Mode Failover dan Failover (Grup Ketersediaan AlwaysOn)
Berlaku untuk:
SQL Server
Dalam konteks grup ketersediaan, peran utama dan peran sekunder dari 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. Grup ketersediaan gagal di tingkat ketersediaan-replika. Artinya, grup ketersediaan gagal ke salah satu replika sekundernya ( target failover saat ini).
Catatan
Kecuali Deteksi Kesehatan Tingkat Database dikonfigurasi, masalah di tingkat database, seperti database menjadi tersangka karena hilangnya file data, penghapusan database, atau kerusakan log transaksi, tidak menyebabkan grup ketersediaan gagal.
Selama failover, target failover mengambil alih peran utama, memulihkan databasenya, dan membuatnya online sebagai database utama baru. Replika utama sebelumnya, jika tersedia, beralih ke peran sekunder, dan databasenya menjadi database sekunder. Berpotensi, peran ini dapat beralih bolak-balik (atau ke target failover yang berbeda) sebagai respons terhadap beberapa kegagalan atau untuk tujuan administratif.
Formulir failover yang didukung replika ketersediaan tertentu ditentukan oleh properti mode failover . Untuk replika ketersediaan tertentu, mode failover yang mungkin bergantung pada mode ketersediaan replika, sebagai berikut:
Replika penerapan sinkron mendukung dua pengaturan otomatis atau manual. Pengaturan "otomatis" mendukung failover otomatis dan failover manual. Untuk mencegah kehilangan data, failover otomatis dan failover yang direncanakan mengharuskan target failover menjadi replika sekunder penerapan sinkron dengan status sinkronisasi yang sehat (ini menunjukkan bahwa setiap database sekunder pada target failover disinkronkan dengan database utama yang sesuai). Setiap kali replika sekunder tidak memenuhi kedua kondisi ini, replika tersebut hanya mendukung failover paksa. Perhatikan bahwa failover paksa juga didukung replika yang perannya dalam status PENYELESAIAN.
Replika penerapan asinkron hanya mendukung mode failover manual. Selain itu, karena tidak pernah disinkronkan, mereka hanya mendukung failover paksa.
Catatan
Setelah failover, aplikasi klien yang perlu mengakses database utama harus terhubung ke replika utama baru. Selain itu, jika replika sekunder baru dikonfigurasi untuk memungkinkan akses baca-saja, aplikasi klien baca-saja dapat terhubung ke replika tersebut. Untuk informasi tentang cara klien terhubung ke grup ketersediaan, lihat Pendengar Grup Ketersediaan, Konektivitas Klien, dan Failover Aplikasi (SQL Server).
Bagian dalam Topik Ini:
Syarat dan Definisi
Failover otomatis
Failover yang terjadi secara otomatis pada hilangnya replika utama. Failover otomatis hanya didukung ketika replika primer dan satu sekunder saat ini dikonfigurasi dengan mode failover diatur ke OTOMATIS dan replika sekunder yang saat ini disinkronkan. Jika mode failover dari replika utama atau sekunder adalah MANUAL, failover otomatis tidak dapat terjadi.
Failover manual yang direncanakan (tanpa kehilangan data)
Failover manual yang direncanakan, atau failover manual, adalah failover yang dimulai oleh administrator database, biasanya, untuk tujuan administratif. Failover manual yang direncanakan hanya didukung jika replika utama dan replika sekunder dikonfigurasi untuk mode penerapan sinkron, dan replika utama dan replika sekunder saat ini disinkronkan (dalam status DISINKRONKAN). Ketika replika sekunder target disinkronkan, failover manual (tanpa kehilangan data) dimungkinkan bahkan jika replika utama mengalami crash karena database sekunder siap untuk failover. Administrator database secara manual memulai failover manual.
Failover paksa (dengan kemungkinan kehilangan data)
Failover yang dapat dimulai oleh administrator database ketika tidak ada replika sekunder yang DISINKRONKAN dengan replika utama atau replika utama tidak berjalan dan tidak ada replika sekunder yang siap untuk failover. Failover paksa berisiko kemungkinan kehilangan data dan disarankan secara ketat untuk pemulihan bencana. Failover paksa juga dikenal sebagai failover manual paksa karena hanya dapat dimulai secara manual. Ini adalah satu-satunya bentuk failover yang didukung oleh dalam mode ketersediaan penerapan asinkron.
Set failover otomatis
Dalam grup ketersediaan tertentu, sepasang replika ketersediaan (termasuk replika utama saat ini) yang dikonfigurasi untuk mode penerapan sinkron dengan failover otomatis, jika ada. Failover otomatis menetapkan efek hanya jika replika sekunder saat ini DISINKRONKAN dengan replika utama.
Set failover penerapan sinkron
Dalam grup ketersediaan tertentu, satu set dua atau tiga replika ketersediaan (termasuk replika utama saat ini) yang dikonfigurasi untuk mode penerapan sinkron, jika ada. Efek failover penerapan sinkron hanya jika replika sekunder dikonfigurasi untuk mode failover manual dan setidaknya satu replika sekunder saat ini DISINKRONKAN dengan replika utama.
Seluruh set failover
Dalam grup ketersediaan tertentu, kumpulan semua replika ketersediaan yang status operasionalnya saat ini ONLINE, terlepas dari mode ketersediaan dan mode failover. Seluruh set failover relevan ketika tidak ada replika sekunder yang saat ini DISINKRONKAN dengan replika utama.
Gambaran Umum Failover
Tabel berikut ini meringkas bentuk failover mana yang didukung di bawah mode ketersediaan dan failover yang berbeda. Untuk setiap pemasangan, mode ketersediaan efektif dan mode failover ditentukan oleh persimpangan mode replika utama ditambah mode satu atau beberapa replika sekunder.
| Formulir failover | Mode penerapan asinkron | Mode penerapan sinkron dengan mode failover manual | Mode penerapan sinkron dengan mode failover otomatis |
|---|---|---|---|
| Failover otomatis | Tidak | Tidak | Ya |
| Failover manual yang direncanakan | Tidak | Ya | Ya |
| Failover paksa | Ya | Ya | Ya***** |
Jika Anda mengeluarkan perintah failover paksa pada replika sekunder yang disinkronkan, replika sekunder berprilaku sama seperti untuk failover manual.
Jumlah waktu database tidak tersedia selama failover tergantung pada jenis failover dan penyebabnya.
Penting
Untuk mendukung koneksi klien setelah failover, kecuali untuk database mandiri, login, dan pekerjaan yang ditentukan pada salah satu database utama sebelumnya harus dibuat ulang secara manual pada database utama baru. Untuk informasi selengkapnya, lihat Manajemen Login dan Pekerjaan untuk Database Grup Ketersediaan (SQL Server).
Set Failover
Bentuk failover yang dimungkinkan untuk grup ketersediaan tertentu dapat dipahami dalam hal set failover. Set failover terdiri dari replika utama dan replika sekunder yang mendukung bentuk failover tertentu, sebagai berikut:
Set failover otomatis (opsional): Dalam grup ketersediaan tertentu, sepasang replika ketersediaan (termasuk replika utama saat ini) yang dikonfigurasi untuk mode penerapan sinkron dengan failover otomatis, jika ada. Set failover otomatis hanya berlaku jika replika sekunder saat ini DISINKRONKAN dengan replika utama.
Set failover penerapan sinkron (opsional): Dalam grup ketersediaan tertentu, satu set dua atau tiga replika ketersediaan (termasuk replika utama saat ini) yang dikonfigurasi untuk mode penerapan sinkron, jika ada. Set failover penerapan sinkron hanya berlaku jika replika sekunder dikonfigurasi untuk mode failover manual dan setidaknya satu replika sekunder saat ini DISINKRONKAN dengan replika utama.
Seluruh set failover : Dalam grup ketersediaan tertentu, kumpulan semua replika ketersediaan yang status operasionalnya saat ini ONLINE, terlepas dari mode ketersediaan dan mode failover. Seluruh set failover menjadi relevan ketika tidak ada replika sekunder yang saat ini DISINKRONKAN dengan replika utama.
Saat Anda mengonfigurasi replika ketersediaan sebagai penerapan sinkron dengan failover otomatis, replika ketersediaan menjadi bagian dari set failover otomatis. Namun apakah set berlaku tergantung pada primer saat ini. Bentuk failover yang sebenarnya dimungkinkan pada waktu tertentu tergantung pada set failover apa yang saat ini berlaku.
Misalnya, pertimbangkan grup ketersediaan yang memiliki empat replika ketersediaan, sebagai berikut:
| Replika | Pengaturan Mode Ketersediaan dan Mode Failover |
|---|---|
| A | Penerapan sinkron dengan failover otomatis |
| B | Penerapan sinkron dengan failover otomatis |
| C | Penerapan sinkron dengan failover manual yang direncanakan saja |
| D | Penerapan asinkron (dengan hanya failover paksa) |
Perilaku failover untuk setiap replika sekunder tergantung pada replika ketersediaan mana yang saat ini menjadi replika utama. Pada dasarnya, untuk replika sekunder tertentu, perilaku failover adalah kasus terburuk mengingat replika utama saat ini. Gambar berikut menggambarkan bagaimana perilaku failover replika sekunder bervariasi tergantung pada replika utama saat ini, dan apakah itu dikonfigurasi untuk mode penerapan asinkron (hanya dengan failover paksa) atau mode penerapan sinkron (dengan atau tanpa failover otomatis).
Failover Otomatis
Failover otomatis menyebabkan replika sekunder yang memenuhi syarat secara otomatis beralih ke peran utama setelah replika utama menjadi tidak tersedia. Failover otomatis paling cocok ketika node WSFC yang menghosting replika utama bersifat lokal untuk node yang menghosting replika sekunder. Ini karena sinkronisasi data berfungsi paling baik dengan latensi pesan rendah antara komputer dan karena koneksi klien dapat tetap lokal.
Di bagian ini:
Kondisi yang Diperlukan untuk Failover Otomatis
Failover otomatis hanya terjadi dalam kondisi berikut:
Ada set failover otomatis. Set ini terdiri dari replika utama dan replika sekunder ( target failover otomatis) yang keduanya dikonfigurasi untuk mode penerapan sinkron dan diatur ke failover OTOMATIS. Jika replika utama diatur ke failover MANUAL, failover otomatis tidak dapat terjadi, bahkan jika replika sekunder diatur ke failover OTOMATIS.
Untuk informasi selengkapnya, lihat Mode Ketersediaan (Grup Ketersediaan AlwaysOn).
Target failover otomatis memiliki status sinkronisasi yang sehat (ini menunjukkan bahwa setiap database sekunder pada target failover disinkronkan dengan database utama yang sesuai).
Tip
Grup Ketersediaan AlwaysOn memantau kesehatan kedua replika dalam set failover otomatis. Jika salah satu replika gagal, status kesehatan grup ketersediaan diatur ke CRITICAL. Jika replika sekunder gagal, failover otomatis tidak dimungkinkan karena target failover otomatis tidak tersedia. Jika replika utama gagal, grup ketersediaan akan gagal ke replika sekunder. Sampai replika utama sebelumnya online, tidak ada target failover otomatis. Dalam kedua kasus, untuk memastikan ketersediaan dalam kasus kegagalan berurutan yang tidak mungkin terjadi, kami sarankan Anda mengonfigurasi replika sekunder yang berbeda sebagai target failover otomatis.
Untuk informasi selengkapnya, lihat Menggunakan Kebijakan AlwaysOn untuk Melihat Kesehatan Grup Ketersediaan (SQL Server) dan Mengubah Mode Failover Replika Ketersediaan (SQL Server).
Kluster Pengklusteran Failover Windows Server (WSFC) memiliki kuorum. Untuk informasi selengkapnya, lihat Mode Kuorum WSFC dan Konfigurasi Pemungutan Suara (SQL Server).
Replika utama menjadi tidak tersedia, dan tingkat kondisi failover yang ditentukan oleh Anda adalah kebijakan failover yang fleksibel telah terpenuhi. Untuk informasi tentang tingkat kondisi failover, lihat Kebijakan Failover Fleksibel untuk Failover Otomatis Grup Ketersediaan (SQL Server).
Cara Kerja Failover Otomatis
Failover otomatis memulai urutan tindakan berikut:
Jika instans server yang menghosting replika utama saat ini masih berjalan, instans server mengubah status database utama menjadi TERPUTUS dan memutuskan sambungan semua klien.
Jika ada rekaman log yang menunggu dalam antrean pemulihan pada replika sekunder target, replika sekunder menerapkan catatan log yang tersisa untuk menyelesaikan rolling forward database sekunder.
Catatan
Jumlah waktu yang diperlukan untuk menerapkan log ke database tertentu tergantung pada kecepatan sistem, beban kerja terbaru, dan jumlah log dalam antrean pemulihan.
Replika sekunder sebelumnya beralih ke peran utama. Databasenya menjadi database utama. Replika utama baru mengembalikan transaksi yang tidak dilakukan (fase pembatalan pemulihan) secepat mungkin. Kunci mengisolasi transaksi yang tidak dilakukan ini, memungkinkan gulung balik terjadi di latar belakang saat klien menggunakan database. Proses ini tidak mengembalikan transaksi yang diterapkan.
Hingga database sekunder tertentu tersambung, database tersebut ditandai secara singkat sebagai NOT_SYNCHRONIZED. Sebelum pemulihan putar kembali dimulai, database sekunder dapat tersambung ke database utama baru dan dengan cepat beralih ke status DISINKRONKAN. Kasus terbaik biasanya untuk replika penerapan sinkron ketiga yang tetap berada dalam peran sekunder setelah failover.
Kemudian, ketika instans server yang menghosting replika utama sebelumnya dimulai ulang, ia mengenali bahwa replika ketersediaan lain sekarang memiliki peran utama. Replika utama sebelumnya beralih ke peran sekunder, dan databasenya menjadi database sekunder. Replika sekunder baru terhubung ke replika utama saat ini dan menangkap databasenya hingga database utama saat ini secepat mungkin. Segera setelah replika sekunder baru telah menyinkronkan ulang databasenya, failover kembali dimungkinkan, ke arah terbalik.
Untuk mengonfigurasi Failover Otomatis
Replika ketersediaan dapat dikonfigurasi untuk mendukung failover otomatis kapan saja.
Untuk mengonfigurasi failover otomatis
Pastikan bahwa replika sekunder dikonfigurasi untuk menggunakan mode ketersediaan penerapan sinkron. Untuk informasi selengkapnya, lihat Mengubah Mode Ketersediaan Replika Ketersediaan (SQL Server).
Atur mode failover ke otomatis. Untuk informasi selengkapnya, lihat Mengubah Mode Failover Replika Ketersediaan (SQL Server).
Secara opsional, ubah kebijakan failover fleksibel dari grup ketersediaan untuk menentukan jenis kegagalan yang dapat menyebabkan kegagalan otomatis terjadi. Untuk informasi selengkapnya, lihat Mengonfigurasi Kebijakan Failover Fleksibel untuk Mengontrol Kondisi untuk Failover Otomatis (Grup Ketersediaan AlwaysOn) dan Kebijakan Failover untuk Instans Kluster Failover.
Failover manual yang direncanakan (Tanpa Kehilangan Data)
Failover manual menyebabkan replika sekunder yang disinkronkan beralih ke peran utama setelah administrator database mengeluarkan perintah failover manual pada instans server yang menghosting replika sekunder target. Untuk mendukung failover manual, replika sekunder dan replika utama saat ini harus dikonfigurasi untuk mode penerapan sinkron, jika ada. Setiap database sekunder pada replika ketersediaan harus digabungkan ke grup ketersediaan dan disinkronkan dengan database utama yang sesuai (yaitu, replika sekunder harus disinkronkan). Ini menjamin bahwa setiap transaksi yang dilakukan pada database utama sebelumnya juga telah dilakukan pada database utama baru. Oleh karena itu, database utama baru identik dengan database utama lama.
Gambar berikut mengilustrasikan tahapan failover yang direncanakan:
Sebelum failover, replika utama dihosting oleh instans server di
Node01.Administrator database memulai failover yang direncanakan. Target failover adalah replika ketersediaan yang dihosting oleh instans server di
Node02.Target failover (on
Node02) menjadi replika utama baru. Karena ini adalah failover yang direncanakan, replika utama sebelumnya beralih ke peran sekunder selama failover dan segera menjadikan databasenya online sebagai database sekunder.
Di bagian ini:
Kondisi yang Diperlukan untuk Failover Manual
Untuk mendukung failover manual, replika utama saat ini harus diatur ke mode synchronous-commit dan replika sekunder harus:
Dikonfigurasi untuk mode penerapan sinkron.
Saat ini disinkronkan dengan replika utama.
Untuk mengalihkan grup ketersediaan secara manual, Anda harus terhubung ke replika sekunder yang akan menjadi replika utama baru.
Cara Kerja Failover Manual terencana
Failover manual yang direncanakan, yang harus dimulai pada replika sekunder target, memulai urutan tindakan berikut:
Untuk memastikan bahwa tidak ada transaksi pengguna baru yang terjadi pada database utama asli, kluster WSFC mengirimkan permintaan ke replika utama untuk offline.
Jika ada log yang menunggu dalam antrean pemulihan database sekunder apa pun, replika sekunder selesai bergulir ke depan database sekunder tersebut. Jumlah waktu yang diperlukan tergantung pada kecepatan sistem, beban kerja terbaru, dan jumlah log dalam antrean pemulihan. Untuk mempelajari ukuran antrean pemulihan saat ini, gunakan penghitung kinerja Antrean Pemulihan . Untuk informasi selengkapnya, lihat SQL Server, Replika Database.
Catatan
Waktu failover dapat diatur dengan membatasi ukuran antrean pemulihan. Namun, ini dapat menyebabkan replika utama melambat untuk memungkinkan replika sekunder mengikuti.
Replika sekunder menjadi replika utama baru, dan replika utama sebelumnya menjadi replika sekunder baru.
Replika utama baru mengembalikan transaksi yang tidak diterapkan dan menjadikan databasenya online sebagai database utama. Semua database sekunder ditandai secara singkat sebagai TIDAK DISINKRONKAN sampai mereka menyambungkan dan menyinkronkan ulang ke database utama baru. Proses ini tidak mengembalikan transaksi yang diterapkan.
Ketika replika utama sebelumnya kembali online, dibutuhkan peran sekunder, dan database utama sebelumnya menjadi database sekunder. Replika sekunder baru dengan cepat menyinkronkan ulang database sekunder baru dengan database utama yang sesuai.
Catatan
Segera setelah replika sekunder baru telah menyinkronkan ulang database, failover kembali dimungkinkan, tetapi ke arah sebaliknya.
Setelah failover, klien harus terhubung kembali ke database utama saat ini. Untuk informasi selengkapnya, lihat Listener Grup Ketersediaan, Konektivitas Klien, dan Failover Aplikasi (SQL Server).
Mempertahankan Ketersediaan Selama Peningkatan
Administrator database untuk grup ketersediaan Anda dapat menggunakan failover manual untuk mempertahankan ketersediaan database saat Anda meningkatkan perangkat keras atau perangkat lunak. Untuk menggunakan grup ketersediaan untuk peningkatan perangkat lunak, instans server dan/atau simpul komputer yang menghosting replika sekunder target harus sudah menerima peningkatan. Untuk informasi selengkapnya, lihat Meningkatkan Instans Replika Grup Ketersediaan AlwaysOn.
Failover Paksa (dengan Kemungkinan Kehilangan Data)
Memaksa failover grup ketersediaan (dengan kemungkinan kehilangan data) adalah metode pemulihan bencana yang memungkinkan Anda menggunakan replika sekunder sebagai server siaga hangat. Karena memaksa kegagalan berisiko kemungkinan kehilangan data, itu harus digunakan dengan hati-hati dan hemat. Sebaiknya paksa failover hanya jika Anda harus segera memulihkan layanan ke database ketersediaan Anda dan bersedia mengambil risiko kehilangan data. Untuk informasi selengkapnya tentang prasyarat dan rekomendasi untuk memaksa failover dan untuk skenario contoh yang menggunakan failover paksa untuk pulih dari kegagalan bencana, lihat Melakukan Failover Manual Paksa dari Grup Ketersediaan (SQL Server).
Peringatan
Memaksa failover mengharuskan kluster WSFC memiliki kuorum. Untuk informasi tentang mengonfigurasi kuorum dan memaksa kuorum, lihat Pengklusteran Failover Windows Server (WSFC) dengan SQL Server.
Di bagian ini:
Cara Kerja Failover Paksa
Memaksa failover memulai transisi peran utama ke replika target yang perannya dalam status SEKUNDER atau PENYELESAIAN. Target failover menjadi replika utama baru dan segera melayani salinan databasenya kepada klien. Ketika replika utama sebelumnya tersedia, replika tersebut akan beralih ke peran sekunder dan databasenya akan menjadi database sekunder.
Semua database sekunder (termasuk database utama sebelumnya, ketika tersedia) diTANGGUHKAN. Bergantung pada status sinkronisasi data sebelumnya dari database sekunder yang ditangguhkan, mungkin cocok untuk menyelamatkan data berkomitmen yang hilang untuk database utama tersebut. Pada replika sekunder yang dikonfigurasi untuk akses baca-saja, Anda dapat mengkueri database sekunder untuk menemukan data yang hilang secara manual. Kemudian Anda dapat mengeluarkan pernyataan Transact-SQL pada database utama baru untuk membuat perubahan yang diperlukan.
Risiko Memaksa Failover
Penting untuk dipahami bahwa memaksa failover dapat menyebabkan kehilangan data. Kehilangan data dimungkinkan karena replika target tidak dapat berkomunikasi dengan replika utama dan, oleh karena itu, tidak dapat menjamin bahwa database disinkronkan. Memaksa failover memulai fork pemulihan baru. Karena database utama asli dan database sekunder berada di fork pemulihan yang berbeda, masing-masing sekarang berisi data yang tidak dimuat database lain: setiap database utama asli berisi perubahan apa pun yang belum dikirim dari antrean pengirimannya ke database sekunder sebelumnya (log yang tidak terkirim); database sekunder sebelumnya berisi perubahan apa pun yang terjadi setelah failover dipaksa.
Jika failover dipaksakan karena replika utama gagal, potensi kehilangan data tergantung pada apakah log transaksi telah dikirim ke replika sekunder atau tidak sebelum kegagalan. Di bawah mode penerapan asinkron, akumulasi log yang tidak dikirim selalu merupakan kemungkinan. Di bawah mode penerapan sinkron, ini hanya dimungkinkan sampai database sekunder disinkronkan.
Tabel berikut ini meringkas kemungkinan kehilangan data untuk database tertentu pada replika tempat Anda memaksa failover.
| Mode ketersediaan Replika Sekunder | Apakah database disinkronkan? | Apakah kehilangan data dimungkinkan? |
|---|---|---|
| Penerapan sinkron | Ya | Tidak |
| Penerapan sinkron | Tidak | Ya |
| Penerapan asinkron | Tidak | Ya |
Database sekunder hanya melacak dua fork pemulihan, jadi jika Anda melakukan beberapa failover paksa, database sekunder apa pun yang memulai sinkronisasi data dengan failover paksa sebelumnya mungkin tidak dapat dilanjutkan. Jika ini terjadi, database sekunder apa pun yang tidak dapat dilanjutkan perlu dihapus dari grup ketersediaan, dipulihkan ke titik waktu yang benar, dan bergabung kembali ke grup ketersediaan. Kesalahan 1408 dengan status 103 dapat diamati dalam skenario ini (Kesalahan: 1408, Tingkat Keparahan: 16, Status: 103). Pemulihan tidak akan berfungsi di beberapa fork pemulihan, oleh karena itu, pastikan untuk melakukan pencadangan log setelah melakukan lebih dari satu failover paksa.
Mengapa Failover Paksa Diperlukan Setelah Memaksa Kuorum
Setelah kuorum dipaksa pada kluster WSFC (kuorum paksa), Anda perlu melakukan failover paksa (dengan kemungkinan kehilangan data) pada setiap grup ketersediaan. Failover paksa diperlukan karena status nyata dari nilai kluster WSFC mungkin telah hilang. Mencegah failover normal setelah kuorum paksa diperlukan karena kemungkinan daripada replika sekunder yang tidak disinkronkan akan tampak disinkronkan pada kluster WSFC yang dikonfigurasi ulang.
Misalnya, pertimbangkan kluster WSFC yang menghosting grup ketersediaan pada tiga node: Node A menghosting replika utama dan Node B dan Node C masing-masing menghosting replika sekunder. Node C terputus dari kluster WSFC sementara replika sekunder lokal DISINKRONKAN. Tetapi Node A dan Node B mempertahankan kuorum yang sehat dan grup ketersediaan tetap online. Pada Node A, replika utama terus menerima pembaruan, dan pada Node B, replika sekunder terus disinkronkan dengan replika utama. Replika sekunder pada Node C menjadi tidak disinkronkan dan semakin berada di belakang replika utama. Namun, karena Node C terputus, replika tetap, salah, dalam status DISINKRONKAN.
Jika kuorum hilang dan kemudian dipaksa pada Node A, status sinkronisasi grup ketersediaan pada kluster WSFC harus benar-benar dengan replika sekunder pada Node C yang ditampilkan sebagai UNSYNCHRONIZED. Namun, jika kuorum dipaksa pada Node C, sinkronisasi grup ketersediaan akan salah. Status sinkronisasi pada kluster akan kembali ke ketika Node C terputus-dengan replika sekunder pada Node C salah ditampilkan sebagai SYNCHRONIZED. Karena failover manual yang direncanakan menjamin keamanan data, mereka tidak diizinkan untuk membawa grup ketersediaan kembali online setelah kuorum dipaksa.
Melacak Potensi Kehilangan Data
Ketika kluster WSFC memiliki kuorum yang sehat, Anda dapat memperkirakan potensi kehilangan data pada database saat ini. Untuk replika sekunder tertentu, potensi kehilangan data saat ini tergantung pada seberapa jauh database sekunder lokal tertinggal dari database utama yang sesuai. Karena jumlah jeda bervariasi dari waktu ke waktu, kami sarankan Anda secara berkala melacak potensi kehilangan data untuk database sekunder Anda yang tidak disinkronkan. Lag pelacakan melibatkan perbandingan Last Commit LSN dan Last Commit Time untuk setiap database utama dan database sekundernya, sebagai berikut:
Sambungkan ke replika utama.
Kueri kolom last_commit_lsn (LSN dari transaksi terakhir yang dilakukan) dan last_commit_time (waktu penerapan terakhir) dari tampilan manajemen dinamis sys.dm_hadr_database_replica_states .
Bandingkan nilai yang dikembalikan untuk setiap database utama dan masing-masing database sekundernya. Perbedaan antara LSN Penerapan Terakhir menunjukkan jumlah jeda.
Anda dapat memicu pemberitahuan ketika jumlah jeda pada database atau sekumpulan database melebihi jeda maksimum yang Anda inginkan untuk jangka waktu tertentu. Misalnya, kueri dapat dijalankan oleh pekerjaan yang dijalankan setiap menit pada setiap database utama. Jika perbedaan antara last_commit_time database utama dan salah satu database sekundernya telah melebihi tujuan titik pemulihan (RPO) (misalnya, 5 menit) sejak terakhir kali pekerjaan dijalankan, pekerjaan dapat memunculkan pemberitahuan.
Penting
Ketika kluster WSFC tidak memiliki kuorum atau kuorum yang dipaksakan, last_commit_lsn dan last_commit_time ADALAH NULL. Untuk informasi tentang bagaimana Anda mungkin dapat menghindari kehilangan data setelah Anda memaksa kuorum, lihat "Cara Potensial untuk Menghindari Kehilangan Data Setelah Kuorum Dipaksa" di Melakukan Failover Manual Paksa dari Grup Ketersediaan (SQL Server).
Mengelola Potensi Kehilangan Data
Setelah failover dipaksa, semua database sekunder ditangguhkan. Ini termasuk database utama sebelumnya, setelah replika utama sebelumnya kembali online dan menemukan bahwa itu sekarang menjadi replika sekunder. Anda harus melanjutkan setiap database yang ditangguhkan secara manual satu per satu pada setiap replika sekunder.
Setelah replika utama sebelumnya tersedia, dengan asumsi bahwa databasenya tidak dirusak, Anda dapat mencoba mengelola potensi kehilangan data. Pendekatan yang tersedia untuk mengelola potensi kehilangan data tergantung pada apakah replika utama asli telah terhubung ke replika utama baru. Dengan asumsi bahwa replika utama asli dapat mengakses instans utama baru, koneksi ulang terjadi secara otomatis dan transparan.
Replika utama asli telah tersambung kembali
Biasanya, setelah kegagalan, ketika replika utama asli dimulai ulang, replika utama tersebut dengan cepat terhubung kembali ke mitranya. Saat menyambungkan kembali, replika utama asli menjadi replika sekunder. Databasenya menjadi database sekunder dan memasuki status SUSPENDED. Database sekunder baru tidak akan digulung balik kecuali Anda melanjutkannya.
Namun, database yang ditangguhkan tidak dapat diakses, sehingga Anda tidak dapat memeriksanya untuk mengevaluasi data apa yang akan hilang jika Anda melanjutkan database tertentu. Oleh karena itu, keputusan tentang apakah akan melanjutkan atau menghapus database sekunder tergantung pada apakah Anda bersedia menerima kehilangan data apa pun, sebagai berikut:
Jika kehilangan data apa pun tidak akan dapat diterima, Anda harus menghapus database dari grup ketersediaan untuk menyelamatkannya.
Administrator database sekarang dapat memulihkan database utama sebelumnya dan mencoba memulihkan data yang akan hilang. Namun, ketika database utama sebelumnya online, database tersebut berbeda dari database utama saat ini, sehingga administrator database perlu membuat database yang dihapus atau database utama saat ini tidak dapat diakses oleh klien untuk menghindari divergensi database lebih lanjut dan untuk mencegah masalah kegagalan klien.
Jika kehilangan data akan dapat diterima oleh tujuan bisnis Anda, Anda dapat melanjutkan database sekunder.
Melanjutkan database sekunder baru menyebabkannya digulung balik sebagai langkah pertama dalam menyinkronkan database. Jika ada catatan log yang menunggu dalam antrean pengiriman pada saat kegagalan, transaksi yang sesuai akan hilang, bahkan jika dilakukan.
Replika utama asli belum tersambung kembali
Jika Anda dapat mencegah sementara replika utama asli terhubung kembali melalui jaringan ke replika utama baru, Anda dapat memeriksa database utama asli untuk mengevaluasi data apa yang akan hilang jika dilanjutkan.
Jika potensi kehilangan data dapat diterima
Izinkan replika utama asli terhubung kembali ke replika utama baru. Menyambungkan kembali menyebabkan database sekunder baru ditangguhkan. Untuk memulai sinkronisasi data pada database, cukup lanjutkan. Replika sekunder baru menghilangkan fork pemulihan asli untuk database tersebut, kehilangan transaksi apa pun yang tidak pernah dikirim atau diterima oleh replika sekunder sebelumnya.
Jika kehilangan data tidak dapat diterima
Jika database utama asli berisi data penting yang akan hilang jika Anda melanjutkan database yang ditangguhkan, Anda dapat mempertahankan data pada database utama asli dengan menghapusnya dari grup ketersediaan. Hal ini menyebabkan database memasuki status PEMULIHAN. Pada titik ini, kami sarankan Anda mencoba mencadangkan ekor log database yang dihapus. Kemudian, Anda dapat memperbarui database primer saat ini (database sekunder sebelumnya) dengan mengekspor data yang ingin Anda simpan dari database utama asli dan mengimpornya ke database utama saat ini. Sebaiknya ambil cadangan database lengkap dari database utama yang diperbarui secepat mungkin.
Kemudian, pada instans server yang menghosting replika sekunder baru, Anda dapat menghapus database sekunder yang ditangguhkan dan membuat database sekunder baru dengan memulihkan cadangan ini (dan setidaknya satu cadangan log berikutnya) menggunakan RESTORE WITH NORECOVERY. Sebaiknya tunda pencadangan log tambahan dari database utama saat ini hingga database sekunder yang sesuai dilanjutkan.
Peringatan
Pemotokan log transaksi tertunda pada database utama saat salah satu database sekundernya ditangguhkan. Juga kesehatan sinkronisasi replika sekunder synchronous-commit tidak dapat beralih ke SEHAT selama database lokal tetap ditangguhkan.
Tugas Terkait
Untuk mengonfigurasi perilaku failover
Untuk melakukan failover manual
Melakukan Failover Manual Terencana dari Grup Ketersediaan (SQL Server)
Melakukan Failover Manual Paksa dari Grup Ketersediaan (SQL Server)
Gunakan Wizard Grup Ketersediaan Fail Over (SQL Server Management Studio)
Manajemen Login dan Pekerjaan untuk Database Grup Ketersediaan (SQL Server)
Untuk mengonfigurasi Konfigurasi Kuorum WSFC
Konten terkait
Panduan Solusi Microsoft SQL Server Always On untuk Ketersediaan Tinggi dan Pemulihan Bencana
SQL Server Blog Always On Team: Blog resmi SQL Server Always On Team
Lihat juga
Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Mode Ketersediaan (Grup Ketersediaan AlwaysOn)
Pengklusteran Failover Windows Server (WSFC) dengan SQL Server
Transaksi Lintas Database dan Transaksi Terdistribusi untuk Grup Ketersediaan AlwaysOn dan Pencerminan Database (SQL Server)
Kebijakan Failover untuk Instans Kluster Failover
Kebijakan Failover Fleksibel untuk Failover Otomatis Grup Ketersediaan (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