Melakukan Failover Manual Paksa Grup Ketersediaan AlwaysOn (SQL Server)

Berlaku untuk: SQL Server (semua versi yang didukung)

Topik 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 dimaksudkan secara ketat 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 Anda memaksa failover hanya jika Anda harus segera memulihkan layanan ke grup ketersediaan dan Anda bersedia kehilangan data.

Setelah failover paksa, target failover tempat grup ketersediaan di-failover menjadi replika utama baru. Database sekunder di replika sekunder yang tersisa ditangguhkan dan harus dilanjutkan secara manual. Ketika replika utama sebelumnya tersedia, replika beralih ke peran sekunder, menyebabkan database utama sebelumnya menjadi database sekunder dan transisi ke status SUSPENDED. Sebelum melanjutkan database sekunder tertentu, Anda mungkin dapat memulihkan data yang hilang dari database tersebut. Namun, perhatikan bahwa pemotokan 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 dilanjutkan. Untuk informasi tentang melanjutkan database sekunder, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa nanti di artikel ini.

Melakukan failover paksa diperlukan dalam situasi darurat berikut:

  • Setelah memaksa kuorum pada kluster WSFC (kuorum paksa), Anda perlu memaksa failover setiap grup ketersediaan (dengan kemungkinan kehilangan data). Memaksa failover diperlukan karena status nyata dari nilai kluster WSFC mungkin telah hilang. Namun, Anda dapat menghindari kehilangan data, jika 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 Dipaksakan, nanti dalam topik ini.

    Penting

    Jika kuorum diperoleh kembali dengan cara alami alih-alih dipaksakan, replika ketersediaan akan melalui pemulihan 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 memaksa kuorum, lihat Pemulihan Bencana WSFC melalui Kuorum Paksa (SQL Server). Untuk informasi tentang mengapa memaksa failover diperlukan setelah memaksa kuorum, lihat Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

  • 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 status SEKUNDER atau PENYELESAIAN. Jika memungkinkan, paksa failover ke replika sekunder synchronous-commit yang disinkronkan ketika replika utama hilang.

    Tip

    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.

Catatan

Untuk informasi selengkapnya tentang prasyarat dan rekomendasi untuk memaksa failover dan misalnya skenario yang menggunakan failover paksa untuk pulih dari kegagalan besar, lihat Contoh Skenario: Menggunakan Failover Paksa untuk Pulih dari Kegagalan Bencana, nanti dalam topik ini.

Batasan dan Pembatasan

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

  • Kehilangan data dimungkinkan selama failover 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 MENGEMBALIKAN atau MENGINISIALISASI, memaksa failover akan menyebabkan database gagal dimulai sebagai database utama. Jika database berada dalam status INISIALISASI maka Anda harus menerapkan rekaman log yang hilang dari cadangan database atau memulihkan database sepenuhnya dari awal. Jika database berada dalam status MENGEMBALIKAN, Anda harus sepenuhnya memulihkan database dari cadangan.

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

  • Konsistensi lintas database di seluruh database dalam grup ketersediaan mungkin tidak dipertahankan pada failover.

    Catatan

    Dukungan untuk transaksi lintas database dan terdistribusi bervariasi menurut SQL Server dan versi sistem operasi. Untuk informasi selengkapnya, lihat Transaksi Lintas Database dan Transaksi Terdistribusi untuk Grup Ketersediaan AlwaysOn dan Pencerminan Database (SQL Server).

Prasyarat

Rekomendasi

  • Jangan paksa failover saat replika utama masih berjalan.

  • Jika memungkinkan, paksa failover hanya ke target failover yang database sekundernya berada dalam status NOT SYNCHRONIZED, SYNCHRONIZED, atau SYNCHRONIZING. Untuk informasi tentang implikasi memaksa failover saat database sekunder berada dalam status MENGINISIALISASI atau MENGEMBALIKAN, lihat Batasan dan Pembatasan, sebelumnya dalam topik ini.

  • Biasanya, latensi database sekunder tertentu, relatif terhadap database utama, harus serupa pada replika sekunder penerapan asinkron yang berbeda. Namun, saat memaksa failover, kehilangan data dapat menjadi perhatian yang signifikan. 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.

    Tip

    Untuk membandingkan LSN akhir log, sambungkan ke setiap replika sekunder online, pada gilirannya, dan sys.dm_hadr_database_replica_states kueri untuk nilai end_of_log_lsn dari setiap database sekunder lokal. Kemudian, bandingkan LSN akhir log dari salinan yang berbeda dari setiap database. Perhatikan bahwa 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 di database yang berbeda. Artinya, untuk database mana yang paling ingin Anda minimalkan kemungkinan kehilangan data?

  • Jika klien dapat terhubung ke primer asli, failover paksa menimbulkan beberapa risiko perilaku split brain. Sebelum Anda memaksa failover, kami sangat menyarankan Agar Anda mencegah klien mengakses replika utama asli. Jika tidak, setelah failover dipaksa, database utama asli dan database utama saat ini dapat diperbarui secara independen dari yang lain.

Cara Potensial Untuk Menghindari Kehilangan Data Setelah Kuorum Dipaksa

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

  • Jika replika utama asli online

    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 membawa replika utama kembali online. Karena Anda melakukan failover paksa ke replika utama asli, tidak ada kehilangan data.

  • Jika replika sekunder synchronous-commit yang disinkronkan online

    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 habis pada saat kuorum hilang, Anda dapat menentukan apakah kehilangan data dapat terjadi pada database tertentu dengan mengkueri kolom is_failover_ready dari tampilan 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 habis pada kuorum waktu 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 saat kegagalan. Untuk informasi selengkapnya, lihat "Mengapa Failover Paksa Diperlukan Setelah Memaksa Kuorum" dalam Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

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

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

    Catatan

    Ketika Anda memaksa failover ke replika sekunder, jumlah kehilangan data akan bergantung pada seberapa jauh target failover tertinggal dari 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 Mode Failover dan Failover (Grup Ketersediaan AlwaysOn).

Izin

Memerlukan izin UBAH GRUP KETERSEDIAAN pada grup ketersediaan, izin GRUP KETERSEDIAAN KONTROL, izin UBAH GRUP KETERSEDIAAN APA PUN, atau izin SERVER KONTROL.

Menggunakan SQL Server Management Studio

Untuk memaksa failover (dengan kemungkinan kehilangan data)

  1. Dalam Object Explorer, sambungkan ke instans server yang menghosting replika yang perannya dalam status SEKUNDER atau PENYELESAIAN dalam grup ketersediaan yang perlu di-failover, dan perluas pohon server.

  2. Perluas node Ketersediaan Tinggi AlwaysOn dan node Grup Ketersediaan .

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

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

  5. Setelah memaksa grup ketersediaan gagal, selesaikan langkah-langkah tindak lanjut yang diperlukan. Untuk informasi selengkapnya, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa, nanti dalam topik ini.

Menggunakan T-SQL

Untuk memaksa failover (dengan kemungkinan kehilangan data)

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

  2. Gunakan pernyataan UBAH GRUP KETERSEDIAAN , sebagai berikut:

    MENGUBAH FORCE_FAILOVER_ALLOW_DATA_LOSS group_name GRUP KETERSEDIAAN

    di mana group_name adalah nama grup ketersediaan.

    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 grup ketersediaan gagal, selesaikan langkah-langkah tindak lanjut yang diperlukan. Untuk informasi selengkapnya, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa, nanti dalam topik ini.

Menggunakan PowerShell

Untuk memaksa failover (dengan kemungkinan kehilangan data)

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

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

    • -AllowDataLoss

      Secara default parameter -AllowDataLoss menyebabkan Switch-SqlAvailabilityGroup meminta Anda untuk mengingatkan Anda bahwa memaksa failover dapat mengakibatkan hilangnya transaksi yang tidak dilakukan dan meminta konfirmasi. Untuk melanjutkan, masukkan Y; untuk membatalkan operasi, masukkan N.

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

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

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

      Contoh berikut melakukan failover paksa (dengan kemungkinan kehilangan data) dari grup MyAg ketersediaan 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 cmdlet Get-Help di lingkungan SQL Server PowerShell. Untuk informasi selengkapnya, lihat Mendapatkan Bantuan SQL Server PowerShell.

  3. Setelah memaksa grup ketersediaan gagal, selesaikan langkah-langkah tindak lanjut yang diperlukan. Untuk informasi selengkapnya, lihat Tindak Lanjut: Tugas Penting Setelah Failover Paksa, nanti dalam topik ini.

Untuk menyiapkan dan menggunakan penyedia PowerShell SQL Server

Tindak Lanjut: Tugas Penting Setelah Failover Paksa

  1. Setelah failover paksa, replika sekunder yang Anda failover 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:

  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 setiap 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 pasca-failover, Anda harus mencoba membuat rekam jepret database pada database yang ditangguhkan pada salah satu database sekunder penerapan sinkron.

    Penting

    Pemotongan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Juga kesehatan sinkronisasi replika sekunder penerapan sinkron tidak dapat beralih ke SEHAT selama database lokal tetap ditangguhkan.

    Untuk membuat rekam jepret database

    Untuk melanjutkan database ketersediaan

    Perhatian

    Setelah melanjutkan semua database sekunder, sebelum mencoba melakukan failover pada grup lagi, tunggu setiap database sekunder pada target failover berikutnya untuk memasuki status SYNCHRONIZING. Jika ada database yang belum DISINKRONKAN, database tersebut akan dicegah untuk online sebagai database utama, dan membuat ulang 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 akan kembali ke replika ketersediaan atau akan mengembalikan terlambat bagi Anda untuk menunda pemotongan log transaksi pada database utama baru, pertimbangkan untuk menghapus replika yang gagal dari grup ketersediaan untuk menghindari kehabisan ruang disk untuk file log Anda.

    Untuk menghapus replika sekunder

  4. Jika Anda mengikuti failover paksa dengan satu atau beberapa failover paksa tambahan, lakukan pencadangan log setelah setiap failover paksa tambahan dalam seri. 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

Contoh Skenario: Menggunakan Failover Paksa untuk Pulih dari Kegagalan Bencana

Jika replika utama gagal dan tidak ada replika sekunder yang disinkronkan yang tersedia, memaksa grup ketersediaan gagal mungkin merupakan respons yang sesuai. Kelayakan memaksa failover tergantung pada: (1) apakah Anda mengharapkan replika utama offline lebih lama dari toleransi perjanjian tingkat layanan (SLA) Anda, dan (2) apakah Anda bersedia mengambil risiko potensi kehilangan data untuk 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 besar, topik ini menyajikan satu skenario pemulihan bencana yang mungkin. Skenario contoh mempertimbangkan grup ketersediaan yang topologi aslinya terdiri dari pusat data utama yang menghosting tiga replika ketersediaan penerapan sinkron, termasuk replika utama, dan pusat data jarak jauh yang menghosting dua replika sekunder penerapan asinkron. Gambar berikut mengilustrasikan topologi asli grup ketersediaan contoh 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).

Topologi asli grup ketersediaan

Pusat data utama dimatikan secara tiba-tiba. Tiga replika ketersediaannya menjadi offline, dan databasenya menjadi tidak tersedia. Gambar berikut menggambarkan dampak kegagalan ini pada topologi grup ketersediaan.

Topologi setelah kegagalan Topologi pusat data utama

Administrator database (DBA) menentukan bahwa respons terbaik adalah memaksa failover grup ketersediaan ke salah satu replika sekunder penerapan asinkron jarak jauh. Contoh ini menggambarkan langkah-langkah umum yang terlibat ketika Anda memaksa failover grup ketersediaan ke replika jarak jauh dan, akhirnya, mengembalikan grup ketersediaan ke topologi aslinya.

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

Menanggapi Kegagalan Bencana Pusat Data Utama

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

Langkah-langkah untuk merespons kegagalan Langkah-langkah 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 Kuorum Paksa (SQL Server)
2. DBA terhubung ke instans server dengan latensi paling sedikit (pada Simpul 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 (Transact-SQL) (Kueri kolom end_of_log_lsn . Untuk informasi selengkapnya, lihat Rekomendasi, sebelumnya dalam topik ini.)
3. DBA secara manual melanjutkan masing-masing database sekunder pada replika sekunder yang tersisa. Melanjutkan Database Ketersediaan (SQL Server)

Mengembalikan Grup Ketersediaan ke Topologi Aslinya

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

Penting

Jika kuorum kluster WSFC telah dipaksa, karena node offline memulai ulang, mereka dapat membentuk kuorum baru jika kondisi berikut ada: (a) tidak ada konektivitas jaringan antara salah satu node dalam set kuorum paksa, dan (b) node yang memulai ulang adalah sebagian besar 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 untuk mengembalikan grup ke langkah topologi aslinya

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

Langkah Tautan
1. Simpul di pusat data utama kembali online dan membangun kembali komunikasi dengan kluster WSFC. Replika ketersediaan mereka online sebagai replika sekunder dengan database yang ditangguhkan, dan DBA harus segera melanjutkan masing-masing database ini secara manual. Melanjutkan Database Ketersediaan (SQL Server)

Tips: Jika Anda khawatir tentang kemungkinan kehilangan data pada database utama pasca-failover, Anda harus mencoba membuat rekam jepret database pada database yang ditangguhkan pada satu database sekunder penerapan sinkron. Perlu diingat bahwa pemotokan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Juga kesehatan sinkronisasi replika sekunder synchronous-commit tidak dapat beralih ke HEALTHY selama database lokal tetap ditangguhkan.
2. Setelah database dilanjutkan, DBA mengubah replika utama baru menjadi mode penerapan sinkron untuk sementara. Ini melibatkan dua langkah:

1) Ubah satu replika ketersediaan offline ke mode penerapan asinkron.

2) Ubah replika utama baru ke mode penerapan sinkron. Catatan: Langkah ini memungkinkan database sekunder synchronous-commit yang dilanjutkan menjadi SYNCHRONIZED.
Mengubah Mode Ketersediaan Replika Ketersediaan (SQL Server)
3. Setelah replika sekunder synchronous-commit pada Node 03 (replika utama asli) memasuki status sinkronisasi HEALTHY, DBA melakukan failover manual yang direncanakan ke replika tersebut, untuk menjadikannya replika utama lagi. Replika pada Node 04 kembali menjadi replika sekunder. sys.dm_hadr_database_replica_states (Transact-SQL)

Gunakan Kebijakan AlwaysOn untuk Melihat Kesehatan Grup Ketersediaan (SQL Server)

Melakukan Failover Manual Terencana dari Grup Ketersediaan (SQL Server)
4. DBA terhubung ke replika utama baru dan:

1) Mengubah replika utama sebelumnya (di pusat jarak jauh) kembali ke mode penerapan asinkron.

2) Mengubah replika sekunder penerapan asinkron di pusat data utama kembali ke mode penerapan sinkron.
Mengubah Mode Ketersediaan Replika Ketersediaan (SQL Server)

Tugas Terkait

Untuk menyesuaikan suara kuorum

Failover manual yang direncanakan:

Pemecahan masalah:

Konten terkait

Lihat juga

Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Mode Ketersediaan (Grup Ketersediaan AlwaysOn)
Mode Failover dan Failover (Grup Ketersediaan AlwaysOn)
Tentang Akses Koneksi Klien ke Replika Ketersediaan (SQL Server)
Pemantauan Grup Ketersediaan (SQL Server)
Pengklusteran Failover Windows Server (WSFC) dengan SQL Server