Memecahkan masalah replikasi geografis dan mengulangi jeda

Aplikasi ke:Azure SQL Database

Dalam replikasi geografis aktif, replika geo-sekunder terus menerima dan menerapkan catatan log transaksi dari primer. Ketika replika sekunder tidak dapat menerapkan log secepat yang dihasilkan oleh primer, backlog menumpuk (antrean ulang) dan kesenjangan waktu meningkat (keterlambatan ulang). Situasi ini dapat memengaruhi konsistensi data hanya baca pada server sekunder dan meningkatkan waktu failover.

• Antrean ulang: Volume catatan log transaksi yang dikirim oleh replikasi geografis ke sekunder tetapi belum diterapkan.
• Redo lag: Waktu yang berlalu antara komitmen transaksi pada primer dan penyelesaian replikasi ulang pada sekunder.

Replikasi geografis tidak sinkron. Keterlambatan pemulihan pada replika sekunder tidak menyebabkan penantian pada replika primer, tetapi keterlambatan pemulihan dapat menyebabkan data pada sekunder tertinggal.

Gejala

• Data kedaluwarsa pada server sekunder untuk beban kerja baca-saja (pelaporan, analitik, atau pembacaan yang didistribusikan).
• Waktu failover yang lebih lama, yang akan meningkatkan Tujuan Waktu Pemulihan (RTO).
• Tekanan sumber daya berkelanjutan pada sekunder, mengurangi kemampuannya untuk mengejar ketinggalan.
• Konfirmasikan lag redo di DMV sys.dm_database_replica_states, jika redo_queue_size > 0 berkembang dan secondary_lag_seconds meningkat.

Mengapa backlog pekerjaan ulang bertambah.

Meskipun database sekunder bersifat baca-saja, database tersebut masih mempertahankan log transaksi untuk operasi internal, termasuk memutar ulang rekaman log dari primer. Ketika antrean ulang tumbuh, sistem sekunder harus menyimpan lebih banyak data log transaksi.

Situasi ini dapat menyebabkan:

• Pertumbuhan log transaksi pada server sekunder.
• Konsumsi penyimpanan yang lebih tinggi, yang dapat memengaruhi biaya dan performa.
• Skenario pembatasan potensial ketika ambang batas terlampaui.

Dampak ketidakcocokan ukuran replika

Anda harus mengonfigurasi replika primer dan geo-sekunder dengan tujuan tingkat layanan (SLO) yang sama, redundansi penyimpanan cadangan, tingkat komputasi (disediakan atau tanpa server), dan ukuran komputasi (DTU atau vCore).

Jika Anda mengonfigurasi database sekunder dengan ukuran komputasi yang lebih rendah daripada database utama, Anda mungkin mengalami:

• Kontensi sumber daya pada sekunder (CPU, I/O), yang memperlambat operasi redo.
• Ketidakmampuan untuk mengikuti tingkat pembuatan log transaksi primer.
• Peningkatan ukuran antrean pengulangan, yang memperburuk lag dan mengurangi efektivitas replikasi.

Recommendations

Untuk mengurangi lag redo dan menjaga kesehatan replikasi serta penggunaan log secara efisien pada server sekunder:

• Selaraskan SLO dan menghitung ukuran. Pastikan database sekunder memiliki tingkat performa yang sama dengan yang utama.

  • Mengonfigurasi geo-sekunder: Replikasi geografis aktif
  • Meningkatkan database tunggal: Meningkatkan sumber daya untuk database tunggal dalam Azure SQL Database
  • Menskalakan kumpulan elastis: Scale sumber daya kumpulan elastis dalam Azure SQL Database
  • Pertimbangan biaya: Plan dan kelola biaya untuk Azure SQL Database

• Pantau secara teratur. Gunakan tampilan manajemen dinamis (DMV) seperti sys.dm_database_replica_states untuk melacak lag pengulangan dan ukuran antrean. Redo lag dikonfirmasi ketika redo_queue_size > 0 berkembang dan secondary_lag_seconds meningkat.

• Optimalkan beban kerja:

  • Kurangi transaksi jangka panjang pada database sekunder dan lonjakan pembuatan log yang tinggi pada database primer.
    • Hindari pembangunan ulang indeks besar selama waktu sibuk. Rekonstruksi dapat memperoleh penguncian modifikasi skema (SCH-M), yang mungkin memblokir utas redo pada sekunder dan berkontribusi pada penumpukan antrean redo.

Konten terkait

• Replikasi geografis aktif
• Mengonfigurasi replikasi geografis aktif dan failover
• Memantau keterlambatan replikasi geografis