Mengonfigurasi Grup Ketersediaan SQL Server untuk skala baca di Linux

Berlaku untuk:SQL Server - Linux

Artikel ini menjelaskan cara membuat Grup Ketersediaan Always On (AG) SQL Server di Linux tanpa manajer kluster. Arsitektur ini hanya menyediakan skala baca. Ini tidak memberikan ketersediaan tinggi.

Ada dua jenis arsitektur untuk AG. Arsitektur untuk ketersediaan tinggi menggunakan manajer kluster untuk memberikan peningkatan kelangsungan bisnis. Untuk membuat arsitektur ketersediaan tinggi, lihat Mengonfigurasi Grup Ketersediaan AlwaysOn SQL Server untuk ketersediaan tinggi di Linux.

Grup ketersediaan dengan CLUSTER_TYPE = NONE dapat mencakup replika yang dihosting di platform sistem operasi yang berbeda. Ini tidak dapat mendukung ketersediaan tinggi.

Prasyarat

Sebelum membuat grup ketersediaan, Anda perlu:

  • Atur lingkungan Anda sehingga semua server yang akan menghosting replika ketersediaan dapat berkomunikasi.
  • Instal SQL Server.

Catatan

Di Linux, Anda harus membuat grup ketersediaan sebelum menambahkannya sebagai sumber daya kluster yang akan dikelola oleh kluster. Dokumen ini menyediakan contoh yang membuat grup ketersediaan. Untuk instruksi khusus distribusi untuk membuat kluster dan menambahkan grup ketersediaan sebagai sumber daya kluster, lihat tautan di bawah "Langkah berikutnya."

  1. Perbarui nama komputer untuk setiap host.

    Setiap nama SQL Server harus:

    • 15 karakter atau kurang.
    • Unik dalam jaringan.

    Untuk mengatur nama komputer, edit /etc/hostname. Skrip berikut memungkinkan Anda mengedit /etc/hostname dengan vi:

    sudo vi /etc/hostname
    
  2. Konfigurasikan file host.

    Catatan

    Jika nama host terdaftar dengan alamat IP mereka di server DNS, Anda tidak perlu melakukan langkah-langkah berikut. Validasi bahwa semua simpul yang dimaksudkan untuk menjadi bagian dari konfigurasi grup ketersediaan dapat berkomunikasi satu sama lain. (Ping ke nama host harus membalas dengan alamat IP yang sesuai.) Selain itu, pastikan bahwa /etc/hosts file tidak berisi catatan yang memetakan alamat IP localhost 127.0.0.1 dengan nama host simpul.

    File host di setiap server berisi alamat IP dan nama semua server yang akan berpartisipasi dalam grup ketersediaan.

    Perintah berikut mengembalikan alamat IP server saat ini:

    sudo ip addr show
    

    Perbarui /etc/hosts. Skrip berikut memungkinkan Anda mengedit /etc/hosts dengan vi:

    sudo vi /etc/hosts
    

    Contoh berikut menunjukkan /etc/hosts pada node1 dengan penambahan untuk node1, , dan .node3node2 Dalam sampel ini, node1 mengacu pada server yang menghosting replika utama, dan node2 dan node3 merujuk ke server yang menghosting replika sekunder.

    127.0.0.1    localhost localhost4 localhost4.localdomain4
    ::1          localhost localhost6 localhost6.localdomain6
    10.128.18.12 node1
    10.128.16.77 node2
    10.128.15.33 node3
    

Instal SQL Server

Instal SQL Server. Tautan berikut menunjuk ke instruksi penginstalan SQL Server untuk berbagai distribusi:

Mengaktifkan grup ketersediaan AlwaysOn

Aktifkan grup ketersediaan AlwaysOn untuk setiap simpul yang menghosting instans SQL Server, lalu mulai ulang mssql-server. Jalankan skrip berikut:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

Mengaktifkan sesi peristiwa AlwaysOn_health

Anda dapat secara opsional mengaktifkan peristiwa yang diperluas (XE) untuk membantu diagnosis akar penyebab saat Anda memecahkan masalah grup ketersediaan. Jalankan perintah berikut pada setiap instans SQL Server:

ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

Untuk informasi selengkapnya tentang sesi XE ini, lihat Mengonfigurasi peristiwa yang diperluas untuk grup ketersediaan AlwaysOn.

Membuat sertifikat

Layanan SQL Server di Linux menggunakan sertifikat untuk mengautentikasi komunikasi antara titik akhir pencerminan.

Skrip Transact-SQL berikut membuat kunci master dan sertifikat. Kemudian mencadangkan sertifikat dan mengamankan file dengan kunci privat. Perbarui skrip dengan kata sandi yang kuat. Koneksi ke instans SQL Server utama. Untuk membuat sertifikat, jalankan skrip Transact-SQL berikut:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
        );

Pada titik ini, replika SQL Server utama Anda memiliki sertifikat di /var/opt/mssql/data/dbm_certificate.cer dan kunci privat di var/opt/mssql/data/dbm_certificate.pvk. Salin kedua file ini ke lokasi yang sama di semua server yang akan menghosting replika ketersediaan. Gunakan pengguna mssql, atau berikan izin kepada pengguna mssql untuk mengakses file-file ini.

Misalnya, pada server sumber, perintah berikut menyalin file ke komputer target. **<node2>** Ganti nilai dengan nama instans SQL Server yang akan menghosting replika.

cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/

Pada setiap server target, berikan izin kepada pengguna mssql untuk mengakses sertifikat.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Membuat sertifikat di server sekunder

Skrip Transact-SQL berikut membuat kunci master dan sertifikat dari cadangan yang Anda buat di replika SQL Server utama. Perbarui skrip dengan kata sandi yang kuat. Kata sandi dekripsi adalah kata sandi yang sama dengan yang Anda gunakan untuk membuat file .pvk di langkah sebelumnya. Untuk membuat sertifikat, jalankan skrip berikut di semua server sekunder:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
        );

Membuat titik akhir pencerminan database pada semua replika

Titik akhir pencerminan database menggunakan Protokol Kontrol Transmisi (TCP) untuk mengirim dan menerima pesan antara instans server yang berpartisipasi dalam sesi pencerminan database atau replika ketersediaan host. Titik akhir pencerminan database mendengarkan nomor port TCP yang unik.

Skrip Transact-SQL berikut membuat titik akhir mendengarkan bernama Hadr_endpoint untuk grup ketersediaan. Ini memulai titik akhir dan memberikan izin koneksi ke sertifikat yang Anda buat. Sebelum Anda menjalankan skrip, ganti nilai di antara **< ... >**. Secara opsional Anda dapat menyertakan alamat LISTENER_IP = (0.0.0.0)IP . Alamat IP pendengar harus berupa alamat IPv4. Anda juga dapat menggunakan 0.0.0.0.

Perbarui skrip Transact-SQL berikut untuk lingkungan Anda di semua instans SQL Server:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Catatan

Jika Anda menggunakan SQL Server Express Edition pada satu simpul untuk menghosting replika khusus konfigurasi, satu-satunya nilai yang valid untuk ROLE adalah WITNESS. Jalankan skrip berikut di SQL Server Express Edition:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Port TCP pada firewall harus terbuka untuk port pendengar.

Penting

Untuk rilis SQL Server 2017, satu-satunya metode autentikasi yang didukung untuk titik akhir pencerminan database adalah CERTIFICATE. Opsi WINDOWS akan diaktifkan dalam rilis mendatang.

Untuk informasi selengkapnya, lihat Titik akhir pencerminan database (SQL Server).

Membuat grup ketersediaan

Buat AG. Set CLUSTER_TYPE = NONE. Selain itu, atur setiap replika dengan FAILOVER_MODE = MANUAL. Aplikasi klien yang menjalankan analitik atau melaporkan beban kerja dapat langsung terhubung ke database sekunder. Anda juga dapat membuat daftar perutean baca-saja. Koneksi ke replika utama meneruskan permintaan koneksi baca ke setiap replika sekunder dari daftar perutean dengan cara round-robin.

Skrip Transact-SQL berikut membuat AG bernama ag1. Skrip mengonfigurasi replika AG dengan SEEDING_MODE = AUTOMATIC. Pengaturan ini menyebabkan SQL Server secara otomatis membuat database di setiap server sekunder setelah ditambahkan ke AG. Perbarui skrip berikut untuk lingkungan Anda. <node1> Ganti nilai dan <node2> dengan nama instans SQL Server yang menghosting replika. <5022> Ganti nilai dengan port yang Anda tetapkan untuk titik akhir. Jalankan skrip Transact-SQL berikut pada replika SQL Server utama:

CREATE AVAILABILITY GROUP [ag1]
    WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON
        N'<node1>' WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC,
                    SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
            ),
        N'<node2>' WITH ( 
            ENDPOINT_URL = N'tcp://<node2>:<5022>', 
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC,
            SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Menggabungkan instans SQL Server sekunder ke AG

Skrip Transact-SQL berikut menggabungkan server ke AG bernama ag1. Perbarui skrip untuk lingkungan Anda. Pada setiap replika SQL Server sekunder, jalankan skrip Transact-SQL berikut untuk bergabung dengan AG:

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Menambahkan database ke Grup Ketersediaan

Pastikan database yang Anda tambahkan ke grup ketersediaan berada dalam model pemulihan penuh dan memiliki cadangan log yang valid. Jika ini adalah database pengujian atau database yang baru dibuat, ambil cadangan database. Pada SQL Server utama, jalankan skrip Transact-SQL berikut untuk membuat dan mencadangkan database yang disebut db1:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
   TO DISK = N'/var/opt/mssql/data/db1.bak';

Pada replika SQL Server utama, jalankan skrip Transact-SQL berikut untuk menambahkan database yang dipanggil db1 ke grup ketersediaan yang disebut ag1:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Memverifikasi bahwa database dibuat di server sekunder

Pada setiap replika SQL Server sekunder, jalankan kueri berikut untuk melihat apakah db1 database dibuat dan disinkronkan:

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

AG ini bukan konfigurasi ketersediaan tinggi. Jika Anda memerlukan ketersediaan tinggi, ikuti instruksi di Mengonfigurasi Grup Ketersediaan AlwaysOn untuk SQL Server di Linux. Secara khusus, buat AG dengan CLUSTER_TYPE=WSFC (di Windows) atau CLUSTER_TYPE=EXTERNAL (di Linux). Anda kemudian dapat berintegrasi dengan manajer kluster, dengan menggunakan pengklusteran failover Windows Server di Windows, atau Pacemaker di Linux.

Koneksi ke replika sekunder baca-saja

Ada dua cara untuk terhubung ke replika sekunder baca-saja. Aplikasi dapat terhubung langsung ke instans SQL Server yang menghosting replika sekunder dan mengkueri database. Mereka juga dapat menggunakan perutean baca-saja, yang memerlukan pendengar.

Failover replika utama pada AG skala baca

Setiap grup ketersediaan hanya memiliki satu replika utama. Replika utama memungkinkan baca dan tulis. Untuk mengubah replika mana yang utama, Anda dapat melakukan failover. Dalam grup ketersediaan umum, manajer kluster mengotomatiskan proses failover. Dalam grup ketersediaan dengan jenis kluster NONE, proses failover manual.

Ada dua cara untuk melakukan failover pada replika utama dalam grup ketersediaan dengan jenis kluster NONE:

  • Failover manual tanpa kehilangan data
  • Failover manual paksa dengan kehilangan data

Failover manual tanpa kehilangan data

Gunakan metode ini saat replika utama tersedia, tetapi Anda perlu mengubah sementara atau secara permanen instans mana yang menghosting replika utama. Untuk menghindari potensi kehilangan data, sebelum Anda mengeluarkan failover manual, pastikan bahwa replika sekunder target sudah diperbarui.

Untuk melakukan failover secara manual tanpa kehilangan data:

  1. Buat replika SYNCHRONOUS_COMMITsekunder primer dan target saat ini .

    ALTER AVAILABILITY GROUP [AGRScale] 
         MODIFY REPLICA ON N'<node2>' 
         WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
    
  2. Untuk mengidentifikasi bahwa transaksi aktif diterapkan ke replika utama dan setidaknya satu replika sekunder sinkron, jalankan kueri berikut:

    SELECT ag.name, 
       drs.database_id, 
       drs.group_id, 
       drs.replica_id, 
       drs.synchronization_state_desc, 
       ag.sequence_number
    FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
    WHERE drs.group_id = ag.group_id; 
    

    Replika sekunder disinkronkan ketika synchronization_state_desc adalah SYNCHRONIZED.

  3. Perbarui REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ke 1.

    Skrip berikut diatur REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ke 1 pada grup ketersediaan bernama ag1. Sebelum Anda menjalankan skrip berikut, ganti ag1 dengan nama grup ketersediaan Anda:

    ALTER AVAILABILITY GROUP [AGRScale] 
         SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
    

    Pengaturan ini memastikan bahwa setiap transaksi aktif diterapkan ke replika utama dan setidaknya satu replika sekunder sinkron.

    Catatan

    Pengaturan ini tidak spesifik untuk failover dan harus ditetapkan berdasarkan persyaratan lingkungan.

  4. Atur replika utama dan replika sekunder yang tidak berpartisipasi dalam failover offline untuk mempersiapkan perubahan peran:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
    
  5. Promosikan replika sekunder target ke primer.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
    
  6. Perbarui peran primer lama dan sekunder lainnya ke SECONDARY, jalankan perintah berikut pada instans SQL Server yang menghosting replika utama lama:

    ALTER AVAILABILITY GROUP [AGRScale] 
         SET (ROLE = SECONDARY); 
    

    Catatan

    Untuk menghapus grup ketersediaan, gunakan DROP AVAILABILITY GROUP. Untuk grup ketersediaan yang dibuat dengan jenis kluster NONE atau EXTERNAL, jalankan perintah pada semua replika yang merupakan bagian dari grup ketersediaan.

  7. Lanjutkan pergerakan data, jalankan perintah berikut untuk setiap database dalam grup ketersediaan pada instans SQL Server yang menghosting replika utama:

    ALTER DATABASE [db1]
         SET HADR RESUME
    
  8. Buat ulang listener apa pun yang Anda buat untuk tujuan skala baca dan yang tidak dikelola oleh manajer kluster. Jika pendengar asli menunjuk ke primer lama, letakkan dan buat ulang untuk menunjuk ke primer baru.

Failover manual paksa dengan kehilangan data

Jika replika utama tidak tersedia dan tidak dapat segera dipulihkan, maka Anda perlu memaksa failover ke replika sekunder dengan kehilangan data. Namun, jika replika utama asli pulih setelah failover, replika tersebut akan mengasumsikan peran utama. Untuk menghindari setiap replika berada dalam status yang berbeda, hapus primer asli dari grup ketersediaan setelah failover paksa dengan kehilangan data. Setelah primer asli kembali online, hapus grup ketersediaan darinya sepenuhnya.

Untuk memaksa failover manual dengan kehilangan data dari replika utama N1 ke replika sekunder N2, ikuti langkah-langkah berikut:

  1. Pada replika sekunder (N2), mulai failover paksa:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
    
  2. Pada replika utama baru (N2), hapus primer asli (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
    REMOVE REPLICA ON N'N1';
    
  3. Validasi bahwa semua lalu lintas aplikasi diarahkan ke pendengar dan/atau replika utama baru.

  4. Jika primer asli (N1) online, segera ambil grup ketersediaan AGRScale offline pada primer asli (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
    
  5. Jika ada data atau perubahan yang tidak disinkronkan, pertahankan data ini melalui cadangan atau opsi replikasi data lain yang sesuai dengan kebutuhan bisnis Anda.

  6. Selanjutnya, hapus grup ketersediaan dari primer asli (N1):

    DROP AVAILABILITY GROUP [AGRScale];
    
  7. Hilangkan database grup ketersediaan pada replika utama asli (N1):

    USE [master]
    GO
    DROP DATABASE [AGDBRScale]
    GO
    
  8. (Opsional) Jika diinginkan, Anda sekarang dapat menambahkan N1 kembali sebagai replika sekunder baru ke grup ketersediaan AGRScale.