Sorun çözme: Asenkron uyumluluk erişilebilirlik grubu replikalarında olası veri kaybı

Şunlar için geçerlidir: SQL Server

Bir erişilebilirlik grubunda zorunlu manuel bir devre işlemi yaptıktan sonra, asenkron bir ikincil bir kopyaya ulaştıktan sonra, veri kaybının kurtarma noktası hedefinizden (RPO) daha fazla olduğunu görebilirsiniz. Ya da, Monitor Performance for Always On Availability Groups'taki yöntemle asenkron-commit ikincil replikanın potansiyel veri kaybını hesapladığınızda, bunun RPO'nuzu aştığını görürsünüz.

Eşzamanlı işlemeli bir ikincil çoğaltma veri kaybı olmamasını garanti eder, ancak eşzamansız işlemeli bir ikincil çoğaltmadaki olası veri kaybı, ikincil çoğaltmada henüz diske yazılmayı bekleyen günlük miktarına bağlıdır.

Aşağıdaki bölümler, sunucu örneğinizde erişilebilirlik gruplarıyla ilgisi olmayan sistemik performans sorunu olmadığı varsayılarak, asenkron-commit ikincil replikanın yüksek potansiyel veri kaybının yaygın nedenlerini açıklar.

  1. Yüksek ağ gecikmesi veya düşük ağ veri kapasitesi, birincil replikada log birikmesine neden olur

  2. Disk G/Ç darboğazı, ikincil replikada log sertleşmesini yavaşlatır

Yüksek ağ gecikmesi veya düşük ağ veri kapasitesi, birincil replikada log birikmesine neden olur

Veritabanlarının RPO'larını aşmasının en yaygın nedeni, ikincil replikaya yeterince hızlı gönderilememesidir.

Explanation

Birincil replika, ikincil replikaya gönderilen onaylanmamış mesajların izin verilen maksimum sayısını aştığında günlük gönderimde akış kontrolünü etkinleştirir. Bu mesajların bazıları onaylanana kadar, ikincil replikaya artık log bloğu gönderilemez. Veri kaybı ancak ikincil replikada güçlendirildiğinde önlenebileceğinden, gönderilmemiş günlük mesajlarının birikmesi potansiyel veri kaybını artırır.

Tanı ve çözüm

İkincil replikaya gönderilen çok sayıda mesaj, yüksek ağ gecikmesi ve ağ gürültüsü anlamına gelebilir. Ayrıca DMV değerini performans nesnesi Log Bytes Flushed/sec ile log_send_rate karşılaştırabilirsiniz. Eğer loglar gönderilenden daha hızlı diske atılırsa, potansiyel veri kaybı sonsuz olarak artabilir.

Ayrıca, SQL Server:Availability Replica > Flow Control Time (ms/sec) ve SQL Server:Availability Replica > Flow Control/sec olmak üzere iki performans nesnesini kontrol etmek yararlıdır. Bu iki değeri çarpmak, son saniyede akış kontrolünün temizlenmesini beklemek için ne kadar zaman harcadığını gösterir. Akış kontrolü bekleme süresi ne kadar uzun olursa, gönderim oranı o kadar düşüktür.

Aşağıdaki metrikler, ağ gecikmesi ve veri verimliliğinin teşhisinde faydalıdır. Gecikme ve ağ kullanımını değerlendirmek içinping.exe ve Network Monitor gibi diğer Windows araçlarını kullanabilirsiniz.

  • DMV (Motorlu Taşıtlar Dairesi) sys.dm_hadr_database_replica_states, log_send_queue_size

  • DMV (Motorlu Taşıtlar Dairesi) sys.dm_hadr_database_replica_states, log_send_rate

  • Performans sayacı SQL Server:Database > Log Bytes Flushed/sec

  • Performans sayacı SQL Server:Database Mirroring > Send/Receive Ack Time

  • Performans sayacı SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Performans sayacı SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Performans sayacı SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Performans sayacı SQL Server:Availability Replica > Flow Control/sec

  • Performans sayacı SQL Server:Availability Replica > Resent Messages/sec

Bu sorunu çözmek için ağ bant genişliğinizi yükseltmeyi veya gereksiz ağ trafiğini kaldırmayı veya azaltmayı deneyin.

Disk G/Ç darboğazı, ikincil replikada log sertleşmesini yavaşlatır

Veritabanı dosyası dağıtımına bağlı olarak, raporlama iş yükündeki I/O rekabeti nedeniyle log sertleştirmesi yavaşlayabilir.

Explanation

Log bloğu log dosyasında sertleştirildiğinde veri kaybı önlenir. Bu nedenle, log dosyasını veri dosyasından izole etmek kritik öneme sahiptir. Eğer log dosyası ve veri dosyası aynı sabit diske eşlenmişse, veri dosyasında yoğun okumalarla iş yükünü raporlamak, log sertleştirme işlemi için gereken aynı G/O kaynaklarını tüketir. Yavaş log sertleşmesi, birincil replikaya yavaş onay vermeye dönüşebilir; bu da akış kontrolünün aşırı aktivasyonuna ve uzun akış kontrolü bekleme sürelerine neden olabilir.

Tanı ve çözüm

Ağın yüksek gecikme veya düşük aktarım kapasitesi yaşamadığını doğruladıysanız, I/O tartışmaları için ikincil replikayı araştırmalısınız. SQL Server: Minimize Disk I/O sorguları, çekişmeleri belirlemede yararlıdır. O makaleden örnekler aşağıda rahatlığınız için alınmıştır.

Aşağıdaki betik, bir SQL Server örneğinde çalışan her kullanılabilirlik grubundaki veritabanının her bir veri ve günlük dosyasındaki okuma ve yazma sayısını görmenizi sağlar. Ortalama I/O durma süresine göre milisaniyeler içinde sıralanıyor. Sayıların sunucu örneği son başlatıldığından itibaren birikimli olduğunu unutmayın. Bu nedenle, iki ölçüm arasındaki farkı bir süre geçtikten sonra almalısınız.

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;

Bu sonraki sorgu, sisteminizde bekleyen G/Ç taleplerinin zaman içinde (kümülatif değil) bir anlık görüntüsünü sağlar.

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;

Okuma I/O ile yazı I/O'nun birbirleriyle nasıl eşleştiğini karşılaştırarak I/O çekişmelerini belirleyebilirsiniz.

Aşağıda, I/O darboğazlarını teşhis etmenize yardımcı olabilecek bazı diğer performans sayacları şunlardır:

  • Fiziksel Disk: tüm sayaçlar

  • Fiziksel Disk: Ortalama Disk Saniyesi/Transfer

  • SQL Server: Veritabanları > Kütük Dökme Bekleme Süresi

  • SQL Server: Veritabanları > Log Flush Bekleme/saniye

  • SQL Server: Veritabanları > Log Pool Disk Okunma/Saniye

Bir I/O darboğazı tespit ederseniz ve log dosyası ile veri dosyasını aynı sabit diske yerleştirdiyseniz, yapmanız gereken ilk şey veri dosyası ile log dosyasını ayrı disklere yerleştirmektir. Bu en iyi uygulama, raporlama iş yükünün birincil replikadan log buffer'a günlük transfer yoluna ve ikincil replikada işlemi sertleştirme yeteneğine müdahale etmesini engeller.

İlgili içerik

  • Last updated on