Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk:SQL Server
Aspek performa Grup Ketersediaan AlwaysOn sangat penting untuk mempertahankan perjanjian tingkat layanan (SLA) untuk database misi penting Anda. Memahami bagaimana grup ketersediaan mengirim log ke replika sekunder dapat membantu Anda memperkirakan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) implementasi ketersediaan Anda dan mengidentifikasi hambatan dalam grup ketersediaan atau replika yang berkinerja buruk. Artikel ini menjelaskan proses sinkronisasi, menunjukkan kepada Anda cara menghitung beberapa metrik utama, dan memberi Anda tautan ke beberapa skenario pemecahan masalah performa umum.
Proses sinkronisasi data
Untuk memperkirakan waktu sinkronisasi penuh dan mengidentifikasi hambatan, Anda perlu memahami proses sinkronisasi. Penyempitan performa dapat berada di mana saja dalam proses, dan menemukan hambatan dapat membantu Anda menggali lebih dalam masalah yang mendasar. Gambar dan tabel berikut mengilustrasikan proses sinkronisasi data:
Urutan | Deskripsi langkah | Komentar | Metrik yang berguna |
---|---|---|---|
1 | Pembuatan catatan | Data log dihapus ke disk. Log ini harus direplikasi ke replika sekunder. Rekaman log masuk ke dalam antrean kirim. | SQL Server:Byte log basis data > dibersihkan per detik |
2 | Menangkap | Log untuk setiap database dicatat dan dikirim ke antrean mitra yang sesuai (satu per pasangan basis data replika). Proses pengambilan ini berjalan secara terus-menerus selama replika ketersediaan terhubung dan pergerakan data tidak ditangguhkan karena alasan apa pun, dan pasangan replika database ditunjukkan sebagai Menyinkronkan atau Tersinkronkan. Jika proses pengambilan tidak dapat memindai dan mengantrekan pesan dengan cukup cepat, antrean pengiriman log akan menumpuk. |
SQL Server:Availability Replica > Byte Dikirim ke Replika/detik, yang merupakan agregasi dari jumlah semua pesan database yang diantrekan untuk replika ketersediaan tersebut. log_send_queue_size (KB) dan log_bytes_send_rate (KB/detik) pada replika utama. |
3 | Kirim | Pesan dalam setiap antrean replika database dikeluarkan dari antrean dan dikirim melalui jaringan ke replika sekunder masing-masing. | SQL Server:Replika Ketersediaan > Byte yang dikirim ke transport/detik |
4 | Terima dan simpan dalam cache | Setiap replika sekunder menerima dan menyimpan cache pesan. | Penghitung kinerja > |
5 | Mengeras | Log dikosongkan di replika sekunder untuk memastikan daya tahan. Setelah pembersihan log, konfirmasi dikirim kembali ke replika utama. Setelah log diperkeras, kehilangan data dihindari. |
Penghitung kinerja SQL Server:Database > Bytes Log Dibuang/dtk Jenis waktu tunggu HADR_LOGCAPTURE_SYNC |
6 | Mengulangi | Kembalikan halaman yang dihapus pada replika sekunder. Halaman disimpan dalam antrean redo saat menunggu untuk diproses ulang. |
SQL Server:Database Replica > Redone Bytes/detik redo_queue_size (KB) dan redo_rate. Tipe tunggu REDO_SYNC |
Gerbang pengaturan aliran
Grup ketersediaan dirancang dengan gerbang kontrol aliran pada replika utama untuk menghindari konsumsi sumber daya yang berlebihan, seperti sumber daya jaringan dan memori, pada semua replika ketersediaan. Gerbang kontrol alur ini tidak memengaruhi status kesehatan sinkronisasi replika ketersediaan, tetapi dapat memengaruhi performa keseluruhan database ketersediaan Anda, termasuk RPO.
Setelah log diambil pada replika utama, log tunduk pada dua tingkat pengendalian aliran. Setelah ambang pesan dari salah satu gerbang tercapai, pesan log tidak lagi dikirim ke replika tertentu atau untuk database tertentu. Pesan dapat dikirim setelah pesan pengakuan diterima untuk pesan yang dikirim untuk membawa jumlah pesan terkirim di bawah ambang batas.
Selain gerbang kontrol alur, ada faktor lain yang dapat mencegah pesan log dikirim. Sinkronisasi replika memastikan bahwa pesan dikirim dan diterapkan sesuai urutan nomor urut log (LSN). Sebelum pesan log dikirim, LSN-nya juga diperiksa terhadap nomor LSN terendah yang diakui untuk memastikan bahwa LSN tersebut di bawah salah satu ambang batas (tergantung pada jenis pesan). Jika kesenjangan antara dua angka LSN lebih besar dari ambang batas, pesan tidak dikirim. Setelah celah berada di bawah ambang batas lagi, pesan akan dikirim.
SQL Server 2022 (16.x) meningkatkan batasan jumlah pesan yang diizinkan setiap gerbang. Dengan menggunakan Bendera Pelacakan 12310, batas yang ditingkatkan juga tersedia untuk versi SQL Server berikut: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16.
Tabel berikut membandingkan batas pesan:
Untuk versi SQL Server yang mengaktifkan Bendera Pelacakan 12310, yaitu SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16, dan versi yang lebih baru, lihat batas berikut:
Tingkat | Jumlah gerbang | Jumlah pesan | Metrik yang berguna |
---|---|---|---|
Transportasi | 1 per replika ketersediaan | 16384 | Peristiwa Diperluas database_transport_flow_control_action |
Database | 1 per database ketersediaan | 7168 |
DBMIRROR_SEND Peristiwa diperpanjang hadron_database_flow_control_action |
Dua penghitung kinerja yang berguna, SQL Server:Availability Replica > Kontrol Aliran/detik dan SQL Server:Availability Replica > Waktu Kontrol Aliran (ms/detik), menunjukkan kepada Anda, dalam detik terakhir, berapa kali kontrol aliran diaktifkan dan berapa banyak waktu yang dihabiskan untuk menunggu kontrol aliran. Waktu tunggu yang lebih tinggi pada kontrol alur diterjemahkan ke RPO yang lebih tinggi. Untuk informasi selengkapnya tentang jenis masalah yang dapat menyebabkan waktu tunggu yang tinggi pada pengaturan aliran, lihat Memecahkan Masalah: Potensi kehilangan data dengan replika grup ketersediaan dengan komitmen asinkron.
Memperkirakan waktu pemulihan (RTO)
RTO dalam SLA Anda tergantung pada waktu failover dari implementasi Always On Anda pada momen tertentu, yang dapat dinyatakan dengan rumus berikut:
Penting
Jika grup ketersediaan berisi lebih dari satu database ketersediaan, maka database ketersediaan dengan Tfailover tertinggi menjadi nilai pembatasan untuk kepatuhan RTO.
Waktu deteksi kegagalan, Tdetection, adalah waktu yang diperlukan sistem untuk mendeteksi kegagalan. Waktu ini bergantung pada pengaturan tingkat pengelompokan dan bukan pada replika ketersediaan individual. Bergantung pada kondisi failover otomatis yang dikonfigurasi, failover dapat dipicu sebagai respons instan terhadap kesalahan kritikal internal SQL Server, seperti spinlock yatim piatu. Dalam hal ini, deteksi dapat secepat ketika laporan kesalahan sp_server_diagnostics dikirim ke Kluster Failover Windows Server (WSFC). Interval bawaan adalah sepertiga dari batas waktu pemeriksaan kesehatan. Failover juga dapat dipicu karena waktu habis, misalnya ketika waktu habis pemeriksaan kesehatan kluster telah kedaluwarsa (30 detik secara bawaan) atau ketika sewa antara sumber daya DLL dan instans SQL Server telah kedaluwarsa (20 detik secara bawaan). Dalam hal ini, waktu deteksi adalah sepanjang interval waktu habis. Untuk informasi lebih lanjut, lihat Kebijakan failover yang fleksibel untuk otomatisasi failover dalam grup ketersediaan (SQL Server).
Hal satu-satunya yang perlu dilakukan replika sekunder agar siap untuk failover adalah memastikan proses redo menyusul hingga akhir log. Waktu pengulangan, Tredo, dihitung menggunakan rumus berikut:
di mana redo_queue adalah nilai dalam redo_queue_size dan redo_rate adalah nilai dalam redo_rate.
Waktu overhead failover, Toverhead, mencakup waktu yang diperlukan untuk melakukan failover kluster WSFC dan untuk mengaktifkan database. Waktu ini biasanya singkat dan konstan.
Memperkirakan potensi kehilangan data (RPO)
RPO dalam SLA Anda bergantung pada kemungkinan kehilangan data dari implementasi Always On Anda setiap saat. Kemungkinan kehilangan data ini dapat dinyatakan dalam rumus berikut:
di mana log_send_queue adalah nilai log_send_queue_size dan laju pembuatan log adalah nilai SQL Server:Database > Log Bytes Flushed/detik.
Peringatan
Jika grup ketersediaan berisi lebih dari satu database ketersediaan, maka database ketersediaan dengan Tdata_loss tertinggi menjadi nilai pembatasan untuk kepatuhan RPO.
Antrean pengiriman log mewakili semua data yang dapat hilang dari kegagalan bencana. Pada pandangan pertama, menarik bahwa laju pembuatan log digunakan alih-alih laju pengiriman log (lihat log_send_rate). Namun, ingatlah bahwa menggunakan laju pengiriman log hanya memberi Anda waktu untuk disinkronkan, sementara RPO mengukur kehilangan data berdasarkan seberapa cepat itu dihasilkan, bukan pada seberapa cepat disinkronkan.
Cara yang lebih sederhana untuk memperkirakan Tdata_loss adalah dengan menggunakan last_commit_time. DMV pada replika utama melaporkan nilai ini untuk semua replika. Anda dapat menghitung perbedaan antara nilai untuk replika utama dan nilai untuk replika sekunder untuk memperkirakan seberapa cepat log pada replika sekunder mengejar replika utama. Seperti yang dinyatakan sebelumnya, perhitungan ini tidak memberi tahu Anda potensi kehilangan data berdasarkan seberapa cepat log dihasilkan, tetapi seharusnya mendekati.
Memperkirakan RTO dan RPO dengan dasbor SSMS
Di Grup Ketersediaan AlwaysOn, RTO dan RPO dihitung dan ditampilkan untuk database yang dihosting pada replika sekunder. Di dasbor SQL Server Management Studio (SSMS), pada replika utama, RTO dan RPO dikelompokkan oleh replika sekunder.
Untuk melihat RTO dan RPO di dalam dasbor, lakukan langkah-langkah berikut:
Di SQL Server Management Studio, perluas simpul Always On High Availability, klik kanan nama grup ketersediaan Anda, dan pilih Tampilkan Dasbor.
Pilih Tambahkan/Hapus Kolom di bawah tab Kelompokkan menurut . Periksa Perkiraan Waktu Pemulihan(detik) [RTO] dan Perkiraan Kehilangan Data (waktu) [RPO].
Perhitungan RTO basis data sekunder
Perhitungan waktu pemulihan menentukan berapa banyak waktu yang diperlukan untuk memulihkan database sekunder setelah failover terjadi. Waktu failover biasanya pendek dan konstan. Waktu deteksi tergantung pada pengaturan tingkat kluster dan bukan pada replika ketersediaan individual.
Untuk database sekunder (DB_sec
), perhitungan dan tampilan RTO-nya didasarkan pada redo_queue_size
dan redo_rate
:
Kecuali kasus sudut, rumus untuk menghitung RTO database sekunder adalah:
Perhitungan RPO (Recovery Point Objective) untuk database sekunder
Untuk database sekunder (DB_sec
), perhitungan dan tampilan RPO-nya didasarkan pada is_failover_ready
, , last_commit_time
dan nilai database utama (DB_pri
) last_commit_time
yang berkorelasi. Ketika nilai DB_sec.is_failover_ready
adalah 1
, maka data antara primer dan sekunder disinkronkan, dan tidak ada kehilangan data yang terjadi setelah failover. Namun, jika nilai ini adalah 0
, maka ada kesenjangan antara last_commit_time
pada database utama dan last_commit_time
pada database sekunder.
Untuk database utama, last_commit_time
adalah waktu ketika transaksi terbaru telah dilakukan. Untuk database sekunder, last_commit_time
adalah waktu komit terbaru untuk transaksi dari database utama yang telah berhasil disimpan secara permanen pada database sekunder. Angka ini sama untuk database utama dan sekunder. Namun, kesenjangan antara kedua nilai ini adalah durasi di mana transaksi yang tertunda belum diperkeras pada database sekunder, dan mungkin hilang jika terjadi failover.
Metrik performa yang digunakan dalam rumus RTO/RPO
redo_queue_size
(KB): Ukuran antrean redo, yang digunakan dalam RTO, adalah ukuran log transaksi di antaralast_received_lsn
danlast_redone_lsn
. Nilainyalast_received_lsn
adalah ID blok log yang mengidentifikasi titik di mana semua blok log telah diterima oleh replika sekunder yang menghosting database sekunder ini. Nilailast_redone_lsn
adalah nomor urutan log dari rekaman log terakhir yang direbus pada database sekunder. Berdasarkan kedua nilai ini, kita dapat menemukan ID blok log awal (last_received_lsn
) dan blok log akhir (last_redone_lsn
). Ruang antara kedua blok log ini kemudian dapat mewakili berapa banyak blok log transaksi yang belum di-redone. Ini diukur dalam Kilobyte(KB).redo_rate
(KB/detik): Digunakan dalam perhitungan RTO, ini adalah nilai kumulatif yang menunjukkan berapa banyak log transaksi (KB) yang telah direone atau diputar ulang pada database sekunder per detik.last_commit_time
(tanggalwaktu): Digunakan dalam RPO, nilai ini memiliki arti yang berbeda antara database utama dan sekunder. Untuk database utama,last_commit_time
adalah waktu ketika transaksi terbaru dilakukan. Untuk database sekunder,last_commit_time
adalah penerapan terbaru untuk transaksi pada database utama yang berhasil diperkuat pada database sekunder juga. Karena nilai ini pada sekunder harus disinkronkan dengan nilai yang sama pada primer, kesenjangan apa pun antara kedua nilai ini adalah perkiraan kehilangan data (RPO).
Memperkirakan RTO dan RPO menggunakan DMV
Dimungkinkan untuk membuat kueri DMV sys.dm_hadr_database_replica_states dan sys.dm_hadr_database_replica_cluster_states untuk memperkirakan RPO dan RTO dari sebuah database. Kueri di bawah ini membuat prosedur tersimpan yang menyelesaikan kedua hal tersebut.
Catatan
Pastikan untuk membuat dan menjalankan prosedur tersimpan untuk memperkirakan RTO terlebih dahulu, karena nilai yang dihasilkannya diperlukan untuk menjalankan prosedur tersimpan untuk memperkirakan RPO.
Membuat prosedur tersimpan untuk memperkirakan RTO
Pada replika sekunder target, buat prosedur tersimpan
proc_calculate_RTO
. Jika prosedur simpanan ini sudah ada, hapus dahulu, lalu buat ulang.IF object_id(N'proc_calculate_RTO', 'p') IS NOT NULL DROP PROCEDURE proc_calculate_RTO; GO RAISERROR ('creating procedure proc_calculate_RTO', 0, 1) WITH NOWAIT; GO -- name: proc_calculate_RTO -- -- description: Calculate RTO of a secondary database. -- -- parameters: @secondary_database_name nvarchar(max): name of the secondary database. -- -- security: this is a public interface object. -- CREATE PROCEDURE proc_calculate_RTO @secondary_database_name NVARCHAR (MAX) AS BEGIN DECLARE @db AS sysname; DECLARE @is_primary_replica AS BIT; DECLARE @is_failover_ready AS BIT; DECLARE @redo_queue_size AS BIGINT; DECLARE @redo_rate AS BIGINT; DECLARE @replica_id AS UNIQUEIDENTIFIER; DECLARE @group_database_id AS UNIQUEIDENTIFIER; DECLARE @group_id AS UNIQUEIDENTIFIER; DECLARE @RTO AS FLOAT; SELECT @is_primary_replica = dbr.is_primary_replica, @is_failover_ready = dbcs.is_failover_ready, @redo_queue_size = dbr.redo_queue_size, @redo_rate = dbr.redo_rate, @replica_id = dbr.replica_id, @group_database_id = dbr.group_database_id, @group_id = dbr.group_id FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbcs.database_name = @secondary_database_name; IF @is_primary_replica IS NULL OR @is_failover_ready IS NULL OR @redo_queue_size IS NULL OR @replica_id IS NULL OR @group_database_id IS NULL OR @group_id IS NULL BEGIN PRINT 'RTO of Database ' + @secondary_database_name + ' is not available'; RETURN; END ELSE IF @is_primary_replica = 1 BEGIN PRINT 'You are visiting wrong replica'; RETURN; END IF @redo_queue_size = 0 SET @RTO = 0; ELSE IF @redo_rate IS NULL OR @redo_rate = 0 BEGIN PRINT 'RTO of Database ' + @secondary_database_name + ' is not available'; RETURN; END ELSE SET @RTO = CAST (@redo_queue_size AS FLOAT) / @redo_rate; PRINT 'RTO of Database ' + @secondary_database_name + ' is ' + CONVERT (VARCHAR, ceiling(@RTO)); PRINT 'group_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @group_id); PRINT 'replica_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @replica_id); PRINT 'group_database_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @group_database_id); END
Jalankan
proc_calculate_RTO
dengan nama database sekunder target:EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
Output menampilkan nilai RTO dari database replika sekunder target. Simpan group_id, replica_id, dan group_database_id untuk digunakan dengan prosedur tersimpan estimasi RPO.
Contoh Output:
RTO of Database DB_sec' is 0 group_id of Database DB4 is F176DD65-C3EE-4240-BA23-EA615F965C9B replica_id of Database DB4 is 405554F6-3FDC-4593-A650-2067F5FABFFD group_database_id of Database DB4 is 39F7942F-7B5E-42C5-977D-02E7FFA6C392
Membuat prosedur tersimpan untuk memperkirakan RPO
Pada replika utama, buat prosedur tersimpan
proc_calculate_RPO
. Jika sudah ada, hapus terlebih dahulu, lalu buat ulang.IF object_id(N'proc_calculate_RPO', 'p') IS NOT NULL DROP PROCEDURE proc_calculate_RPO; GO RAISERROR ('creating procedure proc_calculate_RPO', 0, 1) WITH NOWAIT; GO -- name: proc_calculate_RPO -- -- description: Calculate RPO of a secondary database. -- -- parameters: @group_id uniqueidentifier: group_id of the secondary database. -- @replica_id uniqueidentifier: replica_id of the secondary database. -- @group_database_id uniqueidentifier: group_database_id of the secondary database. -- -- security: this is a public interface object. -- CREATE PROCEDURE proc_calculate_RPO @group_id UNIQUEIDENTIFIER, @replica_id UNIQUEIDENTIFIER, @group_database_id UNIQUEIDENTIFIER AS BEGIN DECLARE @db_name AS sysname; DECLARE @is_primary_replica AS BIT; DECLARE @is_failover_ready AS BIT; DECLARE @is_local AS BIT; DECLARE @last_commit_time_sec AS DATETIME; DECLARE @last_commit_time_pri AS DATETIME; DECLARE @RPO AS NVARCHAR (MAX); SELECT @db_name = dbcs.database_name, @is_failover_ready = dbcs.is_failover_ready, @last_commit_time_sec = dbr.last_commit_time FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbr.group_id = @group_id AND dbr.replica_id = @replica_id AND dbr.group_database_id = @group_database_id; SELECT @last_commit_time_pri = dbr.last_commit_time, @is_local = dbr.is_local FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbr.group_id = @group_id AND dbr.is_primary_replica = 1 AND dbr.group_database_id = @group_database_id; IF @is_local IS NULL OR @is_failover_ready IS NULL BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END IF @is_local = 0 BEGIN PRINT 'You are visiting wrong replica'; RETURN; END IF @is_failover_ready = 1 SET @RPO = '00:00:00'; ELSE IF @last_commit_time_sec IS NULL OR @last_commit_time_pri IS NULL BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END ELSE BEGIN IF DATEDIFF(ss, @last_commit_time_sec, @last_commit_time_pri) < 0 BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END ELSE SET @RPO = CONVERT (VARCHAR, DATEADD(ms, datediff(ss, @last_commit_time_sec, @last_commit_time_pri) * 1000, 0), 114); END PRINT 'RPO of database ' + @db_name + ' is ' + @RPO; END -- secondary database's last_commit_time -- correlated primary database's last_commit_time
Jalankan
proc_calculate_RPO
dengan group_id, replica_id, dan group_database_id pada target database sekunder.EXECUTE proc_calculate_RPO @group_id = 'F176DD65-C3EE-4240-BA23-EA615F965C9B', @replica_id = '405554F6-3FDC-4593-A650-2067F5FABFFD', @group_database_id = '39F7942F-7B5E-42C5-977D-02E7FFA6C392';
Output menampilkan nilai RPO dari database replika sekunder target.
Memantau RTO dan RPO
Bagian ini menunjukkan cara memantau grup ketersediaan Anda untuk metrik RTO dan RPO. Demonstrasi ini mirip dengan tutorial GUI yang diberikan dalam model kesehatan Always On, bagian 2: Memperluas model kesehatan.
Elemen waktu failover dan potensi perhitungan kehilangan data dalam Memperkirakan waktu failover (RTO) dan Memperkirakan potensi kehilangan data (RPO) disediakan dengan nyaman sebagai metrik performa dalam Status Replika Database faset manajemen kebijakan. Untuk informasi selengkapnya, lihat Menampilkan faset Manajemen Berbasis Kebijakan pada Objek SQL Server. Anda dapat memantau kedua metrik ini sesuai jadwal dan diberi tahu ketika metrik melebihi RTO dan RPO Anda.
Skrip yang ditunjukkan membuat dua kebijakan sistem yang dijalankan pada jadwal masing-masing, dengan karakteristik berikut:
Kebijakan RTO yang gagal ketika perkiraan waktu failover melebihi 10 menit, dievaluasi setiap 5 menit
Kebijakan RPO yang gagal ketika perkiraan kehilangan data melebihi 1 jam, dievaluasi setiap 30 menit
Kedua kebijakan memiliki konfigurasi identik pada semua replika ketersediaan.
Evaluasi kebijakan dilakukan di semua server, tetapi hanya pada grup ketersediaan di mana replika ketersediaan lokal adalah replika utama. Jika replika ketersediaan lokal bukan replika utama, kebijakan tidak dievaluasi.
Kegagalan kebijakan ditampilkan dengan nyaman di Always On Dashboard ketika Anda melihatnya pada replika utama.
Untuk membuat kebijakan, ikuti instruksi ini pada semua instans server yang berpartisipasi dalam grup ketersediaan:
Mulai layanan SQL Server Agent jika belum dimulai.
Di SQL Server Management Studio, dari menu Alat , pilih Opsi.
Di tab SQL Server Always On , pilih Aktifkan kebijakan AlwaysOn yang ditentukan pengguna dan pilih OK.
Pengaturan ini memungkinkan Anda menampilkan kebijakan kustom yang dikonfigurasi dengan benar di Dasbor AlwaysOn.
Buat kondisi manajemen berbasis kebijakan menggunakan spesifikasi berikut:
-
Nama:
RTO
- Faset: Keadaan Replika Database
-
Bidang:
Add(@EstimatedRecoveryTime, 60)
- Operator: <=
-
Nilai:
600
Kondisi ini gagal ketika waktu failover yang potensial melebihi 10 menit, termasuk tambahan waktu 60 detik untuk deteksi kegagalan dan failover.
-
Nama:
Buat kondisi manajemen berbasis kebijakan kedua menggunakan spesifikasi berikut:
-
Nama:
RPO
- Faset: Keadaan Replika Database
-
Bidang:
@EstimatedDataLoss
- Operator: <=
-
Nilai:
3600
Kondisi ini gagal ketika potensi kehilangan data melebihi 1 jam.
-
Nama:
Buat kondisi manajemen berbasis kebijakan ketiga menggunakan spesifikasi berikut:
-
Nama:
IsPrimaryReplica
- Faset: Grup Ketersediaan
-
Bidang:
@LocalReplicaRole
- Operator: =
-
Nilai:
Primary
Kondisi ini memeriksa apakah replika ketersediaan lokal untuk grup ketersediaan tertentu adalah replika utama.
-
Nama:
Buat kebijakan manajemen berbasis kebijakan menggunakan spesifikasi berikut:
Halaman umum :
Nama:
CustomSecondaryDatabaseRTO
Periksa kondisi:
RTO
Terhadap target: Setiap DatabaseReplicaState di IsPrimaryReplica AvailabilityGroup
Pengaturan ini memastikan bahwa kebijakan hanya dievaluasi pada grup ketersediaan di mana replika ketersediaan lokal adalah replika utama.
Evaluasi mode: Sesuai jadwal
Jadwal: JadwalPengumpul_Setiap_5menit
Diaktifkan: dipilih
Halaman deskripsi :
Kategori: Peringatan database ketersediaan
Pengaturan ini memungkinkan hasil evaluasi kebijakan ditampilkan di Dasbor AlwaysOn.
Deskripsi: Replika saat ini memiliki RTO yang melebihi 10 menit, dengan asumsi overhead 1 menit untuk penemuan dan failover. Anda harus segera menyelidiki masalah kinerja pada instans server yang bersangkutan.
Teks yang akan ditampilkan: RTO (Waktu Penundaan Terlampaui)
Buat kebijakan manajemen berbasis kebijakan kedua menggunakan spesifikasi berikut:
Halaman umum :
-
Nama:
CustomAvailabilityDatabaseRPO
-
Periksa kondisi:
RPO
- Melawan target: Setiap DatabaseReplicaState dalam Kelompok Ketersediaan IsPrimaryReplica
- Evaluasi mode: Sesuai jadwal
- Jadwal: Jadwal Kolektor Setiap 30 Menit
- Diaktifkan: dipilih
-
Nama:
Halaman deskripsi :
Kategori: Peringatan database ketersediaan
Deskripsi: Database ketersediaan telah melebihi RPO Anda 1 jam. Anda harus segera menyelidiki masalah performa pada replika ketersediaan.
Teks yang akan ditampilkan: RPO Terlampaui!
Setelah Anda selesai, dua tugas Agen SQL Server baru akan dibuat, masing-masing untuk setiap jadwal evaluasi kebijakan. Pekerjaan ini harus memiliki nama yang dimulai dengan syspolicy_check_schedule
.
Anda dapat melihat riwayat pekerjaan untuk memeriksa hasil evaluasi. Kegagalan evaluasi juga dicatat di log aplikasi Windows (di Pemantau Peristiwa) dengan ID Peristiwa 34052. Anda juga dapat mengonfigurasi SQL Server Agent untuk mengirim pemberitahuan tentang kegagalan kebijakan. Untuk informasi selengkapnya, lihat Mengonfigurasi Pemberitahuan untuk Memberi Tahu Administrator Kebijakan tentang Kegagalan Kebijakan.
Skenario pemecahan masalah performa
Tabel berikut mencantumkan skenario pemecahan masalah terkait performa umum.
Skenario | Deskripsi |
---|---|
Pemecahan masalah: Grup ketersediaan melebihi RTO | Setelah failover otomatis atau failover manual yang direncanakan tanpa kehilangan data, waktu failover melebihi Waktu Pemulihan yang Ditargetkan (RTO) Anda. Atau, ketika Anda memperkirakan durasi waktu failover replika sekunder dengan komitmen sinkron (seperti mitra failover otomatis), Anda mendapati bahwa durasinya melebihi target RTO Anda. |
Mengatasi masalah: Grup ketersediaan melebihi RPO | Setelah Anda melakukan failover manual paksa, kehilangan data Anda lebih dari RPO Anda. Atau, ketika Anda menghitung potensi kehilangan data dari replika sekunder dengan komit asinkron, Anda menemukan bahwa itu melebihi RPO Anda. |
Pemecahan masalah: Perubahan pada replika utama tidak tercermin pada replika sekunder | Aplikasi klien berhasil menyelesaikan pembaruan pada replika utama, tetapi mengkueri replika sekunder menunjukkan bahwa perubahan tidak tercermin. |
Peristiwa tambahan yang berguna
Peristiwa yang diperluas berikut ini berguna saat memecahkan masalah replika dalam status Sinkronisasi .
Nama Acara | Kategori | Saluran | Replika ketersediaan |
---|---|---|---|
redo_caught_up |
transaksi | Pemecahan Kesalahan | Sekunder |
redo_worker_entry |
transaksi | Pemecahan Kesalahan | Sekunder |
hadr_transport_dump_message |
alwayson |
Pemecahan Kesalahan | Primer |
hadr_worker_pool_task |
alwayson |
Pemecahan Kesalahan | Primer |
hadr_dump_primary_progress |
alwayson |
Pemecahan Kesalahan | Primer |
hadr_dump_log_progress |
alwayson |
Pemecahan Kesalahan | Primer |
hadr_undo_of_redo_log_scan |
alwayson |
Analitik | Sekunder |