Tentukan mengapa perubahan replika utama tidak tercermin pada replika sekunder untuk grup ketersediaan Always On

Berlaku untuk:SQL Server

Aplikasi klien berhasil menyelesaikan pembaruan pada replika utama, tetapi mengkueri replika sekunder menunjukkan bahwa perubahan tidak tercermin. Kasus ini mengasumsikan bahwa ketersediaan Anda memiliki status sinkronisasi yang sehat. Dalam kebanyakan kasus, perilaku ini diselesaikan dengan sendirinya setelah beberapa menit.

Jika perubahan masih belum tercermin pada replika sekunder setelah beberapa menit, mungkin ada penyempitan dalam alur kerja sinkronisasi. Lokasi penyempitan tergantung pada apakah replika sekunder diatur ke penerapan sinkron atau penerapan asinkron.

Penerapan sinkron

Setiap pembaruan yang berhasil pada replika utama telah disinkronkan ke replika sekunder, atau bahwa rekaman log telah dihapus untuk pengerasan pada replika sekunder. Oleh karena itu, penyempitan harus dalam proses pengulangan yang terjadi setelah log dihapus pada replika sekunder.

Namun, setelah pengulangan tertangkap, semua beban kerja baca pada replika sekunder adalah isolasi rekam jepret:

• Transaksi jangka panjang pada replika utama

• Ulangi pada replika sekunder

Penerapan asinkron

Karena penerapan asinkron mengakui transaksi segera setelah disiram ke disk lokal, hambatan dapat berada di mana saja setelah titik tersebut:

• Transaksi jangka panjang pada replika utama

• Latensi atau throughput jaringan

• Mencatat harden pada replika sekunder

• Ulangi pada replika sekunder

Bagian berikut menjelaskan penyebab umum perubahan pada replika utama yang tidak tercermin pada replika sekunder untuk kueri baca-saja.

Transaksi aktif jangka panjang

Transaksi jangka panjang pada replika utama mencegah pembaruan dibaca pada replika sekunder.

Penjelasan

Semua beban kerja baca pada replika sekunder adalah kueri isolasi rekam jepret. Dalam isolasi rekam jepret, klien baca-saja melihat database ketersediaan pada replika sekunder di titik awal transaksi aktif terlama di log redone. Jika transaksi belum berkomitmen selama berjam-jam, transaksi terbuka memblokir semua kueri baca-saja agar tidak melihat pembaruan baru.

Diagnosis dan resolusi

Pada replika utama, gunakan DBCC OPENTRAN (Transact-SQL) untuk melihat transaksi aktif terlama dan lihat apakah transaksi tersebut dapat digulung balik. Setelah transaksi aktif terlama digulung balik dan disinkronkan ke replika sekunder, beban kerja baca pada replika sekunder dapat melihat pembaruan dalam database ketersediaan hingga awal transaksi aktif terlama.

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

Latensi jaringan tinggi atau throughput rendah dapat mencegah log dikirim ke replika sekunder dengan cukup cepat.

Penjelasan

Replika utama mengaktifkan kontrol alur pada log yang dikirim ketika telah melebihi jumlah maksimum pesan yang tidak diakui yang diizinkan yang dikirim ke replika sekunder. Sampai beberapa pesan ini diakui, tidak ada lagi blok log yang dapat dikirim ke replika sekunder. Situasi ini dapat berdampak lebih serius pada potensi kehilangan data, mungkin membahgi tujuan titik pemulihan (RPO) Anda.

Diagnosis dan resolusi

Nilai DMV tinggi log_send_queue_size dapat menunjukkan log ditahan kembali di replika utama. Membalik nilai ini dengan log_send_rate dapat memberi Anda perkiraan kasar tentang seberapa cepat data dapat tertangkap pada replika sekunder.

Selain itu, berguna untuk memeriksa dua objek performa SQL Server:Availability Replica > Flow Control Time (ms/dtk) dan SQL Server:Availability Replica > Flow control/dtk. 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 tingkat pengiriman.

Di bawah ini adalah daftar metrik yang berguna dalam mendiagnosis latensi dan throughput jaringan. Anda dapat menggunakan alat Windows lainnya seperti ping.exe untuk mengevaluasi pemanfaatan jaringan.

• log_send_queue_size DMV

• log_send_rate DMV

• 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 mengatasi masalah ini, coba tingkatkan bandwidth jaringan Anda atau hapus atau kurangi lalu lintas jaringan yang tidak perlu.

Beban kerja pelaporan lain memblokir utas pengulangan dari menjalankan

Utas pengulangan pada replika sekunder diblokir untuk membuat bahasa definisi data (DDL) berubah oleh kueri baca-saja yang berjalan lama. Utas pengulangan harus dibuka blokirnya sebelum dapat membuat pembaruan lebih lanjut tersedia untuk beban kerja baca.

Penjelasan

Pada replika sekunder, kueri baca-saja memperoleh kunci stabilitas skema (Sch-S). Kunci ini Sch-S dapat memblokir utas pengulangan agar tidak memperoleh kunci modifikasi skema (Sch-M) untuk membuat perubahan DDL. Utas pengulangan yang diblokir tidak dapat menerapkan rekaman log hingga tidak diblokir.

Diagnosis dan resolusi

Saat utas pengulangan diblokir, peristiwa yang diperluas yang disebut sqlserver.lock_redo_blocked dibuat. Selain itu, Anda dapat mengkueri sys.dm_exec_request DMV pada replika sekunder untuk mengetahui sesi mana yang memblokir utas REDO, lalu Anda dapat mengambil tindakan korektif. Kueri berikut mengembalikan ID sesi beban kerja pelaporan yang memblokir utas pengulangan.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'  

Anda dapat membiarkan beban kerja pelaporan selesai, di mana utas pengulangan tidak diblokir, atau Anda dapat membuka blokir utas fase pengulangan segera dengan menjalankan perintah KILL (Transact-SQL) pada ID sesi pemblokiran.

Utas pengulangan tertinggal karena ketidakcocokan sumber daya

Beban kerja pelaporan besar pada replika sekunder telah memperlambat performa replika sekunder, dan utas fase pengulangan telah tertinggal.

Penjelasan

Saat menerapkan rekaman log pada replika sekunder, utas pengulangan membaca rekaman log dari disk log, lalu untuk setiap rekaman log, ia mengakses halaman data untuk menerapkan rekaman log. Akses halaman dapat terikat I/O (mengakses disk fisik) jika halaman belum ada di kumpulan buffer. Jika ada beban kerja pelaporan terikat I/O, beban kerja pelaporan bersaing untuk sumber daya I/O dengan utas pengulangan dan dapat memperlambat utas pengulangan. Situasi ini tidak hanya memengaruhi beban kerja pelaporan lainnya dari melihat data yang diperbarui, tetapi juga memengaruhi RTO.

Diagnosis dan resolusi

Anda dapat menggunakan kueri DMV berikut untuk melihat seberapa jauh utas pengulangan telah tertinggal, dengan mengukur perbedaan antara kesenjangan antara last_redone_lsn dan last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states  
  

Jika utas fase pengulangan memang tertinggal, Anda perlu menyelidiki akar penyebab penurunan performa pada replika sekunder. Jika ada ketidakcocokan I/O dengan beban kerja pelaporan, Anda dapat menggunakan Resource Governor untuk mengontrol siklus CPU yang digunakan oleh beban kerja pelaporan untuk secara tidak langsung mengontrol siklus I/O yang diambil, hingga batas tertentu. Misalnya, jika beban kerja pelaporan Anda menggunakan 10 persen CPU tetapi beban kerja terikat I/O, Anda dapat menggunakan Resource Governor untuk membatasi penggunaan sumber daya CPU hingga 5 persen untuk membatasi beban kerja baca, yang meminimalkan dampak pada I/O.

Langkah berikutnya

Memecahkan masalah performa di SQL Server 2008