Vì sao commit SQL đồng bộ của bạn chờ chuyến đi khứ hồi qua VPN

Độ trễ ghi tăng vọt sau khi một bản sao được chuyển sang site thứ hai, và đường hầm là thành phần mới nhất, nên nó bị đổ lỗi. Đường hầm có thể vô can: trong một nhóm khả dụng có commit đồng bộ, bản chính không thể xác nhận commit cho đến khi hoàn tất một lần ghi log từ xa, nên mọi giao dịch đều trả một chuyến khứ hồi, bất kể đường truyền chở được bao nhiêu megabit. Thông lượng đo byte mỗi giây, độ trễ đo một lần trao đổi mất bao lâu, và một commit chỉ cần một lần trao đổi nhỏ để xong. Một con số quyết định cuộc tranh luận: thời lượng commit của một giao dịch nhỏ, đo bên trong cơ sở dữ liệu khả dụng và sau đó đo lại với một bảng cục bộ trên cùng instance.

Bản chính thực sự chờ điều gì

Dưới commit đồng bộ, bản chính giữ xác nhận commit cho đến khi đối tác xác nhận các bản ghi log của nó đã được làm bền. Làm bền nghĩa là được ghi bền vững vào log giao dịch của bản thứ cấp, không phải được phát lại vào các trang dữ liệu của nó. Redo có thể tụt lại vài phút mà không thêm một mili giây nào vào commit của bản chính.

Tài liệu của Microsoft về các chế độ khả dụng giải thích cái bắt tay đó và mô tả điều nền tảng làm khi một đối tác rơi ra. Một bản sao được đánh dấu đồng bộ là một quy tắc về việc chờ đợi, không phải lời hứa vĩnh viễn rằng có một bản sao từ xa khỏe mạnh cho mọi commit. Đường đi bị ngắt được định nghĩa riêng, và đó không chỉ là việc commit thất bại.

Vậy thời gian chờ bạn thấy là một tổng: vận chuyển log, lập lịch trên cả hai máy chủ và ghi vào lưu trữ từ xa. Một bản thứ cấp có dung lượng log bão hòa thêm thời gian mà không bài kiểm tra tốc độ nào cho thấy. Ổ đĩa đó hiếm khi được đo khi đơn khiếu nại nêu tên VPN.

Băng thông không phải độ trễ khứ hồi

Một bài kiểm tra tốc độ làm ngập đường đi trong chốc lát và báo cáo tốc độ. Commit hỏi một thứ hẹp hơn: một thông điệp nhỏ mất bao lâu để đến phía bên kia, được lưu bền và quay lại. Độ dài đường đi, hàng đợi và mất gói quyết định con số đó, và không cái nào cải thiện khi nhà cung cấp nâng trần.

Vì thế một đường hầm «nhanh» có thể thêm một hình phạt thấy được cho khối lượng công việc nặng ghi, được xây từ nhiều giao dịch nhỏ liên tiếp. Cùng tổng số byte chia cho một nghìn commit trả chuyến khứ hồi một nghìn lần; một lần truyền hàng loạt trả nó một lần.

Hãy đề nghị chủ sở hữu mạng đo độ trễ và mất mát trên chính tuyến của bản sao dưới tải đại diện. Một lệnh ping từ laptop văn phòng đến cổng VPN, hay một bài kiểm tra tốc độ đến nút gần đó, hầu như không quy cho tuyến mà log thực sự đi qua. Hãy để cửa sổ đo trùng với những giờ ghi chậm.

Đọc trạng thái bản sao trước khi thay đổi bất cứ điều gì

Bắt đầu từ những gì các instance báo về chính chúng, vì hai bên có thể không đồng ý về mức độ khỏe mạnh của quan hệ đối tác và mức trung bình trên bảng điều khiển giấu hàng đợi nào đang di chuyển. Các truy vấn dưới đây trả lời những câu hỏi khác nhau: một truy vấn đọc trạng thái sao chép theo từng cơ sở dữ liệu, truy vấn kia đọc cách mỗi bản sao được cấu hình. Chạy cả hai trước khi chạm vào một chế độ.

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

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

Kết quả đầu tiên tách vận chuyển log khỏi redo. log_send_queue_size tăng trong khi redo_queue_size đứng phẳng nghĩa là log chưa đến; ngược lại nghĩa là nó đã đến và việc phát lại đang tụt lại. Chỉ trường hợp đầu nằm trên đường commit.

Kết quả thứ hai xác nhận bản sao nào thực sự được cấu hình như bạn giả định, vì một chế độ bị thay đổi trong sự cố trước thường ở lại trạng thái đã thay đổi và không có tài liệu. Hãy đọc hàng bạn quan tâm thay vì giá trị mặc định của nhóm: availability_mode_desc và failover_mode_desc là theo từng bản sao. secondary_lag_seconds chỉ tồn tại trên SQL Server 2016 trở lên, nên một bản dựng cũ chỉ để lại cho bạn các cột hàng đợi gửi và redo.

Sau đó đo một lần ghi đại diện thay vì tin vào mức trung bình trên bảng điều khiển. Chạy khối dưới đây trong cơ sở dữ liệu khả dụng, rồi chạy lại nó với cùng hình dạng bảng trong một cơ sở dữ liệu ngoài nhóm trên cùng instance. Khoảng cách giữa hai thời lượng là một cái giá thô cho log từ xa, và trong một cuộc tranh luận với nhóm mạng nó đứng vững tốt hơn nhiều so với một biểu đồ. Sau đó hãy thay đổi từng biến một, nếu không khoảng cách không còn nghĩa gì.

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

Commit bất đồng bộ mua gì và giá bao nhiêu

Với commit bất đồng bộ, bản chính ngừng chờ xác nhận làm bền từ xa, nên chuyến khứ hồi rời khỏi đường commit. Độ trễ commit giảm và bản thứ cấp được tự do tụt lại một lượng mà không ai kiểm soát. Đó là một bản sửa thật cho việc chờ đợi và một thay đổi thật cho lời hứa.

Cái giá là một quyết định về điểm phục hồi. Nếu bản chính chết trước khi log của nó đến được một mục tiêu chuyển đổi dự phòng mà bạn thực sự dùng được, việc đẩy dịch vụ sang bản sao bất đồng bộ sẽ vứt bỏ những giao dịch mà ứng dụng đã báo là đã commit. Không hộp thoại cấu hình nào trình bày điều đó như vậy, vì đây là câu hỏi kinh doanh về mất mát chấp nhận được, không phải một thiết lập hiệu năng. Hãy viết cửa sổ mất mát dung thứ trước sự cố, không phải trong lúc sự cố.

Thống nhất chế độ với người sở hữu dữ liệu bằng văn bản, cùng với quy trình chuyển đổi dự phòng cho trường hợp mục tiêu ưu tiên không khả dụng. Đồng bộ trong một tài liệu thiết kế không phải là sổ tay vận hành, và bất đồng bộ không phải là giấy phép ngừng theo dõi các hàng đợi.

Chọn một bản sửa bạn có thể bảo vệ sau này

Có bốn lựa chọn trung thực. Cắt những chuyến khứ hồi commit có thể tránh được ở nơi ngữ nghĩa ứng dụng cho phép gom lô; sửa một điểm nghẽn vận chuyển hoặc lưu trữ mà bạn đã đo, điều này có thể nghĩa là dung lượng log nhanh hơn trên bản thứ cấp thay vì một ống lớn hơn; đưa bản sao lại gần để chuyến khứ hồi thu nhỏ; hoặc nới lỏng chính sách bảo vệ và chấp nhận một cửa sổ mất mát rộng hơn. Mỗi lựa chọn mua độ trễ bằng cách tiêu thứ khác, và lựa chọn thứ tư tiêu độ bền. Hãy gọi tên khoản chi trước khi chọn.

Hãy quyết định khi mục tiêu độ trễ của khối lượng công việc và yêu cầu độ bền của nó cùng ở trước mắt, vì tối ưu cái này sẽ âm thầm tiêu cái kia. Sau đó chạy lại chính giao dịch bạn đã đo trước thay đổi. Một bản sửa không thể nhích con số đó là một phỏng đoán mang theo phiếu thay đổi.

Giữ các số đọc trước và sau trong bản ghi thay đổi. Nếu không, người tiếp theo thấy ghi chậm sẽ lặp lại cuộc điều tra từ đầu và lại bắt đầu đổ lỗi cho đường hầm.