Mengapa VPN Laju Masih Melambatkan Commit SQL Segerak

Buka sesi pertanyaan pada primer dan perhatikan apa yang ditunggu oleh tulisan mudah. Jika pangkalan data tergolong dalam kumpulan ketersediaan dengan commit segerak dan sekunder disambungkan, sebahagian tunggu itu keluar dari bangunan: rekod log bergerak ke replika, dikeraskan di sana, dan berita pengerasan itu kembali sebelum commit selesai. Lebar jalur tidak memendekkan perjalanan pergi balik itu. Panduan di bawah mengikuti pengesahan daripada skrin ke cakera jauh dan kembali.

Mulakan dengan jenis tunggu pada primer

Tulisan yang menunggu pada replika jauh muncul sebagai tunggu berkaitan log dan bukan tunggu CPU atau kunci, dan tempoh transaksi mengikut perjalanan pergi balik dan bukannya bilangan baris. Banyak commit kecil menjadikannya jelas, kerana setiap satu membayar perjalanan secara berasingan. Satu operasi pukal menyembunyikan kos yang sama di dalam satu pengesahan yang lebih panjang.

Isih beban kerja anda mengikut kekerapan commit sebelum membuat sebarang kesimpulan tentang pautan.

Baca keadaan replika sebelum membaca rangkaian. Pembilang yang penting ialah baris gilir hantar, baris gilir redo dan keadaan penyegerakan, dan bersama-sama ia menunjukkan sama ada sekunder mengejar atau ketinggalan. Baris gilir hantar yang membesar menunjuk kepada pengangkutan, manakala baris gilir redo yang membesar menunjuk kepada kerja atau storan sekunder itu sendiri. Itu pembaikan yang berbeza, dan tiada satu pun bertambah baik dengan menambah lebar jalur.

Ikuti pengesahan sampai ke sekunder

Dalam commit segerak, primer menunggu pengesahan bahawa log berkenaan telah dikeraskan pada sekunder sebelum melaporkan commit selesai. Dikeraskan bermaksud tahan lama dalam log, bukan dimainkan semula ke halaman data. Perbezaan itulah yang menjelaskan mengapa sekunder segerak boleh ketinggalan dalam redo sambil masih mengesahkan pengerasan.

Telusuri laluan mengikut urutan dan ukur setiap peringkat dan bukannya keseluruhan. Rekod log melalui pengangkutan, sekunder menulis dan menyahcasnya, dan pengesahan kembali melalui laluan yang sama. Kelewatan pengangkutan, penjadualan sekunder dan kependaman cakera log sekunder semuanya masuk ke dalam jumlah, dan hanya yang pertama milik pemilik rangkaian. Sekunder yang isipadu lognya tepu oleh perkara lain boleh memanjangkan setiap commit sementara pautan terbiar.

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 coretan itu sebelum dan selepas tulisan wakil dan bukannya sekali pada petang yang tenang. Perbezaannya yang memberitahu anda baris gilir mana bergerak semasa commit menunggu.

Ukur laluan, bukan pautan

Ujian daya pemprosesan mengukur kapasiti antara dua titik yang bukan replika anda, di bawah beban yang bukan kerja anda. Minta pemilik rangkaian untuk kelewatan dan kehilangan di sepanjang laluan replika sebenar semasa trafik sebenar berjalan, dalam kedua-dua arah. Kehilangan lebih penting daripada kapasiti di sini, kerana segmen yang hilang memerlukan penghantaran semula dan setiap commit menunggu satu pengesahan. Pautan yang kelihatan sangat baik dalam ujian muat turun masih boleh tidak sesuai untuk corak commit yang banyak bercakap.

Kekalkan keselamatan pengangkutan pangkalan data dan kawalan akses tanpa gangguan semasa mengukur. Mengukur laluan tidak pernah menjadi alasan untuk memintasnya.

Kaitkan masa dengan pembilang dan bukannya dengan gerak hati. Jika baris gilir hantar kekal kosong dan commit masih menunggu, kelewatan ada pada pengesahan atau pada penyahcasan sekunder. Jika baris gilir hantar membesar secara berterusan, pengangkutan atau kapasiti ialah kekangan. Catat pemerhatian mana yang menyokong kesimpulan supaya orang seterusnya boleh mengulang pengukuran dan bukan perdebatan.

Apa yang sebenarnya diubah mod tak segerak

Commit tak segerak menghapuskan tunggu akan pengesahan pengerasan daripada sekunder, itulah sebabnya tulisan menjadi lebih pantas dan itulah sebabnya kedudukan ketahanan anda berubah. Primer mengesahkan transaksi tanpa pengesahan jauh itu. Sekunder kemudian dibenarkan ketinggalan, dan ketinggalan itulah pendedahan.

Jika primer hilang sebelum log mencapai sasaran pengambilalihan yang boleh digunakan, memaksa perkhidmatan ke replika itu membuang transaksi yang sudah dimaklumkan kepada aplikasi sebagai commit.

Itu keputusan titik pemulihan dan ia milik pemilik pangkalan data, bukan semakan prestasi. Tetapkan dahulu tetingkap kehilangan data yang bertoleransi, pilih mod yang memenuhinya, kemudian optimumkan dalam sempadan itu. Pilihan yang mengekalkan perlindungan segerak termasuk membuang perjalanan commit yang boleh dielakkan di tempat aplikasi membenarkannya, membaiki kesesakan pengangkutan atau storan yang diukur, dan memindahkan replika supaya pengesahan menempuh jarak yang lebih pendek. Timbang semuanya terhadap keperluan ketahanan yang anda mulakan, yang tidak berubah.