Chào mọi người và cảm ơn trước sự giúp đỡ của bạn. Chúng tôi đang gặp thử thách với các nhóm sẵn có của SQL Server 2017.
Lý lịch
Công ty là một phần mềm back-end B2B bán lẻ. Khoảng 500 cơ sở dữ liệu người thuê duy nhất và 5 cơ sở dữ liệu dùng chung được sử dụng bởi tất cả người thuê. Đặc tính khối lượng công việc được đọc hầu hết và phần lớn các cơ sở dữ liệu có hoạt động rất thấp.
Các máy chủ sản xuất vật lý được lưu trữ tại cùng vị trí gần đây đã được nâng cấp từ SQL Server 2014 Enterprise trên Windows Server 2012 trong cấu hình SAN / FCI được chia sẻ, lên SQL Server 2017 Enterprise trên Windows Server 2016 trên RAM 2 ổ cắm / 32 lõi / 768 GB và cục bộ Ổ đĩa SSD sử dụng Luôn luôn AG. Lưu lượng AG sử dụng các cổng NIC 10G chuyên dụng với kết nối cáp chéo.
Yêu cầu của họ là cho tất cả các cơ sở dữ liệu cùng chuyển đổi dự phòng, vì vậy họ phải đặt tất cả chúng vào một AG. Đó là một bản sao đồng bộ duy nhất, không thể đọc được trên một máy chủ giống hệt nhau.
Các máy chủ mới đã được sản xuất từ tháng 6 năm 2018. CU mới nhất (CU7 tại thời điểm đó) và các bản cập nhật windows đã được cài đặt và hệ thống đang hoạt động tốt. Khoảng một tháng sau, sau khi cập nhật các máy chủ từ CU7 lên CU9, họ bắt đầu nhận thấy các thách thức sau, được liệt kê theo thứ tự ưu tiên.
Chúng tôi đã theo dõi các máy chủ bằng SQL Sentry và quan sát không có tắc nghẽn vật lý nào. Tất cả các chỉ số chính có vẻ tốt. CPU trung bình 20%, thời gian IO thường dưới 1ms, RAM không được sử dụng đầy đủ và mạng <1%.
Thử thách
Các triệu chứng dường như trở nên tốt hơn sau khi chuyển đổi dự phòng, nhưng sẽ quay trở lại trong vòng một vài ngày, bất kể máy chủ nào là chính - các triệu chứng giống hệt nhau trên cả hai máy chủ.
Mất thời gian của khách hàng lẻ tẻ và lỗi kết nối như
... xảy ra lỗi trong khi thiết lập kết nối ...
hoặc là
Hết thời gian thực hiện
Đôi khi những điều này sẽ diễn ra trong tối đa 40 giây và sau đó giảm dần.
Công việc sao lưu nhật ký giao dịch mất 10 lần để hoàn thành so với trước đây. Trước đây phải mất 2 - 3 phút để sao lưu nhật ký của tất cả 500 cơ sở dữ liệu, bây giờ phải mất 15-25. Chúng tôi đã xác minh rằng bản thân Sao lưu chạy tốt với thông lượng tốt. Tuy nhiên, có một độ trễ nhỏ sau khi hoàn thành sao lưu một bản ghi và trước khi bắt đầu bản ghi tiếp theo. nó bắt đầu rất thấp, nhưng trong vòng một hoặc hai ngày đến 2-3 giây. Nhân với 500 cơ sở dữ liệu, và có sự khác biệt.
Đôi khi, một số cơ sở dữ liệu dường như ngẫu nhiên bị kẹt trong trạng thái "Không đồng bộ hóa" sau khi chuyển đổi thủ công. Cách duy nhất để giải quyết vấn đề này là khởi động lại Dịch vụ máy chủ SQL trên bản sao thứ cấp hoặc xóa và nối lại các cơ sở dữ liệu này với AG.
Một vấn đề khác được giới thiệu bởi CU10 (và không được giải quyết trong CU11): Kết nối với thời gian chờ thứ cấp khi chặn trên cơ sở dữ liệu master.sys.dat và thậm chí không thể sử dụng trình thám hiểm đối tượng SSMS cho bản sao thứ cấp. Nguyên nhân gốc dường như bị chặn bởi nhà văn Microsoft SQL Server VSS đưa ra truy vấn sau:
select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from master.sys.databases
Quan sát
Tôi tin rằng tôi đã tìm thấy khẩu súng hút thuốc trong nhật ký lỗi. Nhật ký lỗi chứa đầy các thông báo AG, được gắn nhãn là "chỉ thông tin", nhưng có vẻ như chúng không bình thường chút nào, và có mối tương quan rất mạnh về tần suất của chúng với các lỗi ứng dụng.
Các lỗi có nhiều loại và xuất hiện theo trình tự:
DbMgrPartnerCommitPolicy :: SetSyncState: GUID
DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID
Luôn kết nối các nhóm sẵn có với cơ sở dữ liệu thứ cấp bị chấm dứt cho cơ sở dữ liệu chính 'XYZ' trên bản sao khả dụng 'DB' với ID bản sao: {GUID}. Đây là tin nhắn mang thông tin đơn thuần. Không có hành động người dùng được yêu cầu.
Luôn kết nối các nhóm sẵn có với cơ sở dữ liệu thứ cấp được thiết lập cho cơ sở dữ liệu chính 'ABC' trên bản sao khả dụng 'DB' với ID bản sao: {GUID}. Đây là tin nhắn mang thông tin đơn thuần. Không có hành động người dùng được yêu cầu.
Một số ngày có 10 ngàn trong số đó.
Bài viết này thảo luận về loại lỗi tương tự trên SQL 2016 và ở đó nó nói rằng nó là bất thường. Điều này cũng giải thích hiện tượng 'không đồng bộ hóa' sau khi chuyển đổi dự phòng. Vấn đề được thảo luận là cho năm 2016 và đã được khắc phục vào đầu năm nay trong một CU. tuy nhiên, đây là tài liệu tham khảo phù hợp duy nhất mà tôi có thể tìm thấy cho 2 loại tin nhắn đầu tiên, ngoài các tham chiếu đến tin nhắn gieo hạt ban đầu tự động không phải là trường hợp ở đây vì AG đã được thiết lập.
Dưới đây là tóm tắt về các lỗi hàng ngày vào tuần trước, trong những ngày có> 10K lỗi cho mỗi loại trên PRIMARY (chương trình phụ 'mất kết nối với chính ...'):
Date Message Type (First 50 characters) Num Errors
10/8/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 61953
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 56812
10/4/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 27951
10/2/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 24158
10/7/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 14904
10/8/2018 Always On Availability Groups connection with seco 13301
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4 11057
10/3/2018 Always On Availability Groups connection with seco 10080Thỉnh thoảng chúng tôi cũng thấy những tin nhắn "kỳ lạ" như:
Cơ sở dữ liệu nhóm khả dụng "DB" đang thay đổi vai trò từ "THỨ HAI" sang "THỨ HAI" vì phiên phản chiếu hoặc nhóm khả dụng không thành công do đồng bộ hóa vai trò. Đây là tin nhắn mang thông tin đơn thuần. Không có hành động người dùng được yêu cầu.
... Trong số rất nhiều trạng thái thay đổi từ "THỨ HAI" sang "GIẢI QUYẾT".
Sau khi chuyển đổi thủ công, hệ thống có thể hoạt động trong vài ngày mà không có một tin nhắn nào thuộc loại này, và đột nhiên, không có lý do rõ ràng, chúng tôi sẽ nhận được hàng ngàn lần, điều này khiến máy chủ không phản hồi và gây ra ứng dụng thời gian chờ kết nối. Đây là một lỗi nghiêm trọng vì một số ứng dụng của họ không kết hợp cơ chế thử lại và do đó có thể mất dữ liệu. Khi xảy ra một loạt lỗi như vậy, các kiểu chờ dưới đây sẽ gọi tên bầu trời. Điều này cho thấy sự chờ đợi ngay sau khi AG dường như mất kết nối với tất cả các cơ sở dữ liệu cùng một lúc:
Khoảng 30 giây sau, mọi thứ trở lại bình thường về mặt chờ đợi, nhưng các thông báo AG liên tục tràn ngập các bản ghi lỗi ở các mức độ khác nhau và trong các thời điểm khác nhau trong ngày, dường như là thời gian ngẫu nhiên bao gồm cả giờ cao điểm. Khối lượng công việc tăng đồng thời trong các đợt lỗi này làm cho mọi thứ trở nên tồi tệ hơn. Nếu chỉ có một vài cơ sở dữ liệu bị ngắt kết nối, thì nó thường không khiến kết nối hết thời gian vì nó được giải quyết đủ nhanh.
Chúng tôi đã cố gắng xác minh rằng đó thực sự là CU9 đã bắt đầu sự cố, nhưng chúng tôi chỉ có thể hạ cấp cả hai nút thành CU9. Nỗ lực hạ cấp một trong hai nút thành CU8, dẫn đến việc nút đó bị kẹt trong trạng thái 'Đang giải quyết' hiển thị cùng một lỗi trong nhật ký:
Không thể đọc cấu hình bền vững của nhóm Luôn sẵn sàng với ID tài nguyên tương ứng ''. Cấu hình bền vững được viết bởi Máy chủ SQL phiên bản cao hơn lưu trữ bản sao khả dụng chính. Nâng cấp phiên bản SQL Server cục bộ để cho phép bản sao sẵn có cục bộ trở thành bản sao thứ cấp.
Điều này có nghĩa là chúng tôi sẽ phải giới thiệu thời gian xuống để có thể hạ cấp cả hai nút xuống CU8 cùng một lúc. Điều này cũng cho thấy đã có một số cập nhật lớn cho AG có thể giải thích những gì chúng ta đang trải qua.
Chúng tôi đã thử điều chỉnh max_worker_threads từ mặc định là 0 (= 960 trên hộp của chúng tôi dựa trên bài viết này ) dần dần lên đến 2.000 mà không có tác động quan sát đến các lỗi.
Chúng ta có thể làm gì để giải quyết các ngắt kết nối AG này? Có ai ngoài đó gặp vấn đề tương tự? Những người khác có số lượng lớn cơ sở dữ liệu trong AG có thể thấy các thông báo tương tự trong nhật ký lỗi SQL bắt đầu bằng CU9 hoặc CU8 không?
Cảm ơn trước sự giúp đỡ nào!