Mengapa commit SQL sinkron Anda menunggu perjalanan pulang-pergi VPN

Latensi tulis melonjak setelah replika dipindahkan ke situs kedua, dan terowongan adalah komponen terbaru, jadi ia yang disalahkan. Terowongan bisa tidak bersalah: di dalam grup ketersediaan dengan commit sinkron, replika utama tidak dapat mengakui commit sampai penulisan log jarak jauh selesai, sehingga setiap transaksi membayar perjalanan pulang-pergi berapa pun megabit yang dapat dibawa tautan. Throughput mengukur byte per detik, latensi mengukur berapa lama satu pertukaran berlangsung, dan commit hanya perlu satu pertukaran kecil untuk selesai. Satu angka menyelesaikan perdebatan: durasi commit transaksi kecil, diukur di dalam basis data ketersediaan dan sekali lagi terhadap tabel lokal pada instans yang sama.

Apa yang sebenarnya ditunggu replika utama

Dengan commit sinkron, replika utama menahan pengakuan commit sampai mitra memastikan catatan lognya sudah mengeras. Mengeras berarti tertulis secara tahan lama ke log transaksi sekunder, bukan diputar ulang ke halaman datanya. Redo dapat tertinggal beberapa menit tanpa menambahkan satu milidetik pun ke commit replika utama.

Dokumentasi Microsoft tentang mode ketersediaan menjelaskan jabat tangan itu dan apa yang dilakukan platform ketika mitra keluar. Replika yang ditandai sinkron adalah aturan tentang menunggu, bukan janji permanen bahwa ada salinan jarak jauh yang sehat untuk setiap commit. Jalur terputus didefinisikan secara terpisah, dan bukan sekadar bahwa commit gagal.

Jadi penantian yang Anda lihat adalah jumlah: transportasi log, penjadwalan di kedua host, dan penulisan penyimpanan jarak jauh. Replika sekunder dengan volume log jenuh menambahkan waktu yang tidak akan ditunjukkan uji kecepatan mana pun. Disk itu jarang diukur ketika keluhan menyebut VPN.

Bandwidth bukan tunda pulang-pergi

Uji kecepatan membanjiri jalur sebentar dan melaporkan laju. Commit meminta sesuatu yang lebih sempit: berapa lama pesan kecil mencapai sisi lain, tersimpan, dan kembali. Panjang jalur, antrean, dan kehilangan paket menentukan angka itu, dan tidak satu pun membaik ketika penyedia menaikkan plafon.

Terowongan «cepat» karena itu dapat menambah penalti yang terlihat pada beban kerja berat tulis yang dibangun dari banyak transaksi kecil berurutan. Total byte yang sama dibagi ke seribu commit membayar perjalanan pulang-pergi seribu kali; satu transfer massal membayarnya sekali.

Mintalah pemilik jaringan mengukur tunda dan kehilangan pada rute replika itu sendiri di bawah beban representatif. Ping dari laptop kantor ke gateway VPN, atau uji kecepatan ke node terdekat, hampir tidak mengaitkan apa pun ke rute yang sebenarnya dilalui log. Buat jendela pengukuran tumpang tindih dengan jam ketika penulisan lambat.

Baca status replika sebelum mengubah apa pun

Mulailah dari apa yang dilaporkan instans tentang dirinya sendiri, karena kedua sisi bisa berbeda pendapat tentang seberapa sehat kemitraan itu dan rata-rata dasbor menyembunyikan antrean mana yang bergerak. Kueri di bawah menjawab pertanyaan berbeda: satu membaca status replikasi per basis data, yang lain membaca bagaimana setiap replika dikonfigurasi. Jalankan keduanya sebelum menyentuh mode.

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;

Hasil pertama memisahkan transportasi log dari redo. log_send_queue_size naik sementara redo_queue_size tetap datar berarti log belum tiba; sebaliknya berarti log tiba dan pemutaran ulang tertinggal. Hanya kasus pertama yang duduk di jalur commit.

Hasil kedua memastikan replika mana yang benar-benar dikonfigurasi seperti yang Anda asumsikan, karena mode yang diubah selama insiden sebelumnya cenderung tetap berubah dan tidak terdokumentasi. Baca baris yang Anda pedulikan alih-alih default grup: availability_mode_desc dan failover_mode_desc bersifat per replika. secondary_lag_seconds hanya ada di SQL Server 2016 dan yang lebih baru, jadi build lama meninggalkan Anda hanya dengan kolom antrean kirim dan redo.

Lalu ukur penulisan representatif alih-alih memercayai rata-rata dasbor. Jalankan blok di bawah di basis data ketersediaan, lalu jalankan lagi terhadap bentuk tabel yang sama di basis data di luar grup pada instans yang sama. Selisih antara dua durasi itu adalah harga kasar untuk log jarak jauh, dan dalam argumen dengan tim jaringan ia bertahan jauh lebih baik daripada grafik. Setelah itu ubah satu variabel pada satu waktu, atau selisihnya tidak lagi berarti apa-apa.

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;

Apa yang dibeli commit asinkron, dan berapa biayanya

Dengan commit asinkron, replika utama berhenti menunggu konfirmasi pengerasan jarak jauh, sehingga perjalanan pulang-pergi keluar dari jalur commit. Latensi commit turun dan replika sekunder bebas tertinggal sejauh yang tidak dikendalikan siapa pun. Itu perbaikan nyata untuk penantian dan perubahan nyata pada janji.

Harganya adalah keputusan titik pemulihan. Jika replika utama mati sebelum lognya mencapai target failover yang benar-benar dapat Anda gunakan, memindahkan layanan ke salinan asinkron membuang transaksi yang sudah dilaporkan aplikasi sebagai commit. Tidak ada dialog konfigurasi yang membingkainya begitu, karena itu pertanyaan bisnis tentang kerugian yang dapat diterima, bukan pengaturan kinerja. Tuliskan jendela kerugian yang ditoleransi sebelum insiden, bukan selama insiden.

Sepakati mode dengan pemilik data, secara tertulis, bersama prosedur failover untuk kasus target pilihan tidak tersedia. Sinkron dalam dokumen desain bukan buku pedoman operasional, dan asinkron bukan lisensi untuk berhenti memantau antrean.

Pilih perbaikan yang dapat Anda pertahankan nanti

Ada empat opsi jujur. Potong perjalanan pulang-pergi commit yang dapat dihindari di mana semantik aplikasi memungkinkan pengelompokan; perbaiki hambatan transportasi atau penyimpanan yang Anda ukur, yang mungkin berarti volume log lebih cepat pada replika sekunder alih-alih pipa lebih besar; dekatkan replika agar perjalanan pulang-pergi menyusut; atau longgarkan kebijakan perlindungan dan terima jendela kerugian yang lebih lebar. Masing-masing membeli latensi dengan membelanjakan hal lain, dan yang keempat membelanjakan daya tahan. Sebutkan pengeluarannya sebelum memilih.

Putuskan dengan target latensi beban kerja dan kebutuhan daya tahannya di depan Anda pada saat yang sama, karena mengoptimalkan yang satu diam-diam membelanjakan yang lain. Lalu jalankan lagi transaksi yang sama yang Anda ukur sebelum perubahan. Perbaikan yang tidak dapat menggerakkan angka itu adalah dugaan yang memakai tiket perubahan.

Simpan pembacaan sebelum dan sesudah dalam catatan perubahan. Jika tidak, orang berikutnya yang melihat penulisan lambat mengulang penyelidikan dari awal dan mulai menyalahkan terowongan lagi.