Ketersediaan tinggi dan perlindungan data untuk konfigurasi grup ketersediaan

Berlaku untuk:SQL Server - Linux

Artikel ini menyajikan konfigurasi penyebaran yang didukung untuk grup ketersediaan AlwaysOn SQL Server di server Linux. Grup ketersediaan mendukung ketersediaan tinggi dan perlindungan data. Deteksi kegagalan otomatis, failover otomatis, dan koneksi ulang transparan setelah failover memberikan ketersediaan tinggi. Replika yang disinkronkan memberikan perlindungan data.

Pada Windows Server Failover Cluster (WSFC), konfigurasi umum untuk ketersediaan tinggi menggunakan dua replika sinkron dan server ketiga atau berbagi file untuk menyediakan kuorum. Saksi berbagi file memvalidasi konfigurasi grup ketersediaan - status sinkronisasi, dan peran replika, misalnya. Konfigurasi ini memastikan bahwa replika sekunder yang dipilih sebagai target failover memiliki perubahan konfigurasi data dan grup ketersediaan terbaru.

WSFC menyinkronkan metadata konfigurasi untuk arbitrase failover antara replika grup ketersediaan dan bukti berbagi file. Ketika grup ketersediaan tidak berada di WSFC, instans SQL Server menyimpan metadata konfigurasi dalam master database.

Misalnya, grup ketersediaan pada kluster Linux memiliki CLUSTER_TYPE = EXTERNAL. Tidak ada WSFC untuk melakukan arbitrase failover. Dalam hal ini metadata konfigurasi dikelola dan dikelola oleh instans SQL Server. Karena tidak ada server bukti dalam kluster ini, instans SQL Server ketiga diperlukan untuk menyimpan metadata status konfigurasi. Ketiga instans SQL Server bersama-sama menyediakan penyimpanan metadata terdistribusi untuk kluster.

Manajer kluster dapat mengkueri instans SQL Server dalam grup ketersediaan, dan mengatur failover untuk mempertahankan ketersediaan tinggi. Dalam kluster Linux, Pacemaker adalah manajer kluster.

SQL Server 2017 CU 1 memungkinkan ketersediaan tinggi untuk grup ketersediaan dengan CLUSTER_TYPE = EXTERNAL untuk dua replika sinkron ditambah replika konfigurasi saja. Replika konfigurasi hanya dapat dihosting pada edisi SQL Server 2017 CU1 atau yang lebih baru - termasuk edisi SQL Server Express. Replika konfigurasi hanya mempertahankan informasi konfigurasi tentang grup ketersediaan dalam master database tetapi tidak berisi database pengguna dalam grup ketersediaan.

Bagaimana konfigurasi memengaruhi pengaturan sumber daya default

SQL Server 2017 memperkenalkan REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT pengaturan sumber daya kluster. Pengaturan ini menjamin jumlah replika sekunder yang ditentukan menulis data transaksi untuk dicatat sebelum replika utama menerapkan setiap transaksi. Saat Anda menggunakan manajer kluster eksternal, pengaturan ini memengaruhi ketersediaan tinggi dan perlindungan data. Nilai default untuk pengaturan tergantung pada arsitektur pada saat sumber daya kluster dibuat. Saat Anda menginstal agen sumber daya SQL Server - - mssql-server-ha dan membuat sumber daya kluster untuk grup ketersediaan, manajer kluster mendeteksi konfigurasi dan set REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT grup ketersediaan yang sesuai.

Jika didukung oleh konfigurasi, parameter REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT agen sumber daya diatur ke nilai yang memberikan ketersediaan tinggi dan perlindungan data. Untuk informasi selengkapnya, lihat Memahami agen sumber daya SQL Server untuk pacemaker.

Bagian berikut menjelaskan perilaku default untuk sumber daya kluster.

Pilih desain grup ketersediaan untuk memenuhi persyaratan bisnis tertentu untuk ketersediaan tinggi, perlindungan data, dan skala baca.

Konfigurasi berikut menjelaskan pola desain grup ketersediaan dan kemampuan setiap pola. Pola desain ini berlaku untuk grup ketersediaan dengan CLUSTER_TYPE = EXTERNAL solusi ketersediaan tinggi.

• Tiga replika sinkron
• Dua replika sinkron
• Dua replika sinkron dan replika konfigurasi saja

Tiga replika sinkron

Konfigurasi ini terdiri dari tiga replika sinkron. Secara default, ini memberikan ketersediaan tinggi dan perlindungan data. Ini juga dapat menyediakan skala baca.

Grup ketersediaan dengan tiga replika sinkron dapat memberikan skala baca, ketersediaan tinggi, dan perlindungan data. Tabel berikut ini menjelaskan perilaku ketersediaan.

Perilaku ketersediaan	baca-skala	Ketersediaan tinggi & perlindungan data	Perlindungan data
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0	1 1	2
Pemadaman utama	Failover otomatis. Mungkin kehilangan data. Primer baru adalah R/W.	Failover otomatis. Primer baru adalah R/W.	Failover otomatis. Primer baru tidak tersedia untuk transaksi pembaruan pengguna hingga mantan primer pulih dan bergabung dengan grup ketersediaan sebagai sekunder.
Satu pemadaman replika sekunder	Primer adalah R/W.	Primer adalah R/W.	Primer tidak tersedia untuk transaksi pembaruan pengguna hingga sekunder gagal pulih dan bergabung dengan grup ketersediaan.

¹ Default

Dua replika sinkron

Konfigurasi ini memungkinkan perlindungan data. Seperti konfigurasi grup ketersediaan lainnya, ini dapat mengaktifkan skala baca. Dua konfigurasi replika sinkron tidak memberikan ketersediaan tinggi otomatis. Dua konfigurasi replika hanya berlaku untuk SQL Server 2017 RTM dan tidak lagi didukung dengan versi SQL Server 2017 yang lebih tinggi (CU1 dan seterusnya).

Grup ketersediaan dengan dua replika sinkron memberikan perlindungan skala baca dan data. Tabel berikut ini menjelaskan perilaku ketersediaan.

Perilaku ketersediaan	baca-skala	Perlindungan data
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Pemadaman utama	Failover otomatis. Mungkin kehilangan data. Primer baru adalah R/W.	Failover otomatis. Primer baru tidak tersedia untuk transaksi pembaruan pengguna hingga mantan primer pulih dan bergabung dengan grup ketersediaan sebagai sekunder.
Satu pemadaman replika sekunder	Primer adalah R/W, berjalan terpapar kehilangan data.	Primer tidak tersedia untuk transaksi pembaruan pengguna hingga sekunder pulih.

¹ Default

Dua replika sinkron dan replika konfigurasi saja

Grup ketersediaan dengan dua (atau lebih) replika sinkron dan replika konfigurasi hanya memberikan perlindungan data dan mungkin juga memberikan ketersediaan tinggi. Diagram berikut mewakili arsitektur ini:

1. Replikasi data pengguna yang sinkron ke replika sekunder. Ini juga mencakup metadata konfigurasi grup ketersediaan.
2. Replikasi sinkron metadata konfigurasi grup ketersediaan. Ini tidak termasuk data pengguna.

Dalam diagram grup ketersediaan, replika utama mendorong data konfigurasi ke replika sekunder dan replika konfigurasi saja. Replika sekunder juga menerima data pengguna. Replika konfigurasi saja tidak menerima data pengguna. Replika sekunder dalam mode ketersediaan sinkron. Replika konfigurasi saja tidak berisi database dalam grup ketersediaan - hanya metadata tentang grup ketersediaan. Data konfigurasi pada replika konfigurasi saja diterapkan secara sinkron.

Catatan

Grup ketersediaan dengan replika konfigurasi saja baru untuk SQL Server 2017 CU1. Semua instans SQL Server dalam grup ketersediaan harus SQL Server 2017 CU1 atau yang lebih baru.

Nilai default untuk REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT adalah 0. Tabel berikut ini menjelaskan perilaku ketersediaan.

Perilaku ketersediaan	Ketersediaan tinggi & perlindungan data	Perlindungan data
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Pemadaman utama	Failover otomatis. Primer baru adalah R/W. Mungkin kehilangan data.	Failover otomatis. Primer baru tidak tersedia untuk transaksi pembaruan pengguna.
Pemadaman replika sekunder	Primer adalah R/W, berjalan terpapar kehilangan data (jika primer gagal dan tidak dapat dipulihkan). Tidak ada failover otomatis jika primer juga gagal.	Primer tidak tersedia untuk transaksi pembaruan pengguna. Tidak ada replika yang gagal jika primer juga gagal.
Pemadaman replika hanya konfigurasi	Primer adalah R/W. Tidak ada failover otomatis jika primer juga gagal.	Primer adalah R/W. Tidak ada failover otomatis jika primer juga gagal.
Pemadaman replika sekunder + konfigurasi sinkron saja	Primer tidak tersedia untuk transaksi pembaruan pengguna. Tidak ada failover otomatis.	Primer tidak tersedia untuk transaksi pembaruan pengguna. Tidak ada replika untuk failover jika primer juga gagal.

¹ Default

Catatan

Instans SQL Server yang menghosting replika konfigurasi saja juga dapat menghosting database lain. Ini juga dapat berpartisipasi sebagai database konfigurasi saja untuk lebih dari satu grup ketersediaan.

Persyaratan

• Semua replika dalam grup ketersediaan dengan replika konfigurasi saja harus SQL Server 2017 CU 1 atau yang lebih baru.
• Edisi SQL Server apa pun dapat menghosting replika konfigurasi saja, termasuk SQL Server Express.
• Grup ketersediaan membutuhkan setidaknya satu replika sekunder - selain replika utama.
• Hanya replika konfigurasi yang tidak dihitung dalam jumlah maksimum replika per instans SQL Server. Edisi standar SQL Server memungkinkan hingga tiga replika, SQL Server Enterprise Edition memungkinkan hingga 9.

Pertimbangan

• Tidak lebih dari satu replika konfigurasi hanya per grup ketersediaan.
• Replika konfigurasi saja tidak dapat menjadi replika utama.
• Anda tidak dapat mengubah mode ketersediaan replika konfigurasi saja. Untuk mengubah dari replika konfigurasi saja ke replika sekunder sinkron atau asinkron, hapus replika konfigurasi saja, dan tambahkan replika sekunder dengan mode ketersediaan yang diperlukan.
• Replika konfigurasi saja sinkron dengan metadata grup ketersediaan. Tidak ada data pengguna.
• Grup ketersediaan dengan satu replika utama dan satu replika hanya konfigurasi, tetapi tidak ada replika sekunder yang tidak valid.
• Anda tidak dapat membuat grup ketersediaan pada instans edisi SQL Server Express.

Memahami agen sumber daya SQL Server untuk Pacemaker

SQL Server 2017 (14.x) diperkenalkan sequence_number untuk sys.availability_groups menunjukkan apakah replika yang ditandai sebagai SYNCHRONOUS_COMMIT sudah diperbarui. sequence_number adalah BIGINT yang meningkat secara monoton yang menunjukkan seberapa terbaru replika grup ketersediaan lokal sehubungan dengan replika lainnya dalam grup ketersediaan. Melakukan failover, menambahkan atau menghapus replika, dan operasi grup ketersediaan lainnya memperbarui nomor ini. Angka diperbarui pada replika utama, lalu didorong ke replika sekunder. Dengan demikian replika sekunder yang diperbarui memiliki yang sama sequence_number dengan replika utama.

Ketika Pacemaker memutuskan untuk mempromosikan replika ke primer, Pacemaker pertama-tama mengirim pemberitahuan ke semua replika untuk mengekstrak nomor urut dan menyimpannya (pemberitahuan ini disebut pemberitahuan pra-promosi). Selanjutnya, ketika Pacemaker mencoba mempromosikan replika ke primer, replika hanya mempromosikan dirinya sendiri jika angka urutannya adalah yang tertinggi dari semua angka urutan dari semua replika, jika tidak, replika menolak operasi promosi. Dengan cara ini hanya replika dengan nomor urutan tertinggi yang dapat dipromosikan ke primer, memastikan tidak ada kehilangan data.

Promosi hanya dijamin berfungsi selama setidaknya satu replika yang tersedia untuk promosi memiliki nomor urut yang sama dengan primer sebelumnya. Perilaku default adalah agar agen sumber daya Pacemaker secara otomatis mengatur REQUIRED_COPIES_TO_COMMIT sehingga setidaknya satu replika sekunder penerapan sinkron sudah diperbarui dan tersedia, untuk menjadi target failover otomatis. Dengan setiap tindakan pemantauan, nilai REQUIRED_COPIES_TO_COMMIT dihitung (dan diperbarui jika perlu) sebagai ('jumlah replika penerapan sinkron' / 2). Kemudian, pada waktu failover, agen sumber daya memerlukan (total number of replicas - required_copies_to_commit replika) untuk menanggapi pemberitahuan pra-promosi untuk dapat mempromosikan salah satunya ke primer. Replika dengan yang tertinggi sequence_number dipromosikan ke primer.

Misalnya, mari kita pertimbangkan kasus grup ketersediaan dengan tiga replika sinkron - satu replika utama dan dua replika sekunder penerapan sinkron.

• REQUIRED_COPIES_TO_COMMIT adalah 3 / 2 = 1

• Jumlah replika yang diperlukan untuk merespons tindakan prapromosikan adalah 3 - 1 = 2. Jadi dua replika harus siap untuk failover yang akan dipicu. Ketika pemadaman utama terjadi, jika salah satu replika sekunder tidak responsif dan hanya salah satu sekunder yang merespons tindakan prapromosikan, agen sumber daya tidak dapat menjamin bahwa sekunder yang merespons memiliki yang tertinggi sequence_number, dan failover tidak dipicu.

Pengguna dapat memilih untuk mengambil alih perilaku default, dan mengonfigurasi sumber daya grup ketersediaan agar tidak diatur REQUIRED_COPIES_TO_COMMIT secara otomatis seperti yang ditunjukkan sebelumnya.

Penting

0 Kapan REQUIRED_COPIES_TO_COMMIT ada risiko kehilangan data. Dalam kasus pemadaman primer, agen sumber daya tidak akan secara otomatis memicu failover. Pengguna harus memutuskan apakah mereka ingin menunggu primer pulih atau gagal secara manual.

Untuk mengatur REQUIRED_COPIES_TO_COMMIT ke 0, jalankan:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Perintah yang setara menggunakan crm (pada SLES) adalah:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Untuk kembali ke nilai komputasi default, jalankan:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Catatan

Memperbarui properti sumber daya menyebabkan semua replika berhenti dan memulai ulang. Ini berarti primer untuk sementara akan diturunkan ke sekunder, kemudian dipromosikan lagi yang akan menyebabkan tidak tersedianya penulisan sementara. Nilai baru untuk REQUIRED_COPIES_TO_COMMIT hanya akan diatur setelah replika dimulai ulang, sehingga tidak akan seketika dengan menjalankan perintah pcs .

Menyeimbangkan ketersediaan tinggi dan perlindungan data

Perilaku default di atas berlaku untuk kasus dua replika sinkron (primer + sekunder) juga. Pacemaker default REQUIRED_COPIES_TO_COMMIT = 1 untuk memastikan replika sekunder selalu diperbarui untuk perlindungan data maksimum.

Peringatan

Ini datang dengan risiko tidak tersedianya replika utama yang lebih tinggi karena pemadaman yang direncanakan atau tidak direncanakan pada sekunder. Pengguna dapat memilih untuk mengubah perilaku default agen sumber daya dan mengambil alih REQUIRED_COPIES_TO_COMMIT ke 0:

sudo pcs resource update <ag1> required_copies_to_commit=0

Setelah ditimpa, agen sumber daya menggunakan pengaturan baru untuk REQUIRED_COPIES_TO_COMMIT dan berhenti menghitungnya. Pengguna harus memperbaruinya secara manual (misalnya, jika mereka meningkatkan jumlah replika).

Tabel berikut menjelaskan hasil pemadaman untuk replika primer atau sekunder dalam konfigurasi sumber daya grup ketersediaan yang berbeda:

Grup ketersediaan - dua replika sinkronisasi

Konfigurasi	Pemadaman utama	Satu pemadaman replika sekunder
REQUIRED_COPIES_TO_COMMIT = 0	Pengguna harus mengeluarkan manual FAILOVER. Mungkin kehilangan data. Primer baru adalah R/W	Primer adalah R/W, berjalan terpapar kehilangan data.
REQUIRED_COPIES_TO_COMMIT = 11	Masalah kluster secara otomatis FAILOVER Tidak ada kehilangan data. Primer baru menolak semua koneksi sampai mantan primer pulih dan bergabung dengan grup ketersediaan sebagai sekunder.	Primer menolak semua koneksi hingga sekunder pulih.

¹ Agen sumber daya SQL Server untuk perilaku default Pacemaker.

Grup ketersediaan - tiga replika sinkronisasi

Konfigurasi	Pemadaman utama	Satu pemadaman replika sekunder
REQUIRED_COPIES_TO_COMMIT = 0	Pengguna harus mengeluarkan manual FAILOVER. Mungkin kehilangan data. Primer baru adalah R/W	Primer adalah R/W
REQUIRED_COPIES_TO_COMMIT = 11	Kluster secara otomatis mengeluarkan FAILOVER. Tidak ada kehilangan data. Primer baru adalah RW	Primer adalah R/W

¹ Agen sumber daya SQL Server untuk perilaku default Pacemaker.

Konten terkait

• Grup ketersediaan di Linux