Eşzamanlı SQL commit'iniz neden VPN gidiş-dönüşünü bekliyor

Yazma gecikmesi, bir kopya ikinci siteye taşındıktan sonra fırladı ve tünel en yeni bileşen olduğu için suçu o alıyor. Tünel masum olabilir: eşzamanlı commit'li bir kullanılabilirlik grubunda birincil, uzak bir günlük yazımı tamamlanmadan bir commit'i onaylayamaz, bu yüzden her işlem, bağlantı kaç megabit taşıyabilirse taşısın, bir gidiş-dönüş öder. Aktarım hızı saniyedeki baytı ölçer, gecikme bir takasın ne kadar sürdüğünü ölçer ve bir commit'in bitmesi için yalnızca küçük bir takas yeterlidir. Tartışmayı tek bir sayı bitirir: küçük bir işlemin commit süresi, kullanılabilirlik veritabanının içinde ve ardından aynı örnekteki yerel bir tabloya karşı yeniden ölçülür.

Birincil aslında neyi bekliyor

Eşzamanlı commit altında birincil, iş ortağı günlük kayıtlarının sağlamlaştırıldığını doğrulayana kadar commit onayını tutar. Sağlamlaştırılmış, ikincilin işlem günlüğüne kalıcı olarak yazılmış demektir, veri sayfalarına yeniden uygulanmış değil. Redo, birincilin commit'ine tek bir milisaniye eklemeden dakikalarca geride kalabilir.

Microsoft'un kullanılabilirlik modları belgeleri bu el sıkışmayı açıklar ve bir iş ortağı düştüğünde platformun ne yaptığını anlatır. Eşzamanlı olarak işaretlenmiş bir kopya, bekleme hakkında bir kuraldır; her commit için sağlıklı bir uzak kopya bulunduğuna dair kalıcı bir söz değildir. Bağlantısı kesilen yol ayrı tanımlanır ve bu yalnızca commit'in başarısız olması değildir.

Yani gördüğünüz bekleme bir toplamdır: günlük taşıması, iki ana bilgisayarda zamanlama ve uzak depolamaya yazma. Günlük hacmi doymuş bir ikincil, hiçbir hız testinin göstermeyeceği zamanı ekler. Şikayet VPN'i andığında o disk nadiren ölçülür.

Bant genişliği gidiş-dönüş gecikmesi değildir

Bir hız testi yolu kısa süreliğine sular altında bırakır ve bir hız bildirir. Commit daha dar bir şey sorar: küçük bir mesajın karşı tarafa ulaşması, kalıcı olması ve geri dönmesi ne kadar sürer. Yolun uzunluğu, kuyruklar ve paket kaybı bu sayıyı belirler ve sağlayıcı tavanı yükselttiğinde hiçbiri iyileşmez.

Bu yüzden «hızlı» bir tünel, çok sayıda küçük sıralı işlemden oluşan yazma ağırlıklı bir iş yüküne görünür bir ceza ekleyebilir. Aynı toplam bayt bin commit'e bölünürse gidiş-dönüşü bin kez öder; tek bir toplu aktarım onu bir kez öder.

Ağ sahibinden temsili yük altında kopya rotasının kendisi üzerinde gecikme ve kayıp ölçmesini isteyin. Bir ofis dizüstü bilgisayarından VPN geçidine ping veya yakındaki bir düğüme hız testi, günlüğün gerçekte izlediği rotaya neredeyse hiçbir şey atfetmez. Ölçüm penceresinin yazmanın yavaş olduğu saatlerle çakışmasını sağlayın.

Herhangi bir şeyi değiştirmeden önce kopyanın durumunu okuyun

Örneklerin kendileri hakkında bildirdikleriyle başlayın, çünkü iki taraf ortaklığın ne kadar sağlıklı olduğu konusunda anlaşamayabilir ve gösterge paneli ortalaması hangi kuyruğun hareket ettiğini gizler. Aşağıdaki sorgular farklı soruları yanıtlar: biri veritabanı başına çoğaltma durumunu okur, diğeri her kopyanın nasıl yapılandırıldığını okur. Bir moda dokunmadan önce ikisini de çalıştırın.

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;

İlk sonuç günlük taşımasını redo'dan ayırır. log_send_queue_size artarken redo_queue_size düz kalıyorsa günlük ulaşmamıştır; tersi, ulaştığı ve yeniden oynatmanın geride kaldığı anlamına gelir. Commit yolunda yalnızca ilk durum oturur.

İkinci sonuç hangi kopyaların gerçekten varsaydığınız gibi yapılandırıldığını doğrular, çünkü önceki bir olay sırasında değiştirilen bir mod genellikle değişmiş ve belgelenmemiş kalır. Grubun varsayılanı yerine sizi ilgilendiren satırı okuyun: availability_mode_desc ve failover_mode_desc kopya başınadır. secondary_lag_seconds yalnızca SQL Server 2016 ve sonrasında bulunur, bu yüzden daha eski bir derleme size yalnızca gönderme kuyruğu ve redo sütunlarını bırakır.

Ardından gösterge paneli ortalamasına güvenmek yerine temsili bir yazma ölçün. Aşağıdaki bloğu kullanılabilirlik veritabanında çalıştırın, sonra aynı örnekte grubun dışındaki bir veritabanında aynı tablo biçimine karşı yeniden çalıştırın. İki süre arasındaki fark, uzak günlük için kaba bir fiyattır ve ağ ekibiyle bir tartışmada bir grafikten çok daha iyi dayanır. Ardından her seferinde tek bir değişken değiştirin, yoksa fark bir şey ifade etmez.

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;

Eşzamansız commit ne satın alır ve neye mal olur

Eşzamansız commit ile birincil, uzak sağlamlaştırma onayını beklemeyi bırakır, böylece gidiş-dönüş commit yolundan çıkar. Commit gecikmesi düşer ve ikincil, kimsenin kontrol etmediği bir miktarda geride kalmakta serbest kalır. Bu, bekleme için gerçek bir düzeltme ve sözde gerçek bir değişikliktir.

Bedel, kurtarma noktası hakkında bir karardır. Birincil, günlüğü gerçekten kullanabileceğiniz bir yük devretme hedefine ulaşmadan ölürse, hizmeti eşzamansız kopyaya taşımak, uygulamanın zaten commit olarak bildirdiği işlemleri atar. Hiçbir yapılandırma iletişim kutusu bunu böyle sunmaz, çünkü bu kabul edilebilir kayıpla ilgili bir iş sorusudur, performans ayarı değil. Tolere edilen kayıp penceresini olaydan önce yazın, olay sırasında değil.

Modu verinin sahibiyle yazılı olarak, tercih edilen hedefin kullanılamadığı durum için yük devretme yordamıyla birlikte kararlaştırın. Tasarım belgesindeki eşzamanlı, operasyonel bir el kitabı değildir ve eşzamansız, kuyrukları izlemeyi bırakma lisansı değildir.

Sonradan savunabileceğiniz bir düzeltme seçin

Dört dürüst seçenek var. Uygulamanın anlambilimi toplu işlemeye izin verdiği yerde kaçınılabilir commit gidiş-dönüşlerini kesin; ölçtüğünüz taşıma veya depolama darboğazını düzeltin, bu ikincilde daha büyük bir boru yerine daha hızlı bir günlük hacmi anlamına gelebilir; gidiş-dönüş küçülsün diye kopyayı yaklaştırın; ya da koruma ilkesini gevşetip daha geniş bir kayıp penceresini kabul edin. Her biri gecikmeyi başka bir şey harcayarak satın alır ve dördüncüsü dayanıklılığı harcar. Seçmeden önce harcamayı adlandırın.

İş yükünün gecikme hedefi ve dayanıklılık gereksinimi aynı anda önünüzdeyken karar verin, çünkü birini optimize etmek diğerini sessizce harcar. Ardından değişiklikten önce ölçtüğünüz aynı işlemi yeniden çalıştırın. O sayıyı hareket ettiremeyen bir düzeltme, değişiklik bileti takmış bir tahmindir.

Değişiklik kaydında önce ve sonra okumalarını saklayın. Aksi halde yavaş yazmaları gören bir sonraki kişi soruşturmayı baştan tekrarlar ve yine tüneli suçlamaya başlar.