Bagikan melalui

Failover grup ketersediaan AlwaysOn di Linux

  • Artikel

Berlaku untuk: SQL Server - Linux

Dalam konteks grup ketersediaan (AG), peran utama dan peran sekunder replika ketersediaan biasanya dapat dipertukarkan, dalam proses yang dikenal sebagai failover. Tiga bentuk failover ada: failover otomatis (tanpa kehilangan data), failover manual yang direncanakan (tanpa kehilangan data), dan failover manual paksa (dengan kemungkinan kehilangan data), biasanya disebut failover paksa. Failover manual otomatis dan terencana mempertahankan semua data Anda. AG gagal pada tingkat ketersediaan-replika. Artinya, AG gagal ke salah satu replika sekundernya (target failover saat ini).

Untuk informasi latar belakang tentang failover, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

Failover manual

Gunakan alat manajemen kluster untuk melakukan failover pada AG yang dikelola oleh manajer kluster eksternal. Misalnya, jika solusi menggunakan Pacemaker untuk mengelola kluster Linux, gunakan pcs untuk melakukan failover manual di Red Hat Enterprise Linux (RHEL) atau Ubuntu. Di SUSE Linux Enterprise Server (SLES), gunakan crm.

Penting

Di bawah operasi normal, jangan failover dengan alat manajemen Transact-SQL atau SQL Server seperti SSMS atau PowerShell. Ketika CLUSTER_TYPE = EXTERNAL, satu-satunya nilai yang dapat diterima adalah FAILOVER_MODE EXTERNAL. Dengan pengaturan ini, semua tindakan failover manual atau otomatis dijalankan oleh manajer kluster eksternal. Untuk instruksi untuk memaksa failover dengan potensi kehilangan data, lihat Memaksa failover.

Langkah-langkah failover manual

Untuk failover, replika sekunder yang akan menjadi replika utama harus sinkron. Jika replika sekunder tidak sinkron, ubah mode ketersediaan.

Failover secara manual dalam dua langkah.

  1. Pertama, failover secara manual dengan memindahkan sumber daya AG dari node kluster yang memiliki sumber daya ke simpul baru.

    Kluster gagal sumber daya AG dan menambahkan batasan lokasi. Batasan ini mengonfigurasi sumber daya untuk dijalankan pada simpul baru. Hapus batasan ini agar berhasil melakukan failover di masa mendatang.

  2. Kedua, hapus batasan lokasi.

Langkah 1. Failover secara manual dengan memindahkan sumber daya grup ketersediaan

Untuk melakukan failover secara manual pada sumber daya AG bernama ag_cluster ke node kluster bernama nodeName2, jalankan perintah yang sesuai untuk distribusi Anda:

  • Contoh RHEL/Ubuntu

    sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

  • Contoh SLES

    crm resource migrate ag_cluster nodeName2 --lifetime=30S

Saat Anda menggunakan opsi , --lifetime batasan lokasi yang dibuat untuk memindahkan sumber daya bersifat sementara dan berlaku selama 30 detik dalam contoh sebelumnya.

Batasan sementara tidak dibersihkan secara otomatis dan mungkin muncul dalam daftar batasan, tetapi sebagai batasan kedaluwarsa. Batasan yang kedaluwarsa tidak memengaruhi perilaku failover kluster pacemaker. Jika Anda tidak menggunakan --lifetime opsi saat memindahkan sumber daya, Anda harus menghapus batasan lokasi yang ditambahkan secara otomatis, yang dicatat di bagian berikut.

Langkah 2. Menghapus batasan lokasi

Selama failover manual, pcs perintah move atau crm perintah migrate menambahkan batasan lokasi agar sumber daya ditempatkan pada simpul target baru. Untuk melihat batasan baru, jalankan perintah berikut setelah memindahkan sumber daya secara manual:

  • Contoh RHEL/Ubuntu

    sudo pcs constraint list --full

  • Contoh SLES

    crm config show

    Ini adalah contoh batasan, yang dibuat karena failover manual.

    Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

    Catatan

    Nama sumber daya AG dalam kluster pacemaker pada Red Hat Enterprise Linux 8.x dan Ubuntu 18.04 mungkin menyerupai kloning ag_cluster karena nomenklatur mengenai sumber daya telah berkembang untuk menggunakan klon yang dapat diprogram.

  • Contoh RHEL/Ubuntu

    Dalam perintah berikut, cli-prefer-ag_cluster-master adalah ID batasan yang perlu dihapus. sudo pcs constraint list --full mengembalikan ID ini.

    sudo pcs resource clear ag_cluster-master

    Atau

    sudo pcs constraint remove cli-prefer-ag_cluster-master

    Atau, Anda dapat melakukan pemindahan dan pengosongan batasan yang dihasilkan secara otomatis dalam satu baris sebagai berikut. Contoh berikut menggunakan terminologi kloning sesuai Red Hat Enterprise Linux 8.x.

    sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone

  • Contoh SLES

    Dalam perintah berikut, cli-prefer-ms-ag_cluster adalah ID batasan. crm config show mengembalikan ID ini.

    crm configure
delete cli-prefer-ms-ag_cluster
commit

Catatan

Failover otomatis tidak menambahkan batasan lokasi, sehingga tidak diperlukan pembersihan.

Untuk informasi selengkapnya:

Paksa failover

Failover paksa dimaksudkan secara ketat untuk pemulihan bencana. Dalam hal ini, Anda tidak dapat melakukan failover dengan alat manajemen kluster karena pusat data utama tidak berfungsi. Jika Anda memaksa failover ke replika sekunder yang tidak disinkronkan, beberapa kehilangan data dimungkinkan. Hanya paksa failover jika Anda harus segera memulihkan layanan ke AG dan bersedia kehilangan data.

Jika Anda tidak dapat menggunakan alat manajemen kluster untuk berinteraksi dengan kluster (misalnya, jika kluster tidak responsif karena peristiwa bencana di pusat data utama), Anda mungkin harus memaksa failover untuk melewati manajer kluster eksternal. Prosedur ini tidak disarankan untuk operasi reguler karena berisiko kehilangan data. Gunakan saat alat manajemen kluster gagal menjalankan tindakan failover. Secara fungsional, prosedur ini mirip dengan melakukan failover manual paksa pada AG di Windows.

Proses untuk memaksa failover ini khusus untuk SQL Server di Linux.

  1. Verifikasi bahwa kluster tidak lagi mengelola sumber daya AG.

    • Atur sumber daya ke mode tidak terkelola pada node kluster target. Perintah ini menandakan agen sumber daya untuk menghentikan pemantauan dan manajemen sumber daya. Contohnya:

      sudo pcs resource unmanage <resourceName>

    • Jika upaya untuk mengatur mode sumber daya ke mode tidak terkelola gagal, hapus sumber daya. Contoh:

      sudo pcs resource delete <resourceName>

      Catatan

      Saat Anda menghapus sumber daya, sumber daya juga akan menghapus semua batasan terkait.

  2. Pada instans SQL Server yang menghosting replika sekunder, atur variabel external_clusterkonteks sesi .

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';

  3. Failover AG dengan Transact-SQL. Dalam contoh berikut, ganti <MyAg> dengan nama AG Anda. Sambungkan ke instans SQL Server yang menghosting replika sekunder target dan jalankan perintah berikut:

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;

  4. Setelah failover paksa, bawa AG ke status sehat sebelum memulai ulang pemantauan dan manajemen sumber daya kluster atau membuat ulang sumber daya AG. Tinjau Tugas Penting Setelah Failover Paksa.

  5. Mulai ulang pemantauan dan manajemen sumber daya kluster:

    Untuk memulai ulang pemantauan dan manajemen sumber daya kluster, jalankan perintah berikut:

    sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>

    Jika Anda menghapus sumber daya kluster, buat ulang. Untuk membuat ulang sumber daya kluster, ikuti instruksi di Membuat sumber daya grup ketersediaan.

Penting

Jangan gunakan langkah-langkah sebelumnya untuk latihan pemulihan bencana karena berisiko kehilangan data. Sebagai gantinya ubah replika asinkron menjadi sinkron, dan instruksi untuk failover manual normal.

Pemantauan tingkat database dan pemicu failover

Untuk CLUSTER_TYPE=EXTERNAL, semantik pemicu failover berbeda dibandingkan dengan WSFC. Ketika AG berada pada instans SQL Server di WSFC, transisi ke luar ONLINE status untuk database menyebabkan kesehatan AG melaporkan kesalahan. Sebagai respons, manajer kluster memicu tindakan failover. Di Linux, instans SQL Server tidak dapat berkomunikasi dengan kluster. Pemantauan untuk kesehatan database dilakukan di luar masuk. Jika pengguna memilih untuk pemantauan failover tingkat database dan failover (dengan mengatur opsi DB_FAILOVER=ON saat membuat AG), kluster memeriksa apakah status ONLINE database setiap kali menjalankan tindakan pemantauan. Kluster mengkueri status di sys.databases. Untuk status apa pun yang berbeda dengan ONLINE, itu memicu failover secara otomatis (jika kondisi failover otomatis terpenuhi). Waktu aktual failover tergantung pada frekuensi tindakan pemantauan, dan status database sedang diperbarui di sys.databases.

Failover otomatis memerlukan setidaknya satu replika sinkron.

Konten terkait

Berkontribusi pada dokumentasi SQL

Tahukah Anda bahwa Anda dapat mengedit konten SQL sendiri? Jika Anda melakukannya, Anda tidak hanya membantu meningkatkan dokumentasi kami, tetapi Anda juga dikreditkan sebagai kontributor ke halaman.

Untuk informasi selengkapnya, lihat Cara berkontribusi pada dokumentasi SQL Server