Melakukan failover paksa manual dari grup ketersediaan Always On (SQL Server)

Berlaku untuk:SQL Server

Artikel ini menjelaskan cara melakukan failover paksa (dengan kemungkinan kehilangan data) pada grup ketersediaan AlwaysOn dengan menggunakan SQL Server Management Studio, Transact-SQL, atau PowerShell di SQL Server. Failover paksa adalah bentuk failover manual yang secara khusus dimaksudkan untuk pemulihan bencana, ketika failover manual yang direncanakan tidak dimungkinkan. Jika Anda memaksa failover ke replika sekunder yang tidak disinkronkan, beberapa kehilangan data dimungkinkan. Oleh karena itu, kami sangat menyarankan Agar Anda memaksa failover hanya jika Anda harus segera memulihkan layanan ke grup ketersediaan dan Anda bersedia mengambil risiko kehilangan data.

Setelah failover paksa, target failover yang menjadi tempat berpindahnya grup ketersediaan menjadi replika utama baru. Database sekunder pada replika sekunder yang tersisa ditangguhkan dan harus dilanjutkan secara manual. Ketika replika utama sebelumnya tersedia, replika tersebut beralih ke peran sekunder, menyebabkan database utama sebelumnya menjadi database sekunder dan transisi ke SUSPENDED status. Sebelum melanjutkan database sekunder tertentu, Anda mungkin dapat memulihkan data yang hilang dari database tersebut. Namun, perhatikan bahwa pemotongan log transaksi tertunda pada database utama tertentu saat salah satu database sekundernya ditangguhkan.

Penting

Sinkronisasi data dengan database utama tidak akan terjadi sampai database sekunder diaktifkan kembali. Untuk informasi tentang melanjutkan database sekunder, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa di bagian selanjutnya dari artikel ini.

Melakukan failover paksa diperlukan dalam situasi darurat berikut:

• Setelah memaksa kuorum pada kluster WSFC (kuorum paksa), Anda perlu memaksa failover pada setiap grup ketersediaan (dengan potensi kehilangan data). Memaksa failover diperlukan karena status nyata dari nilai kluster WSFC mungkin telah hilang. Namun, Anda dapat menghindari kehilangan data, jika Anda dapat memaksa failover pada instans server yang menghosting replika yang merupakan replika utama sebelum Anda memaksa kuorum atau ke replika sekunder yang disinkronkan sebelum Anda memaksa kuorum. Untuk informasi selengkapnya, lihat Cara Potensial untuk Menghindari Kehilangan Data Setelah Kuorum Dipaksa, nanti di artikel ini.

  Penting

  Jika kuorum dapat dipulihkan dengan cara alami alih-alih dipaksakan, replika ketersediaan menjalani pemulihan yang normal. Jika replika utama masih tidak tersedia setelah kuorum diperoleh kembali, Anda dapat melakukan failover manual yang direncanakan ke replika sekunder yang disinkronkan.

  Untuk informasi tentang pemaksaan kuorum, lihat Pemulihan Bencana WSFC melalui Kuorum Paksa (SQL Server). Untuk informasi tentang mengapa memaksa failover diperlukan setelah memaksa quorum, lihat Failover dan Mode Failover (Grup Ketersediaan Always On).

• Jika replika utama menjadi tidak tersedia ketika kluster WSFC memiliki kuorum yang sehat, Anda dapat memaksa failover (dengan kemungkinan kehilangan data), ke replika apa pun yang perannya berada dalam keadaan SECONDARY atau RESOLVING. Jika memungkinkan, paksa failover ke replika sekunder synchronous-commit yang disinkronkan ketika replika utama hilang.

  Tips

  Ketika kluster WSFC memiliki kuorum yang sehat, jika Anda mengeluarkan perintah failover paksa pada replika sekunder yang disinkronkan, replika benar-benar melakukan failover manual yang direncanakan.

Untuk informasi selengkapnya tentang prasyarat dan rekomendasi untuk memaksa failover dan untuk contoh skenario yang menggunakan failover paksa untuk pulih dari kegagalan bencana, lihat Contoh skenario: Gunakan failover paksa untuk pulih dari kegagalan bencana, nanti di artikel ini.

Keterbatasan

• Satu-satunya waktu Anda tidak dapat melakukan failover paksa adalah ketika kluster Windows Server Failover Clustering (WSFC) tidak memiliki kuorum.

• Kehilangan data bisa terjadi selama pemutusan paksa grup ketersediaan. Selain itu, jika replika utama berjalan saat Anda memulai failover paksa, klien mungkin masih terhubung ke database utama sebelumnya. Oleh karena itu, kami sangat menyarankan Agar Anda memaksa failover hanya jika replika utama tidak lagi berjalan dan jika Anda bersedia mengambil risiko kehilangan data untuk memulihkan akses ke database dalam grup ketersediaan.

• Ketika database sekunder berada dalam status REVERTING atau INITIALIZING , memaksa failover akan menyebabkan database gagal dimulai sebagai database utama. Jika database berada dalam status INITIALIZING maka Anda perlu menerapkan rekaman log yang hilang dari cadangan database atau memulihkan database sepenuhnya dari awal. Jika database berada dalam status REVERTING Anda perlu memulihkan database sepenuhnya dari cadangan.

• Perintah failover kembali segera setelah target failover menerima perintah. Namun, pemulihan database terjadi secara asinkron setelah grup ketersediaan selesai melakukan failover.

• Konsistensi lintas database di seluruh database dalam grup ketersediaan secara keseluruhan mungkin tidak dapat dipertahankan saat terjadi failover.

  Catatan

  Dukungan untuk transaksi lintas database dan terdistribusi bervariasi menurut SQL Server dan versi sistem operasi. Untuk informasi selengkapnya, lihat Transaksi - grup ketersediaan dan pencerminan database.

Prasyarat

• Kluster WSFC memiliki kuorum. Jika kluster tidak memiliki kuorum, lihat Pemulihan Bencana WSFC melalui Kuorum Paksa (SQL Server).

• Anda harus dapat terhubung ke instans server yang menghosting replika yang perannya berada dalam status SECONDARY atau RESOLVING .

Rekomendasi

• Jangan paksa failover saat replika utama masih berjalan.

• Jika memungkinkan, paksa failover ke target failover hanya jika database sekundernya berada di status NOT SYNCHRONIZED, SYNCHRONIZED, atau SYNCHRONIZING. Untuk informasi tentang implikasi memaksa failover saat database sekunder berada dalam INITIALIZING status atau REVERTING , lihat Batasan sebelumnya di artikel ini.

• Biasanya, latensi database sekunder tertentu, relatif terhadap database utama, harus mirip pada komit asinkron pada replika sekunder yang berbeda. Namun, kehilangan data dapat menjadi perhatian yang signifikan saat memaksa failover. Oleh karena itu, pertimbangkan untuk meluangkan waktu untuk menentukan latensi relatif salinan database pada replika sekunder yang berbeda. Untuk menentukan salinan database sekunder tertentu yang memiliki latensi paling sedikit, bandingkan LSN akhir log mereka. LSN akhir log yang lebih tinggi menunjukkan lebih sedikit latensi.

  Tips

  Untuk membandingkan LSN akhir log, sambungkan secara berurutan ke setiap replika sekunder online, dan lakukan kueri pada sys.dm_hadr_database_replica_states untuk mendapatkan nilai dari setiap database sekunder lokal. Kemudian, bandingkan LSN akhir log dari salinan yang berbeda dari setiap database. Database yang berbeda mungkin memiliki LSN tertinggi pada replika sekunder yang berbeda. Dalam hal ini, target failover yang paling tepat tergantung pada kepentingan relatif yang Anda tempatkan pada data dalam database yang berbeda. Artinya, untuk database mana yang paling ingin Anda minimalkan kemungkinan kehilangan data?

• Jika klien dapat terhubung ke primer utama, failover paksa menimbulkan beberapa risiko perilaku pembagian otak. Sebelum Anda memaksa failover, kami sangat menyarankan agar Anda mencegah klien mengakses replika utama asli. Selain itu, setelah failover dipaksa, database utama asli dan database utama sekarang dapat diperbarui secara independen satu sama lain.

Metode potensial untuk menghindari kehilangan data setelah pemaksaan kuorum

Dalam beberapa kondisi kegagalan setelah kuorum hilang, Anda dapat mencegah kehilangan data sebagai berikut:

• Jika replika utama asli kembali aktif

  Jika kuorum hilang dan memaksa kuorum WSFC memulihkan node kluster yang menghosting replika utama grup ketersediaan, Anda dapat mencegah kehilangan data untuk grup ketersediaan ini. Sambungkan ke replika utama dan lakukan failover paksa (FAILOVER_ALLOW_DATA_LOSS). Ini mengaktifkan kembali replika utama. Karena Anda melakukan failover paksa ke replika utama asli, tidak ada kehilangan data.

• Jika replika sekunder komit sinkron yang tersinkronisasi beroperasi

  Jika kuorum hilang dan memaksa kuorum WSFC memulihkan node kluster yang menghosting replika sekunder yang disinkronkan untuk grup ketersediaan, Anda harus dapat mencegah kehilangan data untuk grup ketersediaan ini. Jika simpul yang dipulihkan sedang aktif pada saat kuorum hilang, Anda dapat menentukan apakah kehilangan data dapat terjadi pada database tertentu dengan melakukan kueri kolom is_failover_ready dari pandangan manajemen dinamis sys.dm_hadr_database_replica_cluster_states. Misalnya, untuk instans server bernama sql108w2k8r22, terbitkan kueri berikut:

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  Perhatian

  Jika simpul yang dipulihkan tidak aktif pada saat kuorum hilang, is_failover_ready mungkin tidak mencerminkan status aktual kluster pada saat replika utama offline. Oleh karena itu, nilai is_failover_ready hanya baik jika node host pada waktu kegagalan terjadi. Untuk informasi selengkapnya, lihat "Mengapa Failover Paksa Diperlukan Setelah Memaksa Kuorum" dalam Failover dan Mode Failover (Grup Ketersediaan Always On).

  Jika is_failover_ready = 1, database ditandai sebagai tersinkronisasi dalam kluster dan siap untuk pemindahan otomatis. Jika is_failover_ready = 1 dikonfigurasi pada setiap database replika sekunder tertentu, Anda dapat melakukan failover paksa (FORCE_FAILOVER_ALLOW_DATA_LOSS) tanpa kehilangan data pada replika sekunder ini. Replika sekunder yang disinkronkan menjadi aktif sebagai peran utama, yaitu sebagai replika utama yang baru, dengan semua data utuh.

  Jika is_failover_ready = 0, database tidak ditandai sebagai disinkronkan dalam kluster dan belum siap untuk failover manual yang direncanakan. Jika Anda memaksa failover ke replika sekunder host, data hilang pada database ini.

  Catatan

  Ketika Anda memaksa failover ke replika sekunder, jumlah kehilangan data tergantung pada seberapa jauh target failover tertinggal di belakang replika utama. Sayangnya, ketika kluster WSFC tidak memiliki kuorum atau kuorum yang dipaksakan, Anda tidak dapat menilai jumlah potensi kehilangan data. Namun, perhatikan bahwa setelah kluster WSFC mendapatkan kembali kuorum yang sehat, Anda dapat mulai melacak potensi kehilangan data. Untuk informasi selengkapnya, lihat "Melacak Potensi Kehilangan Data" dalam Failover dan Mode Failover (Grup Ketersediaan Always On).

Perizinan

ALTER AVAILABILITY GROUP Memerlukan izin pada grup ketersediaan, CONTROL AVAILABILITY GROUP izin, ALTER ANY AVAILABILITY GROUP izin, atau CONTROL SERVER izin.

Menggunakan SQL Server Management Studio

1. Di Object Explorer, sambungkan ke instans server yang menghosting replika yang perannya berada dalam status SECONDARY atau RESOLVING dalam grup ketersediaan yang perlu dipindahkan ke status lain, lalu perluas pohon server tersebut.

2. Perluas node Always On High Availability dan node Grup Ketersediaan.

3. Klik kanan grup ketersediaan yang akan di-failover, dan pilih perintah Failover .

4. Ini akan meluncurkan Wizard untuk Grup Ketersediaan Failover. Untuk informasi selengkapnya, lihat Gunakan Wizard Grup Ketersediaan Fail Over (SQL Server Management Studio).

5. Setelah memaksa failover pada grup ketersediaan, selesaikan langkah-langkah tindak lanjut yang diperlukan. Untuk informasi selengkapnya, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa, nanti di artikel ini.

Menggunakan Transact-SQL

1. Sambungkan ke instans server yang menghosting replika yang perannya berada dalam SECONDARY status atau RESOLVING dalam grup ketersediaan yang perlu di-failover.

2. Gunakan pernyataan ALTER AVAILABILITY GROUP , sebagai berikut, di mana group_name adalah nama grup ketersediaan:

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

   Contoh berikut memaksa AccountsAG grup ketersediaan untuk melakukan failover ke replika sekunder lokal.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Setelah memaksa failover pada grup ketersediaan, selesaikan langkah-langkah tindak lanjut yang diperlukan. Untuk informasi selengkapnya, lihat Tugas penting setelah failover paksa, nanti di artikel ini.

Menggunakan PowerShell

1. Ubah direktori (cd) ke instans server yang menghosting replika yang perannya berada dalam SECONDARY status atau RESOLVING dalam grup ketersediaan yang perlu di-failover.

2. Switch-SqlAvailabilityGroup Gunakan cmdlet dengan AllowDataLoss parameter dalam salah satu bentuk berikut:

   • -AllowDataLoss

     Secara default, parameter -AllowDataLoss menyebabkan Switch-SqlAvailabilityGroup meminta Anda untuk mengonfirmasi dengan mengingatkan bahwa memaksa failover dapat mengakibatkan hilangnya transaksi yang belum diselesaikan. Untuk melanjutkan, masukkan Y; untuk membatalkan operasi, masukkan N.

     Contoh berikut melakukan failover paksa (dengan kemungkinan kehilangan data) dari grup ketersediaan MyAg ke replika sekunder pada instans server dengan nama SecondaryServer\InstanceName. Anda diminta untuk mengonfirmasi operasi ini.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     Untuk memulai failover paksa tanpa konfirmasi, tentukan keduanya, parameter -AllowDataLoss dan -Force. Ini berguna jika Anda ingin menyertakan perintah dalam skrip dan menjalankannya tanpa interaksi pengguna. Namun, gunakan dengan hati-hati opsi -Force, karena failover paksa dapat mengakibatkan hilangnya data dari database yang merupakan bagian dari grup ketersediaan.

     Contoh berikut melakukan failover paksa (dengan kemungkinan kehilangan data) dari grup ketersediaan MyAg ke instans server bernama SecondaryServer\InstanceName. Opsi -Force menekan konfirmasi operasi ini.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Catatan

   Untuk melihat sintaks cmdlet, gunakan Get-Help cmdlet di lingkungan PowerShell SQL Server. Untuk informasi selengkapnya, lihat Mendapatkan Bantuan SQL Server PowerShell.

3. Setelah memaksa failover pada grup ketersediaan, selesaikan langkah-langkah tindak lanjut yang diperlukan. Untuk informasi selengkapnya, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa, nanti di artikel ini.

Menyiapkan dan menggunakan penyedia PowerShell SQL Server

• SQL Server Provider PowerShell

Tindak Lanjut: Tugas penting setelah failover paksa

1. Setelah failover paksa, replika sekunder yang di-switch over menjadi replika utama baru. Namun, untuk membuat replika ketersediaan tersebut dapat diakses oleh klien, Anda mungkin perlu mengonfigurasi ulang kuorum WSFC atau menyesuaikan konfigurasi mode ketersediaan grup ketersediaan, sebagai berikut:

   • Jika Anda melakukan failover di luar set failover otomatis: Sesuaikan suara kuorum simpul WSFC untuk mencerminkan konfigurasi grup ketersediaan baru Anda. Jika simpul WSFC yang menjadi host replika sekunder target tidak memiliki suara kuorum WSFC, Anda mungkin perlu memaksakan kuorum WSFC.

     Set failover otomatis hanya ada jika dua replika ketersediaan (termasuk replika utama sebelumnya) dikonfigurasi untuk mode penerapan sinkron dengan failover otomatis.

     Untuk menyesuaikan suara kuorum

     • Lihat Pengaturan NodeWeight Kuorum Kluster
     • Konfigurasi Pengaturan Bobot Node Kuorum Kluster
     • Paksakan Kluster WSFC untuk Memulai Tanpa Kuorum

   • Jika Anda melakukan failover di luar set failover komit sinkron: Kami sarankan Anda mempertimbangkan untuk menyesuaikan mode ketersediaan dan mode failover pada replika utama baru dan pada replika sekunder yang tersisa untuk mencerminkan konfigurasi komit sinkron dan failover otomatis yang diinginkan.

     Catatan

     Set failover komit sinkron hanya ada jika replika utama saat ini dikonfigurasi untuk mode komit sinkron.

     Untuk mengubah mode ketersediaan dan mode failover

     • Mengubah mode ketersediaan replika dalam grup ketersediaan AlwaysOn
     • Mengubah mode failover untuk replika dalam grup ketersediaan Always On

2. Setelah failover paksa, semua database sekunder ditangguhkan. Ini termasuk database utama sebelumnya, setelah replika utama sebelumnya kembali online dan menemukan bahwa sekarang menjadi replika sekunder. Anda harus melanjutkan setiap database yang ditangguhkan secara manual, satu per satu, pada masing-masing replika sekunder.

   Saat database sekunder dilanjutkan, database tersebut memulai sinkronisasi data dengan database utama yang sesuai. Database sekunder mengembalikan rekaman log apa pun yang tidak pernah dilakukan pada database utama baru. Oleh karena itu, jika Anda khawatir tentang kemungkinan kehilangan data pada database utama setelah gagal-alih, Anda harus mencoba membuat cuplikan database pada database yang dihentikan sementara di salah satu database sekunder dengan komitmen sinkron.

   Penting

   Pemotongan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Status kesehatan sinkronisasi replika sekunder komitmen sinkron juga tidak dapat beralih ke HEALTHY selama ada database lokal yang tetap ditangguhkan.

   Untuk membuat cuplikan basis data

   • Membuat rekam jepret database (Transact-SQL)

   Untuk melanjutkan kembali basis data ketersediaan

   • Melanjutkan Database Ketersediaan (SQL Server)

   Perhatian

   Setelah menyetel semua database sekunder, sebelum mencoba melakukan failover ulang grup, tunggu hingga setiap database sekunder pada target failover berikutnya memasuki status SYNCHRONIZING . Jika ada database yang belum SYNCHRONIZING, database tersebut dicegah untuk online sebagai database utama, dan membuat kembali sinkronisasi data untuk database mungkin memerlukan pemulihan log transaksi, memulihkan cadangan database lengkap, atau melakukan failover kembali ke replika utama sebelumnya.

3. Jika replika ketersediaan yang gagal tidak dapat kembali ke replika ketersediaan atau mungkin terlalu terlambat bagi Anda untuk menunda pemotongan log transaksi pada database utama baru, sebaiknya pertimbangkan untuk menghapus replika yang gagal dari grup ketersediaan untuk mencegah kehabisan ruang disk untuk file log Anda.

   Untuk menghapus replika sekunder

   • Menghapus Replika Sekunder dari Grup Ketersediaan (SQL Server)

4. Jika Anda mengikuti failover paksa dengan satu atau beberapa failover paksa tambahan, lakukan pencadangan log setelah setiap failover paksa tambahan dalam rangkaian. Untuk informasi tentang alasannya, lihat bagian "Risiko Memaksa Failover" di bagian "Failover Manual Paksa (dengan Kemungkinan Kehilangan Data)" dari Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

   Untuk melakukan pencadangan log

   • Mencadangkan log transaksi

Contoh skenario: Gunakan failover paksa untuk pulih dari kegagalan bencana

Jika replika utama gagal dan tidak ada replika sekunder yang disinkronkan yang tersedia, memaksa grup ketersediaan untuk melakukan failover mungkin merupakan respons yang sesuai. Kelayakan memaksa failover bergantung pada: (1) apakah Anda mengharapkan replika utama offline lebih lama dari yang ditoleransi oleh perjanjian tingkat layanan (SLA) Anda, dan (2) apakah Anda bersedia mempertaruhkan potensi kehilangan data agar dapat membuat database utama tersedia dengan cepat. Jika Anda memutuskan bahwa grup ketersediaan memerlukan failover paksa, failover paksa aktual hanyalah satu langkah dari proses multi-langkah.

Untuk mengilustrasikan langkah-langkah yang diperlukan untuk menggunakan failover paksa untuk pulih dari kegagalan bencana, artikel ini menyajikan satu skenario pemulihan bencana yang mungkin. Contoh skenario mempertimbangkan grup ketersediaan yang topologi aslinya terdiri dari pusat data utama yang menghosting tiga replika ketersediaan dengan komit sinkron, termasuk replika utama, dan pusat data jarak jauh yang menghosting dua replika sekunder dengan komit asinkron. Gambar berikut mengilustrasikan topologi asli dari contoh grup ketersediaan ini. Grup ketersediaan dihosting oleh kluster WSFC multi-subnet dengan tiga simpul di pusat data utama (Node 01, Node 02, dan Node 03) dan dua simpul di pusat data jarak jauh (Node 04 dan Node 05).

Pusat data utama dimatikan secara tak terduga. Tiga replika ketersediaan menjadi offline, dan database mereka menjadi tidak tersedia. Gambar berikut mengilustrasikan efek kegagalan ini pada topologi grup ketersediaan.

Administrator basis data (DBA) menentukan bahwa respons terbaik adalah memaksa failover kelompok ketersediaan ke salah satu replika sekunder komitmen asinkron jarak jauh. Contoh ini menggambarkan langkah-langkah umum yang terlibat saat Anda melakukan failover secara paksa dari grup ketersediaan ke replika jarak jauh. Kemudian, Anda mengembalikan grup ketersediaan ke topologi aslinya.

Respons kegagalan yang disajikan di sini terdiri dari dua fase berikut:

• Menanggapi kegagalan bencana pusat data utama
• Mengembalikan grup ketersediaan ke topologi aslinya

Menanggapi kegagalan bencana pusat data utama

Gambar berikut mengilustrasikan serangkaian tindakan yang dilakukan di pusat data jarak jauh sebagai respons kegagalan bencana di pusat data utama.

Langkah-langkah dalam gambar ini menunjukkan langkah-langkah berikut:

Langkah	Tindakan	Tautan
1.	DBA atau administrator jaringan memastikan bahwa kluster WSFC memiliki kuorum yang sehat. Dalam contoh ini, kuorum perlu dipaksakan.	Mode Kuorum WSFC dan Konfigurasi Pemungutan Suara (SQL Server) Pemulihan Bencana WSFC melalui Forced Quorum (SQL Server)
2.	DBA terhubung ke instans server dengan latensi paling sedikit (pada Node 04) dan melakukan failover manual paksa. Failover paksa mentransisikan replika sekunder ini ke peran utama dan menangguhkan database sekunder pada replika sekunder yang tersisa (pada Node 05).	sys.dm_hadr_database_replica_states (Kueri kolom end_of_log_lsn . Untuk informasi selengkapnya, lihat Rekomendasi, sebelumnya di artikel ini.)
3.	DBA secara manual mengaktifkan kembali masing-masing database sekunder pada replika sekunder yang tersisa.	Melanjutkan Database Ketersediaan (SQL Server)

Mengembalikan grup ketersediaan ke topologi aslinya

Gambar berikut menggambarkan serangkaian tindakan yang mengembalikan grup ketersediaan ke topologi aslinya setelah pusat data utama kembali online dan node WSFC membangun kembali komunikasi dengan kluster WSFC.

Penting

Jika kuorum klaster WSFC telah dipaksa, saat simpul offline mulai ulang, mereka dapat membentuk kuorum baru jika kedua kondisi berikut terpenuhi: (a) tidak ada konektivitas jaringan di antara salah satu simpul dalam set kuorum paksa, dan (b) simpul yang mulai ulang adalah mayoritas dari node kluster. Ini akan mengakibatkan kondisi "split brain" di mana grup ketersediaan akan memiliki dua replika utama independen, satu di setiap pusat data. Sebelum memaksa kuorum untuk membuat kumpulan kuorum minoritas, lihat Pemulihan Bencana WSFC melalui Kuorum Paksa (SQL Server).

Langkah-langkah dalam gambar ini menunjukkan langkah-langkah berikut:

Langkah	Tindakan	Tautan
1.	Simpul di pusat data utama kembali online dan membangun kembali komunikasi dengan kluster WSFC. Replika ketersediaan mereka muncul online sebagai replika sekunder dengan database yang ditangguhkan, dan DBA perlu dengan segera melanjutkan setiap database ini secara manual.	Melanjutkan Database Ketersediaan (SQL Server) Tip: Jika Anda khawatir tentang kemungkinan kehilangan data pada database utama pasca-failover, Anda harus mencoba membuat cuplikan basis data pada basis data yang ditangguhkan di salah satu basis data sekunder yang diterapkan dengan komit sinkron. Perlu diingat bahwa pemotongan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Juga status kesehatan sinkronisasi replika sekunder synchronous-commit tidak dapat beralih ke HEALTHY selama setiap database lokal tetap ditangguhkan.
2.	Setelah database dilanjutkan, DBA mengubah replika utama yang baru ke mode komit sinkron untuk sementara. Ini melibatkan dua langkah: 1. Ubah satu replika availabilitas offline ke mode komitmen asinkron. 2. Ubah replika utama baru ke mode komit sinkron. Nota: Langkah ini memungkinkan database sekunder komit sinkron yang berlanjut menjadi SYNCHRONIZED.	Mengubah mode ketersediaan replika dalam grup ketersediaan AlwaysOn
3.	Setelah replika sekunder dengan komit sinkronisasi pada Node 03 (yang merupakan replika utama asli) memasuki status sinkronisasi, DBA melakukan failover manual yang telah direncanakan ke replika tersebut, sehingga menjadi replika utama kembali. Replika pada Node 04 kembali menjadi replika sekunder.	sys.dm_hadr_database_replica_states Gunakan Kebijakan AlwaysOn untuk Melihat Kesehatan Grup Ketersediaan (SQL Server) Melakukan failover manual yang direncanakan dari grup ketersediaan AlwaysOn (SQL Server)
4.	DBA terhubung ke replika utama baru dan: 1. Mengubah replika utama primer sebelumnya (di pusat jarak jauh) kembali ke mode komit asinkron. 2. Mengubah replika sekunder komit asinkron di pusat data utama kembali ke mode komit sinkron.	Mengubah mode ketersediaan replika dalam grup ketersediaan AlwaysOn

Tugas terkait

Mengatur suara kuorum

• Lihat Pengaturan NodeWeight Kuorum Kluster
• Konfigurasi Pengaturan Bobot Node Kuorum Kluster
• Paksakan Kluster WSFC untuk Memulai Tanpa Kuorum

Failover manual yang direncanakan

• Melakukan failover manual yang telah direncanakan dari grup ketersediaan Always On (SQL Server)
• Menggunakan Wizard Grup Ketersediaan Failover (SQL Server Management Studio)

Troubleshoot

• Memecahkan Masalah Konfigurasi Grup Ketersediaan AlwaysOn (SQL Server)
• Mengatasi Operasi Penambahan File yang Gagal (Grup Ketersediaan AlwaysOn)

Konten terkait

• Blog Tim SQL Server Always On: Blog Resmi Tim SQL Server Always On
• Blog Teknisi CSS SQL Server
• Panduan Solusi AlwaysOn Microsoft SQL Server untuk Ketersediaan Tinggi dan Pemulihan Bencana
• Apa itu grup ketersediaan AlwaysOn?
• Perbedaan antara mode ketersediaan untuk grup ketersediaan AlwaysOn
• Mode Failover dan Failover (Grup Ketersediaan AlwaysOn)
• Jenis koneksi klien ke replika dalam grup ketersediaan AlwaysOn
• Alat untuk memantau grup ketersediaan AlwaysOn
• Pengklusteran Failover Windows Server dengan SQL Server