Pemulihan kelompok ketersediaan Always On di Linux

2025-07-03

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 otomatis dan manual yang terencana mempertahankan semua data Anda. AG mengalami kegagalan pada tingkat replika ketersediaan. Artinya, sebuah AG melakukan failover ke salah satu replika sekundernya (yaitu, target failover saat ini).

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

Peralihan 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

Dalam kondisi operasi normal, jangan beralih dengan menggunakan perkakas manajemen seperti Transact-SQL atau SQL Server, seperti SSMS atau PowerShell. Ketika CLUSTER_TYPE = EXTERNAL, satu-satunya nilai yang dapat diterima adalah FAILOVER_MODEEXTERNAL. 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 pengalihan manual

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

Failover secara manual dalam dua langkah.

Pertama, beralih secara manual dengan memindahkan sumber daya Grup Ketersediaan (AG) dari node kluster yang memiliki sumber daya ke simpul baru.

Kluster memindahkan sumber daya AG ke sistem cadangan dan menambahkan batasan lokasi. Batasan ini mengonfigurasi sumber daya untuk dijalankan pada simpul baru. Hapus batasan ini agar berhasil melakukan failover di masa mendatang.
Kedua, hapus batasan lokasi.

Langkah 1. Failover secara manual dengan cara 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 dalam 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 kendala yang dibuat karena failover manual.

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

Catatan

Nama sumber daya AG di kluster pacemaker pada Red Hat Enterprise Linux 8.x dan Ubuntu 18.04 mungkin menyerupai ag_cluster-clone karena nomenklatur mengenai sumber daya telah berkembang untuk menggunakan klon yang dapat dipromosikan.
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 pengalihan

Failover paksa dimaksudkan hanya 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 yang dipaksakan pada AG di Windows.

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

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. Contohnya:
```
sudo pcs resource delete <resourceName>
```
  Catatan
  
  Saat Anda menghapus sumber daya, sumber daya juga akan menghapus semua batasan terkait.
Pada instans SQL Server yang menghosting replika sekunder, atur variabel external_clusterkonteks sesi .
```
EXECUTE sp_set_session_context
    @key = N'external_cluster',
    @value = N'yes';
```
Lakukan failover pada Kelompok Ketersediaan (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;
```
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.
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. Sebaliknya, ubah replika asinkron menjadi sinkron, dan instruksi untuk failover manual normal.

Pemantauan pada tingkat basis data dan pemicu failover

Untuk CLUSTER_TYPE=EXTERNAL, semantik pemicu failover berbeda dibandingkan dengan WSFC. Ketika AG pada instans SQL Server di WSFC beralih keluar dari status ONLINE untuk database, kesehatan AG membuat laporan kesalahan. Sebagai respons, manajer kluster memicu tindakan failover. Di Linux, instans SQL Server tidak dapat berkomunikasi dengan kluster. Pemantauan untuk kesehatan database dilakukan dengan pendekatan luar-dalam. Jika pengguna memilih untuk pemantauan failover tingkat database dan failover (dengan mengatur opsi DB_FAILOVER=ON saat membuat AG), kluster memeriksa apakah status database adalah ONLINE setiap kali menjalankan tindakan pemantauan. Kluster memeriksa 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.

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 Mengedit dokumentasi Microsoft Learn.

Bagikan melalui