Bagikan melalui

Pemecahan masalah: Potensi kehilangan data dengan replika asinkron-komitmen ketersediaan-grup

Berlaku untuk: SQL Server

Setelah Anda melakukan failover manual paksa pada grup ketersediaan ke replika sekunder penerapan asinkron, Anda mungkin menemukan bahwa kehilangan data lebih dari tujuan titik pemulihan (RPO). Atau, ketika Anda menghitung potensi kehilangan data dari replika sekunder penerapan asinkron menggunakan metode dalam Memantau Performa untuk Grup Ketersediaan AlwaysOn, Anda menemukan bahwa itu melebihi RPO Anda.

Replika sekunder penerapan sinkron menjamin kehilangan data nol, tetapi potensi kehilangan data dari replika sekunder penerapan asinkron tergantung pada berapa banyak log yang masih menunggu untuk diperkuat pada replika sekunder.

Bagian berikut menjelaskan penyebab umum hilangnya data potensial tinggi dari replika sekunder penerapan asinkron, dengan asumsi Bahwa Anda tidak memiliki masalah performa sistemik dalam instans server Anda yang tidak terkait dengan grup ketersediaan.

  1. Latensi jaringan tinggi atau throughput jaringan rendah menyebabkan penumpukan log pada replika utama

  2. Penyempitan I/O disk memperlambat pengerasan log pada replika sekunder

Latensi jaringan tinggi atau throughput jaringan rendah menyebabkan penumpukan log pada replika utama

Alasan paling umum untuk database yang melebihi RPO mereka adalah bahwa mereka tidak dapat dikirim ke replika sekunder dengan cukup cepat.

Penjelasan

Replika utama mengaktifkan kontrol alur pada pengiriman log ketika telah melebihi jumlah maksimum pesan yang tidak diakui yang diizinkan yang dikirim ke replika sekunder. Hingga beberapa pesan ini diakui, tidak ada lagi blok log yang dapat dikirim ke replika sekunder. Karena kehilangan data hanya dapat dicegah ketika telah diperkuat pada replika sekunder, penumpukan pesan log yang tidak terpakai meningkatkan potensi kehilangan data.

Diagnosis dan resolusi

Sejumlah besar pesan yang kesal terhadap replika sekunder dapat menunjukkan latensi jaringan dan kebisingan jaringan yang tinggi. Anda juga dapat membandingkan nilai DMV log_send_rate dengan objek performa Log Bytes Flushed/detik. Jika log dibersihkan ke disk lebih cepat daripada yang dikirim, potensi kehilangan data dapat meningkat tanpa batas waktu.

Selain itu, berguna untuk memeriksa dua objek SQL Server:Availability Replica > Flow Control Time (ms/sec) performa dan SQL Server:Availability Replica > Flow Control/sec. Mengalikan kedua nilai ini menunjukkan kepada Anda dalam detik terakhir berapa banyak waktu yang dihabiskan untuk menunggu kontrol alur dihapus. Semakin lama waktu tunggu kontrol alur, semakin rendah laju pengiriman.

Metrik berikut berguna dalam mendiagnosis latensi dan throughput jaringan. Anda dapat menggunakan alat Windows lainnya, seperti ping.exe dan Monitor Jaringan untuk mengevaluasi latensi dan pemanfaatan jaringan.

  • DMV sys.dm_hadr_database_replica_states, log_send_queue_size

  • DMV sys.dm_hadr_database_replica_states, log_send_rate

  • Penghitung kinerja SQL Server:Database > Log Bytes Flushed/sec

  • Penghitung kinerja SQL Server:Database Mirroring > Send/Receive Ack Time

  • Penghitung kinerja SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Penghitung kinerja SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Penghitung kinerja SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Penghitung kinerja SQL Server:Availability Replica > Flow Control/sec

  • Penghitung kinerja SQL Server:Availability Replica > Resent Messages/sec

Untuk memperbaiki masalah ini, coba tingkatkan bandwidth jaringan Anda atau hapus atau kurangi lalu lintas jaringan yang tidak perlu.

Penyempitan I/O disk memperlambat pengerasan log pada replika sekunder

Bergantung pada penyebaran file database, penguatan log dapat melambat karena ketidakcocokan I/O dengan beban kerja pelaporan.

Penjelasan

Kehilangan data dicegah segera setelah blok log diperkuat pada file log. Oleh karena itu, sangat penting untuk mengisolasi file log dari file data. Jika file log dan file data keduanya dipetakan ke hard disk yang sama, melaporkan beban kerja dengan bacaan intensif pada file data akan menggunakan sumber daya I/O yang sama yang diperlukan oleh operasi pengerasan log. Pengerasan log lambat dapat diterjemahkan untuk memperlambat pengakuan ke replika utama, yang dapat menyebabkan aktivasi kontrol aliran yang berlebihan dan waktu tunggu kontrol aliran yang panjang.

Diagnosis dan resolusi

Jika Anda telah memverifikasi bahwa jaringan tidak menderita latensi tinggi atau throughput rendah, maka Anda harus menyelidiki replika sekunder untuk ketidakcocokan I/O. Kueri dari SQL Server: Meminimalkan I/O Disk berguna dalam mengidentifikasi ketidakcocokan. Contoh dari artikel tersebut diturunkan di bawah ini untuk kenyamanan Anda.

Skrip berikut memungkinkan Anda melihat jumlah baca dan tulis pada setiap data dan file log untuk setiap database ketersediaan yang berjalan pada instans SQL Server. Ini diurutkan menurut waktu kios I/O rata-rata, dalam milidetik. Perhatikan bahwa angka bersifat kumulatif dari terakhir kali instans server dimulai. Oleh karena itu, Anda harus mengambil perbedaan antara dua pengukuran setelah beberapa waktu berlalu.

SELECT DB_NAME(database_id) AS   
   [Database Name] ,   
   file_id ,   
   io_stall_read_ms ,   
   num_of_reads ,   
   CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,   
   io_stall_write_ms ,   
   num_of_writes ,  
   CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,   
   io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,   
   num_of_reads + num_of_writes AS [total_io] ,   
   CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads  
+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]  
FROM sys.dm_io_virtual_file_stats(NULL, NULL)  
WHERE DB_NAME(database_id) IN (SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)  
ORDER BY avg_io_stall_ms DESC;

Kueri berikutnya ini menyediakan rekam jepret point-in-time (tidak kumulatif) permintaan I/O yang tertunda pada sistem Anda.

SELECT DB_NAME(mf.database_id) AS [Database] ,   
   mf.physical_name ,  
   r.io_pending ,   
   r.io_pending_ms_ticks ,   
   r.io_type ,   
   fs.num_of_reads ,   
   fs.num_of_writes  
FROM sys.dm_io_pending_io_requests AS r   
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle   
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id  
AND fs.file_id = mf.file_id  
ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;

Anda dapat membandingkan bagaimana I/O baca dan I/O tulis cocok satu sama lain untuk mengidentifikasi ketidakcocokan I/O.

Berikut ini adalah beberapa penghitung kinerja lain yang dapat membantu Anda dalam mendiagnosis hambatan I/O:

  • Disk Fisik: semua penghitung

  • Disk Fisik: Rata-rata Disk detik/Transfer

  • SQL Server: Waktu Tunggu Flush Log Database >

  • SQL Server: Log Database > Flush Waits/dtk

  • SQL Server: Pembacaan > Disk Kumpulan Log Database/detik

Jika Anda mengidentifikasi penyempitan I/O dan Anda telah menempatkan file log dan file data pada hard disk yang sama, hal pertama yang harus Anda lakukan adalah menempatkan file data dan file log pada disk terpisah. Praktik terbaik ini mencegah pelaporan beban kerja mengganggu jalur transfer log dari replika utama ke buffer log dan kemampuannya untuk mengeraskan transaksi pada replika sekunder.

Langkah berikutnya

Memecahkan masalah performa di SQL Server (berlaku untuk SQL Server 2012)

  • Last updated on