Phản ánh cơ sở dữ liệu máy chủ SQL: hành vi ứng dụng khách lạ khi chuyển đổi dự phòng

Tôi đang đặt môi trường máy chủ HA SQL dựa trên ba máy SQL Server 2008 R2 và phản chiếu cơ sở dữ liệu.

Tôi sẽ đặt tên cho chúng:

• hiệu trưởng.company.intra
• gương.company.intra
• nhân chứng

Tên miền "company.intra" là tên miền của công ty mẹ.

Cả hai công cụ cơ sở dữ liệu đang lắng nghe trên cổng 52002 tĩnh để các ứng dụng khách truy cập chúng theo cách sau:

principal.company.intra,52002 & mirror.company.intra,52002

Điểm cuối được gọi EP_Mirroringtại hiệu trưởng và gương, EP_Witnesstại nhân chứng và lắng nghe trên cổng 5022 tại hiệu trưởng, 5023 tại gương và 5024 tại nhân chứng.

Tài khoản dịch vụ được cấu hình chính xác và được cấp quyền kết nối trên các điểm cuối của nhau.

Tính năng phản chiếu đang hoạt động tốt và cơ sở dữ liệu chuyển đổi dự phòng chính xác trong trường hợp chuyển đổi dự phòng thủ công TSQL hoặc lỗi hệ thống mô phỏng.

Vấn đề là với các ứng dụng hoạt động kỳ lạ khi chuyển đổi dự phòng.

Bối cảnh thử nghiệm ứng dụng là như sau:

Một ứng dụng .NET nhỏ bao gồm hai hộp văn bản và một nút:

Khi nhấp vào nút, nó thực hiện cuộc gọi Proc được lưu trữ và điền vào Textbox1 với đầu ra của sp và Textbox2 với thuộc tính nguồn dữ liệu của tôi SqlConnection.

Chuỗi kết nối trông giống như:

Data source=principal.company.intra,52002;failover partner=mirror.company.intra,52002;
initial catalog = TEST_FAILOVER;user ID=user;password=pass;Connection Timeout=30

Tôi đã khởi chạy ứng dụng này từ máy tính xách tay của mình, nằm ở một tên miền khác: laptop.childcompany.com

Kịch bản 1 :

1. Tôi khởi chạy ứng dụng
2. Nhấn nút, TB1: đầu ra sp / TB2: vice.company.intra, 52002
3. Cơ sở dữ liệu dự phòng
4. Nhấn nút, hết thời gian kết nối
5. Nhấn nút, hết thời gian kết nối
6. Chuyển đổi dự phòng DB tại gương (trở lại hiệu trưởng)
7. Nhấn nút, TB1: đầu ra sp / TB2: vice.company.intra, 52002

Kịch bản 2 :

1. Cơ sở dữ liệu dự phòng
2. Ra mắt ứng dụng
3. Nhấn nút, TB1: đầu ra sp / TB2: mirror.company.intra, 52002
4. Cơ sở dữ liệu dự phòng tại gương (trở lại hiệu trưởng)
5. Nhấn nút, lỗi kết nối
6. Nhấn nút, TB1: đầu ra sp / TB2: vice.company.intra, 52002
7. Cơ sở dữ liệu dự phòng
8. Nhấn nút, hết thời gian kết nối
9. Nhấn nút, hết thời gian kết nối

Sau đó, tôi đã cố gắng khởi chạy ứng dụng trên máy chủ nhân bản, cục bộ thông qua RDP

Kịch bản 3

1. Ra mắt ứng dụng
2. Nhấn nút, TB1: đầu ra sp / TB2: vice.company.intra, 52002
3. Cơ sở dữ liệu dự phòng
4. Nhấn nút, lỗi kết nối
5. Nhấn nút, TB1: đầu ra sp / TB2: MIRROR

Tôi đã kiểm tra MSDN về hành vi kết nối Ole DB trong trường hợp chuyển đổi dự phòng để hiểu tại sao trong kịch bản thứ ba, thuộc tính nguồn dữ liệu của kết nối của tôi được đặt thành MIRRORvà khôngmirror.company.holding,52002

Tôi đã biết rằng thuộc tính máy chủ chuyển đổi dự phòng của chuỗi kết nối của tôi chỉ được sử dụng trong trường hợp kết nối ban đầu với lỗi chính (giải thích tại sao kịch bản 2 hoạt động chính xác), nhưng trong trường hợp kết nối hiện có, máy chủ chính đã cung cấp ứng dụng có địa chỉ máy chủ nhân bản (trong một cái gì đó gọi là "failover cache"); thông tin được cung cấp là sai, không có thông tin cổng nghe và tên máy chủ thay vì FQDN, do đó không nằm ngoài miền công ty mẹ.

Bước tiếp theo, tôi đã kiểm tra khung nhìn sys.database_mirroring:

select M.* 
from sys.databases D 
inner join sys.database_mirroring M on D.database_id = M.database_id 
where D.name = 'TEST_FAILOVER'

Và lưu ý rằng trường "mirroring_partner_instance" chứa "MIRROR" thay vì "mirror.company.intra, 52002".

Kiểm tra nhanh với Books Online thông báo cho tôi rằng đây là trường được sử dụng để thông báo cho các ứng dụng khách của đối tác chuyển đổi dự phòng khi kết nối ban đầu với DB Engine chính.

Vì vậy, cuối cùng, câu hỏi của tôi là:

Có cách nào để sửa hành vi đó và làm cho trường "mirroring_partner_instance" giữ FQDN của gương với cổng nghe không?

Tại điểm cuối tạo? Ở mức độ cấu hình phản chiếu (thông qua một tuyên bố cơ sở dữ liệu thay đổi)? Cấu hình động cơ DB?

Tôi đã thử thành công thiết lập bí danh máy khách SQL Server tại các máy khách như một cách giải quyết, tuy nhiên tôi thực sự thích nếu máy chủ chính trả lại thông tin dự phòng chính xác cho các ứng dụng khách.

Đề nghị bạn kiểm tra xem mỗi hộp có mỗi FQDN được đăng ký với cổng, v.v., cho từng mục tiêu / sql-srv, cũng như FQDN của nhân chứng. Mỗi máy chủ có tất cả ba đăng ký với FQDN. Reinitialized các điểm cuối và vượt qua các ngón tay của bạn! :) Nếu trong DMZ, bạn có thể sử dụng AD bên trong DMZ không? hoặc có thể có sự tin tưởng trở lại corp AD? Nếu tên ngắn được đăng ký và FQDN, hãy nghĩ rằng sự tin tưởng này có thể mang lại cho bạn sự phù hợp, do đó, không có FQDN được sử dụng. Rick