Cơ sở dữ liệu nhóm phân tán sẵn có của SQL Server không được đồng bộ hóa sau khi khởi động lại máy chủ

Chúng tôi đã sẵn sàng để thực hiện nâng cấp lớn trên Máy chủ SQL của mình và nhận thấy một số hành vi bất thường với Nhóm sẵn có phân tán mà tôi đang cố gắng giải quyết trước khi tiếp tục.

Tháng trước, tôi đã nâng cấp máy chủ thứ cấp từ xa từ SQL Server 2016 lên SQL Server 2017. Máy chủ này là một phần của nhiều Nhóm sẵn có phân tán (DAG) và Nhóm khả dụng (AG) riêng biệt . Khi chúng tôi nâng cấp máy chủ này, chúng tôi không biết rằng nó sẽ rơi vào trạng thái không thể đọc được , vì vậy trong suốt một tháng qua, chúng tôi chỉ dựa vào máy chủ chính.

Là một phần của bản nâng cấp sắp tới, tôi đã áp dụng bản vá CU 4 cho máy chủ và khởi động lại nó. Khi máy chủ hoạt động trở lại, phần thứ cấp vừa vá cho thấy tất cả các DAG / AG đang đồng bộ hóa mà không có bất kỳ vấn đề nào.

Tuy nhiên, chính đã cho thấy một câu chuyện rất khác nhau. Nó đã báo cáo rằng

• AG riêng biệt đã được đồng bộ hóa mà không có bất kỳ vấn đề
• nhưng các DAG ở trạng thái Không đồng bộ hóa / Không lành mạnh

Sau khi hoảng loạn ban đầu, tôi đã thử những điều sau đây để có được những thứ được đồng bộ hóa lại trong DAGs:

• Từ chính, tôi dừng lại và tiếp tục chuyển động dữ liệu. Điều này đã không bắt đầu đồng bộ hóa dữ liệu.
• Trên phần thứ cấp (cái tôi vừa vá) tôi đã chạy ALTER DATABASE [<database] SET HADR RESUME;- thực thi không có lỗi, nhưng không tiếp tục bất kỳ đồng bộ hóa nào

Nỗ lực cuối cùng của tôi trong việc đồng bộ hóa dữ liệu một lần nữa là đăng nhập vào thứ cấp và tự khởi động lại dịch vụ SQL Server. Khởi động lại dịch vụ theo cách thủ công có vẻ hơi cực đoan, vì tôi cho rằng máy chủ được khởi động lại là đủ.

Đã có ai gặp phải vấn đề này khi DAG không bắt đầu đồng bộ hóa với phụ sau khi khởi động lại chưa? Nếu vậy, nó đã được giải quyết như thế nào?

Tôi đã kiểm tra cả nhật ký lỗi của SQL Server và trình xem sự kiện trên máy chủ thứ cấp, không có gì khác thường mà tôi có thể thấy.

Xin lưu ý, đây không phải là một câu trả lời dứt khoát nhưng đó là câu trả lời tốt nhất sau khi trò chuyện với Taryn .

Tuy nhiên, chính đã cho thấy một câu chuyện rất khác nhau. Nó đã báo cáo rằng AG riêng biệt đã đồng bộ hóa mà không có bất kỳ vấn đề nào nhưng các DAG ở trạng thái Không đồng bộ hóa / Không lành mạnh

Nếu các cơ sở dữ liệu riêng lẻ và AG bên dưới ag phân tán nói rằng chúng khỏe mạnh và đồng bộ hóa, thì rất có thể đây chỉ là một trục trặc trong bảng điều khiển DMV và / hoặc SSMS. Vì không có gì trong thông báo lỗi để đề xuất bản sao không kết nối hoặc ở trạng thái ngắt kết nối.

Thật không may vì vấn đề đã được giải quyết, thật khó để nói chính xác nó là gì ... nhưng trong tương lai nếu điều này xảy ra với một ai đó:

• Kiểm tra sys.dm_hadr_database_Vplica_states trên tất cả các cụm tìm kiếm bất cứ thứ gì không lành mạnh. Nếu tất cả đều tốt, có thể DMV chưa cập nhật
• Nếu nó không lành mạnh, hãy kiểm tra các lỗi / DMV về các vấn đề kết nối (chẳng hạn như không thể kết nối với giao nhận / chính toàn cầu)
• Câu trả lời của Dan đề cập đến các vấn đề có thể phát sinh từ khởi động cơ sở dữ liệu - mặc dù trong trường hợp này, trường hợp này không thể được đọc để rất có thể không phải là vấn đề nhưng có thể là trong trường hợp của bạn
• Nếu cơ sở dữ liệu có thể đọc được, hãy kiểm tra khói với bảng giả / chèn hoặc ...
• Phiên sự kiện mở rộng bằng cách sử dụng các mục kênh DEBUG sqlserver.hadr_dump_log_blockhoặc sqlserver.hadr_apply_log_blockđể xem liệu thứ cấp có thực sự nhận / áp dụng các khối nhật ký hay ...
• Đối tượng nước hoa SQLServer:Database Replica\Log Bytes Received/sec

Nếu bạn đang nhận dữ liệu trên thứ cấp đó nhưng ag phân tán vẫn hiển thị không đồng bộ hóa hoặc không khỏe thì tôi sẽ chờ một chút để xem giá trị DMV có thay đổi hay không vì nó rõ ràng đang nhận và xử lý các khối nhật ký.

Tuy nhiên, nếu không thì chúng ta sẽ cần điều tra thêm về phạm vi của câu trả lời.

Tôi sẽ nói trước tất cả những điều này với lời cảnh báo rằng tôi không có bất kỳ DAG nào trong sản xuất. Về cơ bản mặc dù lời khuyên này nên được áp dụng giữa cả AG và DAG.

Đã tiếp tục đồng bộ hóa sau khi khởi động lại dịch vụ? Nếu vậy thì dự đoán tốt nhất của tôi về nguyên nhân sẽ bị chặn trên SPID làm lại. Nếu nó vẫn không đồng bộ hóa ngay cả sau khi khởi động lại, đây là điều tôi sẽ kiểm tra trước:

Chặn AG làm lại SPID

Nói chung sẽ chỉ xảy ra trên một thứ cấp có thể đọc được. Để kiểm tra, hãy chạy như sau:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Nếu bất kỳ SPID chặn nào xuất hiện, bạn sẽ cần phải giết chúng trước khi thứ cấp có thể tiếp tục ( DB STARTUPSPID là thứ xử lý các hoạt động làm lại). Tôi khuyên bạn nên xem lại SPID chặn trước để thử và xác định nguyên nhân (thường là báo cáo dài).

Nếu bạn muốn biết thêm thông tin về điều này, có một bài viết tuyệt vời (bao gồm cả giám sát loại hành vi này bằng XE) tại đây .

Kiểm tra DMV

Nếu chuyển động dữ liệu bị đình chỉ, bạn có thể tham khảo DMV để có thêm thông tin về lý do đình chỉ. Chạy như sau:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

Các bài viết BOL mô tả các suspend_reason xa hơn một chút.

Nhóm phân phối sẵn có (DAG) của bạn có được phân chia giữa các khu vực khác nhau không? Nếu vậy, bạn có thể bị giá trị SESSION_TIMEOUT mặc định (10 giây) quá thấp. Điều này có nghĩa là độ trễ giữa hai vùng quá cao để đồng bộ hóa hoàn toàn đáng tin cậy.

Một nhóm khả dụng bình thường có thể tăng giá trị SESSION_TIMEOUT để làm cho các phiên đồng bộ hóa ổn định hơn. Cuối năm ngoái tôi đã nhận thấy rằng không thể chỉnh sửa tham số SESSION_TIMEOUT của DAG. Điều này có nghĩa là DAG chỉ khả thi đối với các tình huống có độ trễ thấp. Chúng tôi đã đăng nhập một vé với Microsoft và đầu năm nay, một hotfix đã được phát hành.

Cải thiện: Định cấu hình giá trị SESSION_TIMEOUT cho bản sao Nhóm khả dụng phân tán trong SQL Server 2016 và 2017