Grup ketersediaan untuk SQL Server di Linux

  • Artikel

Berlaku untuk:SQL Server - Linux

Artikel ini menjelaskan karakteristik grup ketersediaan (AG) di bawah penginstalan SQL Server berbasis Linux. Ini juga mencakup perbedaan antara AG berbasis kluster failover Linux dan Windows Server (WSFC). Lihat dokumentasi berbasis Windows untuk dasar-dasar AG, karena berfungsi sama di Windows dan Linux kecuali untuk WSFC.

Catatan

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

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

  • Koordinator Transaksi Terdistribusi Microsoft (DTC) didukung di bawah Linux yang dimulai dengan SQL Server 2017 CU16. Namun, DTC belum didukung pada Grup Ketersediaan di Linux. Jika aplikasi Anda memerlukan penggunaan transaksi terdistribusi dan memerlukan AG, sebarkan SQL Server di Windows.
  • Penyebaran berbasis Linux yang memerlukan ketersediaan tinggi menggunakan Pacemaker untuk pengklusteran alih-alih WSFC.
  • Tidak seperti kebanyakan konfigurasi untuk AG di Windows kecuali untuk skenario Kluster Grup Kerja, Pacemaker tidak pernah memerlukan Active Directory Domain Services (AD DS).
  • Cara menggagalkan AG dari satu simpul ke simpul 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 mendasar, mungkin ada total maksimum 16 simpul saat Corosync terlibat. Grup ketersediaan dapat mencakup paling banyak sembilan dari 16 simpul dengan edisi SQL Server Enterprise, dan dua dengan edisi Standar SQL Server.

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

Jika Pacemaker digunakan, Pacemaker harus dikonfigurasi dengan benar sehingga tetap aktif dan berjalan. Itu berarti bahwa kuorum dan STONITH harus diimplementasikan dengan benar dari perspektif Pacemaker, selain persyaratan SQL Server seperti replika khusus konfigurasi.

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

Jenis kluster dan mode failover

Baru menggunakan SQL Server 2017 (14.x) adalah pengenalan jenis kluster untuk AG. Untuk Linux, ada dua nilai yang valid: Eksternal dan Tidak Ada. Jenis kluster Eksternal berarti Pacemaker akan 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, bagian Pacemaker dari AG dibuat setelah AG dikonfigurasi.

Jenis kluster Tidak Ada berarti bahwa tidak ada persyaratan untuk, juga tidak akan digunakan AG, Pacemaker. Bahkan pada server yang memiliki Pacemaker yang dikonfigurasi, jika AG dikonfigurasi dengan jenis kluster Tidak Ada, Pacemaker tidak akan melihat atau mengelola AG tersebut. Jenis kluster Tidak Ada hanya mendukung failover manual dari replika primer ke 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 SQL Server (DMV), sys.availability_groupsdi kolom cluster_type dan cluster_type_desc.

required_synchronized_secondaries_to_commit

Baru menggunakan SQL Server 2017 (14.x) adalah pengaturan yang digunakan oleh AG yang disebut required_synchronized_secondaries_to_commit. Ini memberi tahu AG jumlah replika sekunder yang harus dalam lockstep 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 selengkapnya tentang cara kerjanya, 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 mengambil alih nilai ini secara manual.

Kombinasi dan required_synchronized_secondaries_to_commit 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:

  • 0 - Replika sekunder tidak perlu dalam keadaan disinkronkan dengan replika utama. Namun jika sekunder tidak disinkronkan, tidak akan 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 simpul tiga atau lebih harus disinkronkan dengan replika utama; failover otomatis dimungkinkan.

required_synchronized_secondaries_to_commit tidak hanya mengontrol perilaku failover dengan replika sinkron, tetapi kehilangan data. Dengan nilai 1 atau 2, replika sekunder selalu diperlukan untuk disinkronkan, sehingga akan selalu ada 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>

di mana AGResourceName adalah nama sumber daya yang dikonfigurasi untuk AG, dan Nilai adalah 0, 1, atau 2. Untuk mengaturnya kembali ke default Pacemaker yang mengelola parameter, jalankan pernyataan yang sama tanpa nilai.

Failover otomatis AG dimungkinkan ketika kondisi berikut terpenuhi:

  • Replika utama dan sekunder diatur ke pergerakan data sinkron.
  • Sekunder memiliki status disinkronkan (tidak disinkronkan), 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 untuk menjadi primer memiliki angka urutan tertinggi - dengan kata lain, replika sequence_number sekunder cocok dengan yang dari replika utama asli.

Jika kondisi ini terpenuhi dan server yang menghosting replika utama gagal, AG akan mengubah kepemilikan menjadi 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 berfungsi 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

Juga baru di SQL Server 2017 (14.x) per CU1 adalah replika khusus konfigurasi. Karena Pacemaker berbeda dari WSFC, terutama dalam hal kuorum dan membutuhkan STONITH, hanya memiliki konfigurasi dua node tidak akan berfungsi ketika datang ke 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 di bawah Linux terjadi di SQL Server, tempat semua metadata disimpan. Di sinilah replika khusus konfigurasi mulai dimainkan.

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 khusus 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 mempertahankan kuorum dan mengaktifkan failover otomatis dengan jenis kluster Eksternal, AG harus:

  • Memiliki tiga replika sinkron (hanya edisi SQL Server Enterprise); Atau
  • Memiliki dua replika (primer dan sekunder) dan replika konfigurasi saja.

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 Tidak Ada, replika tidak disarankan, karena 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 SQL Server edisi apa pun, termasuk SQL Server Express. Ini akan meminimalkan biaya lisensi dan memastikannya berfungsi dengan AG di edisi Standar SQL Server. 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 akan menjadi primer baru dan tersedia untuk membaca dan menulis. Jika nilainya adalah 1, failover otomatis akan terjadi, tetapi tidak akan 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 khusus konfigurasi gagal, AG akan berfungsi secara normal, tetapi tidak ada failover otomatis yang dimungkinkan.
  • Jika replika sekunder sinkron dan replika khusus konfigurasi gagal, primer tidak dapat menerima transaksi, dan tidak ada tempat bagi primer untuk gagal.

Di CU1 ada bug yang diketahui dalam pengelogan dalam corosync.log file yang dihasilkan melalui mssql-server-ha. Jika replika sekunder tidak dapat menjadi replika utama karena jumlah replika yang diperlukan tersedia, pesan saat ini mengatakan "Diharapkan menerima 1 nomor urutan tetapi hanya menerima 2. Tidak cukup replika yang online untuk mempromosikan replika lokal dengan aman." Angka-angka harus dibalik, dan harus mengatakan "Diharapkan menerima 2 nomor urut tetapi hanya diterima 1. Tidak cukup replika yang online untuk mempromosikan replika lokal dengan aman."

Beberapa grup ketersediaan

Lebih dari satu AG dapat dibuat per kluster Pacemaker atau set server. Satu-satunya batasan adalah sumber daya sistem. Kepemilikan AG ditunjukkan oleh master. AG yang berbeda dapat dimiliki oleh node yang berbeda; mereka tidak semua perlu 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 Server A, folder yang sama harus ada di Server B. Satu-satunya pengecualian untuk ini dicatat di bagian Interoperabilitas dengan grup ketersediaan dan replika berbasis Windows.

Pendengar di bawah Linux

Pendengar adalah fungsionalitas 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 listener, lihat Listener, Client Koneksi ivity, dan Application Failover.

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 akan aktif di server yang menghosting replika utama untuk grup ketersediaan tersebut.

Jika Pacemaker digunakan dan sumber daya alamat IP dibuat yang terkait dengan pendengar, akan 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 mengonfigurasi AG, "listener" masih perlu dikonfigurasi di SQL Server. Ini dapat dilihat 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 adalah edisi Standar SQL Server atau edisi SQL Server 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 jenis kluster NONE dapat memiliki batas lintas OS replikanya, sehingga mungkin 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.

Hybrid None.

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

Hybrid Dist AG.

Konten terkait