Mengapa VPN Cepat Masih Memperlambat Commit SQL Sinkron

Buka sesi kueri pada primer dan perhatikan apa yang ditunggu oleh penulisan sederhana. Jika basis data termasuk grup ketersediaan dengan commit sinkron dan sekunder terhubung, sebagian tunggu itu keluar dari gedung: catatan log pergi ke replika, dikeraskan di sana, dan kabar tentang pengerasan itu kembali sebelum commit selesai. Bandwidth tidak memperpendek perjalanan pulang-pergi itu. Penelusuran di bawah mengikuti pengakuan dari layar ke disk jarak jauh dan kembali.

Mulai dari tipe tunggu pada primer

Penulisan yang menunggu di replika jarak jauh muncul sebagai tunggu terkait log, bukan tunggu CPU atau kunci, dan durasi transaksi mengikuti perjalanan pulang-pergi alih-alih jumlah baris. Banyak commit kecil membuatnya jelas, karena masing-masing membayar perjalanan secara terpisah. Satu operasi massal menyembunyikan biaya yang sama di dalam satu pengakuan yang lebih panjang.

Urutkan beban kerja Anda berdasarkan frekuensi commit sebelum menyimpulkan apa pun tentang tautan.

Baca keadaan replika sebelum membaca jaringan. Penghitung yang penting adalah antrean kirim, antrean redo, dan keadaan sinkronisasi, dan bersama-sama mereka menunjukkan apakah sekunder mengikuti atau tertinggal. Antrean kirim yang tumbuh menunjuk ke transportasi, sedangkan antrean redo yang tumbuh menunjuk ke pekerjaan atau penyimpanan sekunder itu sendiri. Itu perbaikan yang berbeda, dan tidak satu pun membaik dengan menambah bandwidth.

Ikuti pengakuan sampai ke sekunder

Pada commit sinkron, primer menunggu konfirmasi bahwa log yang bersangkutan telah dikeraskan pada sekunder sebelum melaporkan commit selesai. Dikeraskan berarti tahan lama di log, bukan diputar ulang ke halaman data. Perbedaan itulah yang menjelaskan mengapa sekunder sinkron dapat tertinggal dalam redo sementara masih mengonfirmasi pengerasan.

Telusuri jalur secara berurutan dan ukur setiap tahap, bukan keseluruhan. Catatan log melewati transportasi, sekunder menulis dan membuangnya, dan pengakuan kembali melalui jalur yang sama. Penundaan transportasi, penjadwalan sekunder, dan latensi disk log sekunder semuanya masuk ke total, dan hanya yang pertama milik pemilik jaringan. Sekunder yang volume lognya jenuh oleh hal lain dapat meregangkan setiap commit sementara tautan menganggur.

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;

Ambil cuplikan itu sebelum dan sesudah penulisan yang mewakili, bukan sekali pada sore yang tenang. Selisihnya yang memberi tahu Anda antrean mana yang bergerak saat commit menunggu.

Ukur jalurnya, bukan tautannya

Uji throughput mengukur kapasitas antara dua titik yang bukan replika Anda, di bawah beban yang bukan beban kerja Anda. Mintalah kepada pemilik jaringan penundaan dan kehilangan di sepanjang jalur replika yang sebenarnya saat lalu lintas nyata berjalan, di kedua arah. Kehilangan lebih penting daripada kapasitas di sini, karena segmen yang hilang memerlukan pengiriman ulang dan setiap commit menunggu satu pengakuan. Tautan yang tampak sangat baik dalam uji unduh bisa tetap tidak cocok untuk pola commit yang banyak bicara.

Jaga keamanan transportasi basis data dan kontrol akses tetap utuh selama mengukur. Mengukur jalur tidak pernah menjadi alasan untuk melewatinya.

Korelasikan waktu dengan penghitung, bukan dengan intuisi. Jika antrean kirim tetap kosong dan commit masih menunggu, penundaan ada pada pengakuan atau pada pembuangan sekunder. Jika antrean kirim tumbuh stabil, transportasi atau kapasitas adalah kendalanya. Catat pengamatan mana yang mendukung kesimpulan agar orang berikutnya dapat mengulang pengukuran, bukan perdebatan.

Apa yang sebenarnya diubah mode asinkron

Commit asinkron menghapus tunggu akan pengakuan pengerasan dari sekunder, itulah sebabnya penulisan menjadi lebih cepat dan itulah sebabnya posisi ketahanan Anda berubah. Primer mengonfirmasi transaksi tanpa konfirmasi jarak jauh itu. Sekunder lalu dibiarkan tertinggal, dan ketertinggalan itulah paparannya.

Jika primer hilang sebelum log mencapai target failover yang dapat digunakan, memaksa layanan ke replika itu membuang transaksi yang sudah diberitahukan kepada aplikasi sebagai commit.

Itu keputusan titik pemulihan dan menjadi milik pemilik basis data, bukan tinjauan kinerja. Tetapkan dulu jendela kehilangan data yang ditoleransi, pilih mode yang memenuhinya, lalu optimalkan di dalam batas itu. Opsi yang mempertahankan perlindungan sinkron mencakup menghapus perjalanan commit yang dapat dihindari di tempat aplikasi mengizinkannya, memperbaiki hambatan transportasi atau penyimpanan yang terukur, dan memindahkan replika agar pengakuan menempuh jarak lebih pendek. Timbang semuanya terhadap persyaratan ketahanan yang Anda mulai, yang tidak berubah.