Melakukan Failover Manual Paksa Grup Ketersediaan AlwaysOn (SQL Server)
Berlaku untuk:
SQL Server
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 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 tempat grup ketersediaan di-failover menjadi replika utama baru. Database sekunder dalam 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 status SUSPENDED. 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 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 Dipaksa, 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 PEMECAHAN MASALAH. 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 untuk skenario contoh yang menggunakan failover paksa untuk pulih dari kegagalan bencana, 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
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 SEKUNDER atau PENYELESAIAN.
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 mirip 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 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 dalam 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 otak terpisah. 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.
Potensi Cara 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. Koneksi 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 penerapan sinkron 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 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 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 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 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 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)
Di Object Explorer, sambungkan ke instans server yang menghosting replika yang perannya berada dalam status SEKUNDER atau PENYELESAIAN dalam grup ketersediaan yang perlu di-failover, dan perluas pohon server.
Perluas node Ketersediaan Tinggi AlwaysOn dan node Grup Ketersediaan.
Klik kanan grup ketersediaan yang akan di-failover, dan pilih perintah Failover .
Ini meluncurkan Wizard Grup Ketersediaan Failover. Untuk informasi selengkapnya, lihat Menggunakan Wizard Grup Ketersediaan Fail Over (SQL Server Management Studio).
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)
Koneksi ke instans server yang menghosting replika yang perannya berada dalam status SEKUNDER atau PEMECAHAN MASALAH dalam grup ketersediaan yang perlu di-failover.
Gunakan pernyataan ALTER AVAILABILITY GROUP, sebagai berikut:
MENGUBAH FORCE_FAILOVER_ALLOW_DATA_LOSS group_name GRUP KETERSEDIAAN
di mana group_name adalah nama grup ketersediaan.
Contoh berikut memaksa
AccountsAGgrup ketersediaan untuk melakukan failover ke replika sekunder lokal.ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;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)
Ubah direktori (cd) ke instans server yang menghosting replika yang perannya berada dalam status SEKUNDER atau RESOLVING dalam grup ketersediaan yang perlu di-failover.
Gunakan cmdlet Switch-SqlAvailabilityGroup dengan parameter AllowDataLoss dalam salah satu formulir berikut:
-AllowDataLoss
Secara default -AllowDataLoss parameter 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
MyAgketersediaan ke replika sekunder pada instans server bernamaSecondaryServer\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
MyAgketersediaan ke instans server bernamaSecondaryServer\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 PowerShell SQL Server. Untuk informasi selengkapnya, lihat Mendapatkan Bantuan SQL Server PowerShell.
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
Setelah failover paksa, replika sekunder tempat Anda gagal 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 node WSFC yang menghosting replika sekunder target tidak memiliki suara kuorum WSFC, Anda mungkin perlu memaksa kuorum WSFC.
Catatan
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
Jika Anda melakukan failover di luar set failover penerapan sinkron: Kami sarankan Anda mempertimbangkan untuk menyesuaikan mode ketersediaan dan mode failover pada replika utama baru dan pada replika sekunder yang tersisa untuk mencerminkan penerapan sinkron dan konfigurasi failover otomatis yang diinginkan.
Catatan
Set failover penerapan sinkron hanya ada jika replika utama saat ini dikonfigurasi untuk mode penerapan sinkron.
Untuk mengubah mode ketersediaan dan mode failover
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 yang diterapkan secara sinkron.
Penting
Pemotongan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Juga kesehatan sinkronisasi replika sekunder synchronous-commit tidak dapat bertransisi ke SEHAT selama database lokal tetap ditangguhkan.
Untuk membuat rekam jepret database
Untuk melanjutkan database ketersediaan
Perhatian
Setelah meneruskan semua database sekunder, sebelum mencoba melakukan failover 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 membangun kembali sinkronisasi data untuk database mungkin memerlukan pemulihan log transaksi, memulihkan cadangan database lengkap, atau melakukan failover kembali ke replika utama sebelumnya.
Jika replika ketersediaan yang gagal tidak akan kembali ke replika ketersediaan atau akan kembali 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
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 untuk melakukan failover mungkin merupakan respons yang sesuai. Kesesuaian 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 mempertaruhkan 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 bencana, topik 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 penerapan sinkron, termasuk replika utama, dan pusat data jarak jauh yang menghosting dua replika sekunder penerapan 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 ketersediaannya untuk offline, dan database mereka menjadi tidak tersedia. Gambar berikut menggambarkan dampak kegagalan ini pada topologi grup ketersediaan.
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 saat 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 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 (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 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 kluster WSFC telah dipaksa, karena simpul offline memulai ulang, mereka dapat membentuk kuorum baru jika kondisi berikut keduanya ada: (a) tidak ada konektivitas jaringan antara salah satu node dalam set kuorum paksa, dan (b) simpul mulai 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 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 yang diterapkan secara sinkron. Perlu diingat bahwa pemotongan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Juga kesehatan sinkronisasi replika sekunder synchronous-commit tidak dapat bertransisi ke SEHAT selama database lokal tetap ditangguhkan. |
| 2. | Setelah database dilanjutkan, DBA mengubah replika utama baru ke 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 penerapan sinkron 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 SEHAT, 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 (T-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:
Melakukan Failover Manual Terencana dari Grup Ketersediaan (SQL Server)
Menggunakan Wizard Grup Ketersediaan Fail Over (SQL Server Management Studio)
Untuk memecahkan masalah:
Memecahkan Masalah Konfigurasi Grup Ketersediaan AlwaysOn (SQL Server)
Memecahkan Masalah Operasi Add-File yang Gagal (Grup Ketersediaan AlwaysOn)
Konten Terkait
Blogs:
Blog SQL Server Always On Team: Blog Resmi SQL Server Always On Team
Whitepapers:
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
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk