Grup ketersediaan untuk SQL Server on Linux

Aplikasi ke:SQL Server di Linux

Artikel ini menjelaskan karakteristik grup ketersediaan (AG) di bawah penginstalan SQL Server berbasis Linux. Ini juga mencakup perbedaan antara AG yang berbasis kluster failover Linux dan yang berbasis kluster failover Windows Server (WSFC). Lihat Apa itu grup ketersediaan AlwaysOn? untuk dasar-dasar AG, karena mereka bekerja sama di Windows dan Linux kecuali untuk WSFC.

Catatan

Dalam grup ketersediaan yang tidak menggunakan Windows Server Failover Clustering (WSFC), seperti kelompok ketersediaan skala baca, atau grup ketersediaan di Linux, kolom di kelompok ketersediaan DMV terkait dengan kluster mungkin menampilkan data tentang kluster default internal. Kolom ini hanya untuk penggunaan internal dan dapat diabaikan.

Dari sudut pandang tingkat tinggi, grup ketersediaan di bawah SQL Server on Linux sama seperti pada implementasi berbasis WSFC. Itu berarti bahwa semua batasan dan fitur sama, dengan beberapa pengecualian. Perbedaan utamanya meliputi:

• Microsoft Distributed Transaction Coordinator (DTC) didukung di bawah Linux yang dimulai dengan SQL Server 2017 CU 16. Namun, DTC belum didukung pada Grup Ketersediaan di Linux. Jika aplikasi Anda memerlukan penggunaan transaksi terdistribusi dan memerlukan AG, sebarkan SQL Server pada Windows.
• Penyebaran berbasis Linux yang memerlukan ketersediaan tinggi menggunakan Pacemaker untuk pengklusteran alih-alih WSFC.
• Tidak seperti kebanyakan konfigurasi untuk AG pada Windows kecuali untuk skenario Kluster Grup Kerja, Pacemaker tidak pernah memerlukan Active Directory Domain Services (AD DS).
• Cara melakukan failover AG dari satu node ke node lainnya berbeda antara Linux dan Windows.
• Pengaturan tertentu seperti required_synchronized_secondaries_to_commit hanya dapat diubah melalui Pacemaker di Linux, sedangkan penginstalan berbasis WSFC menggunakan Transact-SQL.

Jumlah replika dan node kluster

AG dalam edisi standar SQL Server dapat memiliki dua replika total: satu primer, dan satu sekunder yang hanya dapat digunakan untuk tujuan ketersediaan. Ini tidak dapat digunakan untuk hal lain, seperti kueri yang dapat dibaca. AG dalam edisi SQL Server Enterprise dapat memiliki hingga sembilan total replika: satu primer dan hingga delapan sekunder, yang hingga tiga (termasuk yang utama) dapat sinkron. Jika menggunakan kluster yang mendasari, jumlah maksimum total adalah 16 simpul saat Corosync terlibat. Grup ketersediaan dapat mencakup paling banyak sembilan dari 16 simpul dengan edisi SQL Server Enterprise, dan dua dengan edisi SQL Server Standard.

Konfigurasi dua replika yang memerlukan kemampuan untuk melakukan failover secara otomatis ke replika lain memerlukan penggunaan replika khusus konfigurasi, seperti yang dijelaskan dalam Replika khusus konfigurasi dan kuorum. Replika khusus konfigurasi diperkenalkan pada SQL Server 2017 (14.x) Pembaruan Kumulatif 1 (CU 1), sehingga harus menjadi versi minimum yang disebarkan untuk konfigurasi ini.

Jika Pacemaker digunakan, Pacemaker harus dikonfigurasi dengan benar sehingga tetap aktif dan berjalan. Ini berarti bahwa kuorum dan isolasi terhadap node yang gagal harus diimplementasikan dengan benar dari sudut pandang Pacemaker, di samping persyaratan SQL Server seperti replika yang hanya untuk konfigurasi.

Replika sekunder yang dapat dibaca hanya didukung dengan SQL Server edisi Enterprise.

Jenis kluster dan mode failover

Dalam SQL Server 2017 (14.x), diperkenalkan jenis kluster untuk Availability Groups (AG). Untuk Linux, ada dua nilai yang valid: Eksternal dan Tidak Ada. Jenis kluster Eksternal berarti bahwa Pacemaker digunakan di bawah AG. Menggunakan Eksternal untuk jenis kluster mengharuskan mode failover diatur ke Eksternal juga (juga baru di SQL Server 2017 (14.x)). Failover otomatis didukung, tetapi tidak seperti WSFC, mode failover diatur ke Eksternal, bukan otomatis, saat Pacemaker digunakan. Tidak seperti WSFC, komponen Pacemaker dari AG dibuat setelah AG selesai dikonfigurasi.

Jenis kluster Tidak Ada berarti bahwa tidak ada persyaratan untuk menggunakan Pacemaker, dan AG juga tidak menggunakannya. Bahkan pada server yang memiliki Pacemaker yang dikonfigurasi, jika AG dikonfigurasi dengan jenis kluster Tidak Ada, Pacemaker tidak melihat atau mengelola AG tersebut. Jenis kluster "None" hanya mendukung failover manual dari replika primer ke replika sekunder. AG yang dibuat dengan None terutama ditargetkan untuk peningkatan dan peluasan skala baca. Meskipun dapat bekerja dalam skenario seperti pemulihan bencana atau ketersediaan lokal di mana tidak ada failover otomatis yang diperlukan, itu tidak disarankan. Cerita pendengar juga lebih kompleks tanpa Pacemaker.

Jenis kluster disimpan dalam tampilan manajemen dinamis (DMV) SQL Server sys.availability_groups, di kolom cluster_type dan cluster_type_desc.

diperlukan_sinkronisasi_sekunder_untuk_komit

Di SQL Server 2017 (14.x) yang baru, terdapat pengaturan yang digunakan oleh AGs yang disebut required_synchronized_secondaries_to_commit. Ini memberitahu Availability Group (AG) jumlah replika sekunder yang harus sinkron dengan replika utama. Ini memungkinkan hal-hal seperti failover otomatis (hanya ketika terintegrasi dengan Pacemaker dengan jenis kluster Eksternal), dan mengontrol perilaku hal-hal seperti ketersediaan primer jika jumlah replika sekunder yang tepat adalah online atau offline. Untuk memahami lebih lanjut tentang cara kerja ini, lihat Ketersediaan Tinggi dan Perlindungan Data untuk Konfigurasi Grup Ketersediaan. Nilai required_synchronized_secondaries_to_commit diatur secara default dan dikelola oleh Pacemaker/ SQL Server. Anda dapat mengubah nilai ini secara manual.

Kombinasi required_synchronized_secondaries_to_commit dan nomor urutan baru (yang disimpan dalam sys.availability_groups) menginformasikan Pacemaker dan SQL Server bahwa, misalnya, failover otomatis dapat terjadi. Dalam hal ini, replika sekunder akan memiliki nomor urut yang sama dengan yang utama, yang berarti sudah diperbarui dengan semua informasi konfigurasi terbaru.

Ada tiga nilai yang dapat diatur untuk required_synchronized_secondaries_to_commit: 0, 1, atau 2. Mereka mengontrol perilaku apa yang terjadi ketika replika menjadi tidak tersedia. Angka sesuai dengan jumlah replika sekunder yang harus disinkronkan dengan replika utama. Perilakunya adalah sebagai berikut di bawah Linux:

Pengaturan	Deskripsi
0	Replika sekunder tidak perlu dalam status sinkron dengan replika utama. Namun, jika node-node sekunder tidak disinkronkan, tidak ada failover otomatis.
1	Satu replika sekunder harus dalam keadaan disinkronkan dengan replika utama; failover otomatis dimungkinkan. Database utama tidak tersedia hingga replika sinkron sekunder tersedia.
2	Kedua replika sekunder dalam konfigurasi AG dengan tiga simpul atau lebih harus disinkronkan dengan yang utama, sehingga failover otomatis dimungkinkan.

required_synchronized_secondaries_to_commit tidak hanya mengendalikan perilaku failover dengan replika sinkron, namun juga kehilangan data. Dengan nilai 1 atau 2, replika sekunder harus selalu disinkronkan, untuk memastikan redundansi data. Itu berarti tidak ada kehilangan data.

Untuk mengubah nilai required_synchronized_secondaries_to_commit, gunakan sintaks berikut:

Catatan

Mengubah nilai menyebabkan sumber daya dimulai ulang, yang berarti pemadaman singkat. Satu-satunya cara untuk menghindari hal ini adalah dengan mengatur sumber daya agar tidak dikelola oleh kluster untuk sementara.

Red Hat Enterprise Linux (RHEL) dan Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

Catatan

Mulai SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) tidak didukung.

Dalam contoh ini, <AGResourceName> adalah nama sumber daya yang dikonfigurasi untuk AG, dan <value> adalah 0, 1, atau 2. Untuk mengaturnya kembali ke pengaturan default di mana Pacemaker mengelola parameter, jalankan pernyataan yang sama tanpa nilai.

Failover otomatis untuk AG dapat dilakukan ketika kondisi berikut terpenuhi:

• Replika utama dan sekunder diatur ke pergerakan data sinkron.
• Sekunder memiliki status tersinkronisasi (bukan sedang menyinkronkan), yang berarti keduanya berada pada titik data yang sama.
• Jenis kluster diatur ke Eksternal. Failover otomatis tidak dimungkinkan dengan jenis kluster Tidak Ada.
• sequence_number Replika sekunder yang menjadi primer memiliki angka urutan tertinggi - artinya, angka urutan replika sekunder sama dengan replika utama asli.

Jika kondisi ini terpenuhi dan server yang menghosting replika utama gagal, AG mengubah kepemilikan ke replika sinkron. Perilaku untuk replika sinkron (yang dapat ada tiga total: satu replika primer dan dua sekunder) selanjutnya dapat dikendalikan oleh required_synchronized_secondaries_to_commit. Ini dapat digunakan dengan AG di Windows dan Linux, tetapi dikonfigurasi secara berbeda. Di Linux, nilai dikonfigurasi secara otomatis oleh kluster pada sumber daya AG itu sendiri.

Replika dan kuorum khusus konfigurasi

Replika khusus konfigurasi diperkenalkan untuk mengatasi keterbatasan dalam penanganan kuorum dengan Pacemaker, terutama ketika memotong node yang gagal. Hanya memiliki konfigurasi dua node tidak berfungsi untuk AG. Untuk FCI, mekanisme kuorum yang disediakan oleh Pacemaker bisa baik-baik saja karena semua arbitrase failover FCI terjadi di lapisan kluster. Untuk AG, arbitrase pada Linux berlangsung di SQL Server, tempat semua metadata disimpan. Di sinilah replika yang hanya konfigurasi mulai berperan.

Tanpa hal lain, simpul ketiga dan setidaknya satu replika yang disinkronkan akan diperlukan. Replika khusus konfigurasi menyimpan konfigurasi AG dalam master database, sama seperti replika lain dalam konfigurasi AG. Replika yang hanya untuk konfigurasi tidak memiliki database pengguna yang berpartisipasi dalam AG. Data konfigurasi dikirim secara sinkron dari primer. Data konfigurasi ini kemudian digunakan selama failover, baik otomatis maupun manual.

Agar AG dapat mempertahankan kuorum dan mengaktifkan failover otomatis dengan jenis kluster Eksternal, AG harus memiliki salah satu dari opsi berikut:

• Memiliki tiga replika sinkron (hanya SQL Server edisi Enterprise); atau
• Memiliki dua replika (primer dan sekunder) dan replika yang hanya untuk konfigurasi.

Failover manual dapat terjadi baik menggunakan jenis kluster Eksternal atau Tidak Ada untuk konfigurasi AG. Meskipun replika khusus konfigurasi dapat dikonfigurasi dengan AG yang memiliki jenis kluster None, ini tidak disarankan, karena dapat mempersulit penyebaran. Untuk konfigurasi tersebut, ubah required_synchronized_secondaries_to_commit secara manual agar memiliki nilai setidaknya 1, sehingga setidaknya ada satu replika yang disinkronkan.

Replika khusus konfigurasi dapat dihosting pada edisi SQL Server apa pun, termasuk SQL Server Express. Ini meminimalkan biaya lisensi dan memastikannya berfungsi dengan AG dalam edisi SQL Server Standar. Ini berarti bahwa server ketiga yang diperlukan hanya perlu memenuhi spesifikasi minimum untuk SQL Server, karena tidak menerima lalu lintas transaksi pengguna untuk AG.

Saat replika khusus konfigurasi digunakan, replika tersebut memiliki perilaku berikut:

• Secara default, required_synchronized_secondaries_to_commit diatur ke 0. Ini dapat dimodifikasi secara manual menjadi 1 jika diinginkan.

• Jika primer gagal dan required_synchronized_secondaries_to_commit adalah 0, replika sekunder menjadi primer baru dan menjadi tersedia untuk membaca dan menulis. Jika nilainya adalah 1, failover otomatis terjadi, tetapi tidak menerima transaksi baru sampai replika lain online.

• Jika replika sekunder gagal dan required_synchronized_secondaries_to_commit 0, replika utama masih menerima transaksi, tetapi jika replika utama gagal pada titik ini, tidak ada perlindungan untuk data atau kegagalan yang mungkin (manual atau otomatis), karena replika sekunder tidak tersedia.

• Jika replika yang hanya berisi konfigurasi gagal, AG berfungsi secara normal, tetapi tidak memungkinkan terjadi failover otomatis.

• Jika replika sekunder sinkron dan replika konfigurasi saja keduanya gagal, replika utama tidak dapat menerima transaksi, dan tidak ada tempat bagi replika utama untuk berpindah.

Beberapa grup ketersediaan

Lebih dari satu AG dapat dibuat per kluster Pacemaker atau sekumpulan server. Satu-satunya batasan adalah sumber daya sistem. Kepemilikan AG ditunjukkan oleh pemilik utama. AG yang berbeda dapat dimiliki oleh node yang berbeda; tidak perlu semuanya berjalan pada node yang sama.

Lokasi drive dan folder untuk database

Seperti pada AG berbasis Windows, struktur drive dan folder untuk database pengguna yang berpartisipasi dalam AG harus identik. Misalnya, jika database pengguna berada di /var/opt/mssql/userdata di Server A, folder yang sama harus ada di Server B. Satu-satunya pengecualian untuk ini dicatat di bagian Interoperability dengan grup ketersediaan dan replika berbasis Windows.

Penyimak pada Linux

Pendengar adalah fitur opsional untuk AG. Ini menyediakan satu titik entri untuk semua koneksi (baca/tulis ke replika utama dan/atau baca-saja ke replika sekunder) sehingga aplikasi dan pengguna akhir tidak perlu mengetahui server mana yang menghosting data. Dalam WSFC, ini adalah kombinasi sumber daya nama jaringan dan sumber daya IP, yang kemudian terdaftar di AD DS (jika diperlukan) dan DNS. Dalam kombinasi dengan sumber daya AG itu sendiri, ia menyediakan abstraksi tersebut. Untuk informasi selengkapnya tentang pendengar, lihat Menyambungkan ke listener grup ketersediaan AlwaysOn.

Pendengar di bawah Linux dikonfigurasi secara berbeda, tetapi fungsionalitasnya sama. Tidak ada konsep sumber daya nama jaringan di Pacemaker, juga bukan objek yang dibuat di AD DS; hanya ada sumber daya alamat IP yang dibuat di Pacemaker yang dapat berjalan pada salah satu simpul. Entri yang terkait dengan sumber daya IP untuk pendengar di DNS dengan "nama yang mudah diingat" perlu dibuat. Sumber daya IP untuk pendengar hanya aktif di server yang menghosting replika utama untuk grup ketersediaan tersebut.

Jika Pacemaker digunakan, dan sumber daya alamat IP dibuat yang terkait dengan pendengar, ada pemadaman singkat saat alamat IP berhenti di satu server dan dimulai di server lain, apakah itu failover otomatis atau manual. Meskipun ini memberikan abstraksi melalui kombinasi satu nama dan alamat IP, itu tidak menutupi pemadaman. Aplikasi harus dapat menangani pemutusan sambungan dengan memiliki semacam fungsionalitas untuk mendeteksi ini dan menyambungkan kembali.

Namun, kombinasi nama DNS dan alamat IP masih belum cukup untuk menyediakan semua fungsionalitas yang disediakan pendengar di WSFC, seperti perutean baca-saja untuk replika sekunder. Saat Anda mengonfigurasi AG, listener masih perlu dikonfigurasi di SQL Server. Ini dapat terlihat dalam wizard dan sintaks Transact-SQL. Ada dua cara agar ini dapat dikonfigurasi agar berfungsi sama seperti pada Windows:

• Untuk AG dengan jenis kluster eksternal, alamat IP yang terkait dengan listener yang dibuat di SQL Server harus menjadi alamat IP sumber daya yang dibuat di Pacemaker.
• Untuk AG yang dibuat dengan jenis kluster Tidak Ada, gunakan alamat IP yang terkait dengan replika utama.

Instans yang terkait dengan alamat IP yang disediakan kemudian menjadi koordinator untuk hal-hal seperti permintaan perutean baca-saja dari aplikasi.

Interoperabilitas dengan grup ketersediaan dan replika berbasis Windows

AG yang memiliki jenis kluster Eksternal atau yang WSFC tidak dapat memiliki replika lintas platform. Ini benar apakah AG SQL Server edisi Standar atau SQL Server edisi Enterprise. Itu berarti dalam konfigurasi AG tradisional dengan kluster yang mendasarinya, satu replika tidak dapat berada di WSFC dan yang lain di Linux dengan Pacemaker.

AG dengan tipe kluster NONE dapat memiliki replikanya melintasi batas OS, sehingga bisa ada replika berbasis Linux dan Windows dalam AG yang sama. Contoh ditunjukkan di sini di mana replika utama berbasis Windows, sementara sekunder berada di salah satu distribusi Linux.

AG terdistribusi juga dapat melintasi batas OS. AG yang mendasar terikat oleh aturan tentang bagaimana mereka dikonfigurasi, seperti salah satunya yang dikonfigurasi dengan Eksternal menjadi khusus Linux, tetapi AG yang bergabung dengannya dapat dikonfigurasi menggunakan WSFC. Pertimbangkan contoh berikut:

Konten terkait

• Konfigurasi grup ketersediaan SQL Server untuk ketersediaan tinggi di Linux
• Konfigurasi grup ketersediaan SQL Server untuk skala baca di Linux
• Konfigurasi kluster Pacemaker untuk grup ketersediaan SQL Server
• Konfigurasi grup ketersediaan SQL Server AlwaysOn di Windows dan Linux (lintas platform)