Vì sao VPN nhanh vẫn làm chậm xác nhận SQL đồng bộ

Mở một phiên truy vấn trên máy chủ chính và xem một thao tác ghi đơn giản đang chờ gì. Nếu cơ sở dữ liệu thuộc một nhóm sẵn sàng có xác nhận đồng bộ và bản sao thứ cấp được kết nối, một phần của sự chờ đó rời khỏi toà nhà: các bản ghi nhật ký đi đến bản sao, được làm bền ở đó, và tin về việc làm bền ấy quay về trước khi xác nhận kết thúc. Băng thông không rút ngắn chuyến đi khứ hồi đó. Phần trình bày dưới đây theo dõi xác nhận từ màn hình đến đĩa từ xa và quay lại.

Bắt đầu từ kiểu chờ trên máy chủ chính

Một thao tác ghi đang chờ trên bản sao từ xa hiện ra như một sự chờ liên quan đến nhật ký chứ không phải chờ CPU hay khoá, và thời lượng giao dịch đi theo chuyến khứ hồi thay vì số hàng. Nhiều lần commit nhỏ làm điều đó rõ ràng, vì mỗi lần trả giá cho chuyến đi riêng. Một thao tác hàng loạt duy nhất giấu cùng chi phí đó trong một xác nhận dài hơn.

Hãy sắp xếp khối lượng công việc theo tần suất commit trước khi kết luận bất cứ điều gì về đường truyền.

Đọc trạng thái bản sao trước khi đọc mạng. Các bộ đếm quan trọng là hàng đợi gửi, hàng đợi redo và trạng thái đồng bộ hoá, và cùng nhau chúng cho thấy bản sao thứ cấp theo kịp hay tụt lại. Hàng đợi gửi tăng dần chỉ về đường truyền, trong khi hàng đợi redo tăng dần chỉ về công việc hoặc lưu trữ của chính bản sao thứ cấp. Đó là những cách sửa khác nhau, và không cách nào tốt hơn nhờ thêm băng thông.

Theo dấu xác nhận đến bản sao thứ cấp

Với xác nhận đồng bộ, máy chủ chính chờ xác nhận rằng nhật ký liên quan đã được làm bền trên bản sao thứ cấp trước khi báo xác nhận đã xong. Làm bền nghĩa là bền vững trong nhật ký, không phải được phát lại vào các trang dữ liệu. Chính sự phân biệt đó giải thích vì sao một bản sao thứ cấp đồng bộ có thể tụt lại ở redo mà vẫn xác nhận việc làm bền.

Đi theo đường đi theo thứ tự và đo từng chặng thay vì toàn bộ. Các bản ghi nhật ký đi qua đường truyền, bản sao thứ cấp ghi và xả chúng, và xác nhận quay về theo đúng đường đó. Độ trễ đường truyền, việc lập lịch của bản sao thứ cấp và độ trễ đĩa nhật ký của bản sao thứ cấp đều nằm trong tổng, và chỉ cái đầu tiên thuộc về người quản lý mạng. Một bản sao thứ cấp có khối lượng nhật ký bị bão hoà bởi thứ khác có thể kéo dài mọi xác nhận trong khi đường truyền ngồi không.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Chụp ảnh trạng thái đó trước và sau một thao tác ghi đại diện thay vì một lần vào buổi chiều yên tĩnh. Chính sự khác biệt cho bạn biết hàng đợi nào đã dịch chuyển trong khi xác nhận chờ.

Đo đường đi, không phải đường truyền

Một bài kiểm tra thông lượng đo dung lượng giữa hai điểm không phải bản sao của bạn, dưới tải không phải công việc của bạn. Hãy yêu cầu người quản lý mạng đo độ trễ và mất mát dọc theo đường đi thật của bản sao trong khi lưu lượng thật chạy, theo cả hai chiều. Mất mát quan trọng hơn dung lượng ở đây, vì một phân đoạn bị mất tốn một lần truyền lại và mọi xác nhận đều chờ một xác nhận. Một đường truyền trông tuyệt vời trong bài kiểm tra tải xuống vẫn có thể không phù hợp với kiểu commit nhiều lời.

Giữ nguyên vẹn bảo mật đường truyền của cơ sở dữ liệu và các kiểm soát truy cập trong khi đo. Đo một đường đi không bao giờ là lý do để bỏ qua chúng.

Tương quan thời gian với các bộ đếm thay vì với trực giác. Nếu hàng đợi gửi vẫn trống và xác nhận vẫn chờ, độ trễ nằm ở xác nhận hoặc ở việc xả của bản sao thứ cấp. Nếu hàng đợi gửi tăng đều, ràng buộc là đường truyền hoặc dung lượng. Ghi lại quan sát nào đã ủng hộ kết luận để người sau có thể lặp lại phép đo thay vì cuộc tranh luận.

Chế độ không đồng bộ thay đổi điều gì

Xác nhận không đồng bộ loại bỏ việc chờ xác nhận làm bền của bản sao thứ cấp, đó là lý do các thao tác ghi nhanh hơn và lý do vị thế độ bền của bạn thay đổi. Máy chủ chính xác nhận giao dịch mà không có xác nhận từ xa đó. Bản sao thứ cấp sau đó được phép tụt lại, và sự tụt lại đó chính là phơi nhiễm.

Nếu máy chủ chính mất trước khi nhật ký đến được một đích chuyển đổi dự phòng dùng được, việc cưỡng bức dịch vụ sang bản sao đó sẽ vứt bỏ những giao dịch mà ứng dụng đã được thông báo là đã commit.

Đây là quyết định về điểm khôi phục và nó thuộc về người sở hữu cơ sở dữ liệu, không thuộc về một buổi đánh giá hiệu năng. Trước hết hãy đặt cửa sổ mất dữ liệu chấp nhận được, chọn chế độ đáp ứng nó, rồi tối ưu trong ranh giới đó. Các lựa chọn giữ được bảo vệ đồng bộ gồm loại bỏ những chuyến commit có thể tránh ở nơi ứng dụng cho phép, sửa một nút cổ chai đã đo của đường truyền hoặc lưu trữ, và di chuyển bản sao để xác nhận đi quãng đường ngắn hơn. Hãy cân chúng với yêu cầu độ bền mà bạn đã bắt đầu, thứ không thay đổi.