Bagikan melalui

Pengalihan Peran Selama Sesi Pencerminan Database (SQL Server)

Dalam konteks sesi pencerminan database, peran utama dan cermin biasanya dapat dipertukarkan dalam proses yang dikenal sebagai pengalihan peran. Dalam pengalihan peran, server cermin bertindak sebagai mitra failover untuk server utama, mengambil alih peran utama, memulihkan salinan databasenya dan membuatnya online sebagai database utama baru. Server utama sebelumnya, jika tersedia, mengasumsikan peran cermin, dan databasenya menjadi database cermin baru. Peran dapat berpotensi beralih bolak-balik baik sebagai respons terhadap berbagai kegagalan atau untuk tujuan administratif.

Nota

Topik ini mengasumsikan bahwa Anda sudah familiar dengan mode operasi pencerminan basis data. Untuk informasi selengkapnya, lihat Modus Operasi Pencerminan Database.

Ilustrasi berikut menunjukkan mitra pencerminan, Partner_A dan Partner_B, bertukar peran sebagai utama dan cermin selama serangkaian failover otomatis atau manual.

Mitra bergantian peran dua kali

Penting

Setelah pengalihan peran, pekerjaan yang berjalan pada database utama sebelumnya harus dibuat ulang di server utama baru untuk dijalankan di sana. Untuk informasi selengkapnya, lihat Manajemen Login dan Pekerjaan Setelah Pengalihan Peran (SQL Server).

Ada tiga jenis peralihan peran: failover otomatis, failover manual, dan layanan paksa (dengan kemungkinan kehilangan data). Dukungan untuk setiap formulir tergantung pada mode operasi sesi.

Nota

Jika Anda tidak terbiasa dengan mode operasi ini, lihat Mode Operasi Pencerminan Database.

  • Manual gagal beralih

    Mode keamanan tinggi mendukung failover manual. Setiap kali database disinkronkan, pemilik database dapat memulai failover manual.

    Failover manual disediakan untuk tujuan administratif. Untuk informasi selengkapnya, lihat Failover Manual, pada bagian selanjutnya dari topik ini.

  • Failover otomatis

    Di hadapan saksi, mode keselamatan tinggi mendukung failover otomatis. Failover otomatis hanya terjadi ketika server utama mengalami kerusakan sementara server saksi dan cermin masih saling terhubung dan database sudah tersinkronisasi. Untuk informasi selengkapnya, lihat Failover Otomatis, nanti dalam topik ini.

  • Layanan paksa (dengan kemungkinan kehilangan data)

    Layanan paksa didukung dalam mode keamanan tinggi ketika tidak ada saksi yang ditetapkan dan dalam mode kinerja tinggi. Pada hilangnya server utama, pemilik database dapat membuat database tersedia dengan memaksa layanan ke server cermin (dengan kemungkinan kehilangan data).

    Nota

    Sebaiknya properti WITNESS diatur ke NONAKTIF dalam mode performa tinggi. Sebaliknya, untuk membuat database online, server cermin harus dihubungkan ke saksi.

    Untuk informasi selengkapnya, lihat Layanan Paksa (dengan Kemungkinan Kehilangan Data), nanti dalam topik ini.

Tabel berikut ini meringkas bentuk failover mana yang didukung di bawah setiap mode operasi.

Performa tinggi Mode keamanan tinggi tanpa saksi Mode keselamatan tinggi dengan saksi
Failover otomatis Tidak. Tidak. Ya
Peralihan manual Tidak. Ya Ya
Layanan paksa Ya Ya Tidak.

Setelah pengalihan peran, metadata tertentu harus ada di kedua mitra untuk memastikan bahwa semua pengguna database dapat mengakses database utama baru. Selain itu, tugas pencadangan harus dibuat di server utama baru, untuk memastikan bahwa database terus dicadangkan sesuai jadwal reguler. Untuk informasi selengkapnya, lihat Manajemen Login dan Pekerjaan Setelah Pengalihan Peran (SQL Server).

Selama pengalihan peran, jumlah waktu pencerminan database akan kehabisan layanan tergantung pada jenis pengalihan peran dan penyebabnya. Untuk informasi selengkapnya, lihat Memperkirakan Gangguan Layanan Selama Pengalihan Peran (Pencerminan Database).

Alih Fungsi Manual

Failover manual memutus klien dari database dan membalikkan peran para mitra. Hanya mode keamanan tinggi yang mendukung failover manual.

Mempertahankan Ketersediaan Selama Peningkatan

Administrator database dapat menggunakan failover manual untuk meningkatkan perangkat keras atau perangkat lunak tanpa mengorbankan ketersediaan. Untuk menggunakan mirroring basis data untuk pembaruan perangkat lunak, server mirror dan/atau sistem harus telah menerima pembaruan.

Nota

Pencerminan database harus dapat melakukan peningkatan bergulir, tetapi ini tidak dijamin, karena perubahan di masa mendatang tidak diketahui. Untuk informasi selengkapnya, lihat Meminimalkan Waktu Henti untuk Database Cermin Saat Meningkatkan Instans Server.

Gambar berikut mengilustrasikan instans penggunaan failover manual untuk mempertahankan ketersediaan database saat Anda meningkatkan instans server database. Ketika peningkatan selesai, administrator dapat secara opsional melakukan failover kembali ke instans server asli. Ini berguna ketika administrator ingin menghentikan sesi pencerminan dan menggunakan server cermin di tempat lain. Dengan cara ini, satu instans server dapat digunakan berulang kali saat memperbarui serangkaian instans server database.

Failover manual terencana

Kondisi yang Diperlukan untuk Failover Manual

Failover manual memerlukan keamanan transaksi diatur ke tingkat penuh (artinya, mode keamanan tinggi). Ketika mitra terhubung dan basis data sudah tersinkronisasi, pengalihan manual didukung.

Cara Kerja Failover Manual

Failover manual memulai urutan tindakan berikut:

  1. Server utama memutuskan koneksi klien dari database utama, mengirim bagian akhir log ke server cermin, dan sebagai persiapan untuk beralih ke peran cermin, mengatur status pencerminan ke SYNCHRONIZING.

  2. Server mirror mencatat nomor urutan log (LSN) dari catatan log terakhir yang diterima dari prinsipal sebagai LSN failover.

    Nota

    Untuk melihat LSN ini, pilih kolom mirroring_failover_lsn dari sys.database_mirroring (Transact-SQL).

  3. Jika ada log yang menunggu dalam antrean pengulangan, server cermin menyelesaikan memajukan database cermin. Durasi yang diperlukan tergantung pada kecepatan sistem, beban kerja terbaru, dan jumlah log yang ada dalam antrean redo. Untuk mode operasi sinkron, waktu failover dapat diatur dengan cara membatasi ukuran antrean redo. Namun, ini dapat menyebabkan server utama melambat untuk memungkinkan server cermin mengikuti.

    Nota

    Untuk mempelajari ukuran antrean pengulangan saat ini, gunakan penghitung kinerja Ulangi Antrean di objek performa pencerminan database (untuk informasi selengkapnya, lihat Memantau Pencerminan Database (SQL Server)).

  4. Server cermin menjadi server utama baru, dan server utama sebelumnya menjadi server cermin baru.

  5. Server utama yang baru mengembalikan transaksi yang belum dikommit dan membawa salinan databasenya dalam keadaan online sebagai database utama.

  6. Mantan prinsipal mengambil peran cermin, dan database utama sebelumnya menjadi database cermin. Server cermin baru dengan cepat menyinkronkan ulang database cermin baru dengan database utama baru.

    Nota

    Segera setelah server cermin baru telah menyinkronkan ulang database, failover kembali dimungkinkan, tetapi ke arah terbalik.

Setelah failover, klien harus terhubung kembali ke database utama saat ini. Untuk informasi selengkapnya, lihat Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server).

Untuk memulai failover manual

Failover Otomatis

Failover otomatis hanya didukung dalam sesi pencerminan database yang berjalan dengan saksi dalam mode keamanan tinggi (mode keamanan tinggi dengan failover otomatis). Dalam mode keamanan tinggi dengan failover otomatis, setelah database disinkronkan, jika database utama tidak dapat diakses, failover otomatis terjadi. Failover otomatis menyebabkan server cermin mengambil alih peran server utama dan membawa salinan databasenya secara online sebagai database utama. Mengharuskan database disinkronkan mencegah kehilangan data selama failover, karena setiap transaksi yang dilakukan pada database utama juga dilakukan pada database cermin.

Penting

Agar failover otomatis meningkatkan keandalan, cermin dan database utama harus berada di komputer yang berbeda.

Kondisi yang Diperlukan untuk Failover Otomatis

Failover otomatis memerlukan kondisi berikut:

  • Sesi pencerminan database harus berjalan dalam mode keamanan tinggi dan harus memiliki saksi. Untuk informasi selengkapnya, lihat Modus Operasi Pencerminan Database.

  • Database cermin harus sudah disinkronkan. Ini menjamin bahwa semua log yang dikirim ke server cermin telah ditulis ke disk.

  • Server utama kehilangan komunikasi dengan sisa konfigurasi pencerminan database, sementara server cermin dan saksi tetap mempertahankan kuorum. Namun, jika semua instans server kehilangan komunikasi, dan saksi dan server cermin kemudian mendapatkan kembali komunikasi, failover otomatis tidak terjadi.

    Nota

    Untuk informasi selengkapnya, lihat Kuorum: Bagaimana Bukti Memengaruhi Ketersediaan Database (Pencerminan Database).

  • Server cermin telah mendeteksi hilangnya server utama.

    Bagaimana server cermin mendeteksi kegagalan server utama tergantung pada apakah itu kegagalan keras atau lunak. Untuk informasi selengkapnya, lihat Kemungkinan Kegagalan Selama Pencerminan Database.

Cara Kerja Failover Otomatis

Dalam kondisi sebelumnya, failover otomatis memulai urutan tindakan berikut:

  1. Jika server utama masih berjalan, server tersebut mengubah status database utama menjadi TERPUTUS dan memutuskan semua klien dari database utama.

  2. Server saksi dan cermin mendaftarkan bahwa server utama tidak tersedia.

  3. Jika ada log yang menunggu dalam antrian ulang, server cermin menyelesaikan pemajuan database cermin.

    Nota

    Jumlah waktu yang diperlukan untuk menerapkan log tergantung pada kecepatan sistem, beban kerja terbaru, dan jumlah log dalam antrean pengulangan.

  4. Database mirror sebelumnya beralih online sebagai database utama baru, dan pemulihan membersihkan semua transaksi yang belum selesai dengan menggulungnya kembali secepat mungkin. Kunci mengisolasi transaksi tersebut.

  5. Ketika server utama sebelumnya bergabung kembali dengan sesi, ia mengakui bahwa mitra failover-nya sekarang memiliki peran utama. Server utama sebelumnya mengambil peran cermin, menjadikan databasenya sebagai database cermin. Server cermin baru menyinkronkan database cermin baru dengan database utama secepat mungkin. Segera setelah server cermin baru selesai menyinkronkan ulang database, failover kembali dimungkinkan, tetapi dalam arah sebaliknya.

Ilustrasi berikut menunjukkan satu contoh failover yang dilakukan secara otomatis.

Failover otomatis

Awalnya, ketiga server terhubung (sesi memiliki kuorum penuh). Partner_A adalah server utama dan Partner_B adalah server cermin. Partner_A (atau database utama di Partner_A) menjadi tidak tersedia. Saksi dan Partner_B sama-sama mengakui bahwa meskipun prinsipal tidak lagi tersedia, sesi tetap dapat mempertahankan kuorum. Partner_B menjadi server utama dan membuat salinan databasenya tersedia sebagai database utama baru. Akhirnya, Partner_A terhubung kembali ke sesi dan menemukan bahwa Partner_B sekarang memiliki peran utama. Partner_A kemudian mengambil peran cermin.

Setelah failover, klien harus terhubung kembali ke database utama saat ini. Untuk informasi selengkapnya, lihat Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server).

Nota

Transaksi yang telah disiapkan menggunakan Koordinator Transaksi Terdistribusi Microsoft tetapi masih tidak dilakukan ketika failover terjadi, dianggap dibatalkan setelah database gagal.

Untuk menonaktifkan Failover Otomatis (SQL Server Management Studio)

Buka halaman Properti DatabaseMirroring , dan ubah mode operasi dengan memilih salah satu opsi berikut:

  • Keamanan tinggi tanpa failover otomatis (sinkron)

    Dalam mode ini, database terus disinkronkan, dan failover manual tetap dimungkinkan.

  • Performa tinggi (asinkron)

    Dalam mode ini, database cermin mungkin tertinggal agak di belakang database utama, dan failover manual tidak lagi dimungkinkan.

Untuk Menonaktifkan Failover Otomatis (Menggunakan Transact-SQL)

Pada titik mana pun dalam sesi pencerminan database, pemilik database dapat menonaktifkan failover otomatis dengan menonaktifkan saksi.

Untuk mematikan saksi

Layanan Paksa (dengan Kemungkinan Kehilangan Data)

Pencerminan database menyediakan layanan memaksa (dengan kemungkinan kehilangan data) sebagai metode pemulihan bencana untuk memungkinkan Anda menggunakan server cermin sebagai server siaga hangat. Memaksa layanan hanya dimungkinkan jika server utama terputus dari server cermin dalam sesi pencerminan. Karena memaksakan layanan dapat menyebabkan kemungkinan kehilangan data, layanan harus digunakan dengan hati-hati dan secara hemat.

Dukungan untuk layanan paksa tergantung pada mode operasi dan status sesi, sebagai berikut:

  • Biasanya, mode berkinerja tinggi mendukung layanan pemaksaan setiap kali server utama terputus. Namun, meskipun tidak perlu, pengamat dapat ada untuk sesi mode berkinerja tinggi. Dalam hal ini, memaksakan layanan mengharuskan server cermin dan saksi terhubung satu sama lain.

  • Mode keamanan tinggi tanpa failover otomatis mendukung layanan pemaksaan setiap kali server utama terputus.

  • Mode keselamatan tinggi dengan failover otomatis mendukung pemaksaan layanan setiap kali server cermin dan saksi terhubung satu sama lain dan tidak terhubung ke server utama (selama server cermin tidak dalam proses memulihkan database cermin ketika terakhir kali terhubung ke server utama).

Sebaiknya paksa layanan hanya jika Anda harus segera memulihkan layanan ke database dan bersedia mengambil risiko kehilangan data. Efek memaksa layanan mirip dengan menghapus pencerminan, kecuali bahwa memaksa layanan memfasilitasi sinkronisasi ulang database saat pencerminan dilanjutkan, dengan risiko kemungkinan kehilangan data. Proses layanan ini memulai transisi yang lancar dari peran utama ke database cermin. Server cermin mengasumsikan peran server utama dan segera melayani salinan databasenya kepada klien. Database utama baru berjalan tanpa cermin (artinya, database tersebut berjalan terekspos).

Penting

Jika server utama hanya terputus dari sesi pencerminan database dan masih berjalan, beberapa klien mungkin terus mengakses database utama asli. Sebelum Anda memaksa layanan, penting untuk mencegah klien mengakses server utama asli. Sebaliknya, setelah layanan terpaksa dilakukan, database utama yang asli dan database utama saat ini dapat diperbarui secara independen satu sama lain.

Kasus Umum Layanan Paksa

Gambar berikut mengilustrasikan kasus umum layanan paksa (dengan kemungkinan kehilangan data).

Memaksa layanan dengan kemungkinan kehilangan data

Dalam gambar, server utama asli, Partner_A, menjadi tidak tersedia untuk server cermin, Partner_B, menyebabkan database cermin terputus. Setelah memastikan bahwa Partner_A tidak tersedia untuk klien, administrator database memaksa layanan, dengan kemungkinan kehilangan data, pada Partner_B. Partner_B menjadi server utama dan berjalan dengan database yang terbuka (yaitu, tidak dicerminkan). Pada titik ini, klien dapat terhubung kembali ke Partner_B.

Ketika Partner_A tersedia, ia terhubung kembali ke server utama yang baru, bergabung kembali dengan sesi, dan mengambil alih peran cermin. Sesi pencerminan segera ditangguhkan, tanpa menyinkronkan database cermin baru. Menangguhkan sesi memungkinkan administrator database untuk memutuskan apakah akan melanjutkan sesi atau, dalam kasus ekstrem, menghapus pencerminan dan mencoba menyelamatkan data dari database utama sebelumnya. Dalam hal ini, administrator basis data memilih untuk melanjutkan mirroring. Pada saat itu, Partner_A mengambil alih peran server cermin dan mengembalikan database principal sebelumnya ke titik waktu transaksi terakhir yang berhasil disinkronkan; jika ada transaksi yang telah dikomit tidak ditulis ke disk di server cermin sebelum layanan dipaksa berhenti, transaksi tersebut akan hilang. Partner_A kemudian meneruskan database cermin baru dengan menerapkan perubahan apa pun yang dibuat pada database utama baru karena server cermin sebelumnya menjadi server utama baru.

Nota

Meskipun mode berkinerja tinggi tidak memerlukan bukti, jika dikonfigurasi, layanan memaksa hanya dimungkinkan jika saksi saat ini terhubung ke server cermin.

Risiko Memaksa Layanan

Penting untuk dipahami bahwa memaksa layanan dapat menyebabkan kehilangan data. Kehilangan data dimungkinkan karena server cermin tidak dapat berkomunikasi dengan server utama dan, oleh karena itu, tidak dapat menjamin bahwa kedua database disinkronkan. Memaksa layanan memulai percabangan pemulihan baru. Karena database utama asli dan database cermin berada di cabang pemulihan yang berbeda, setiap database sekarang berisi data yang tidak dimiliki oleh database lainnya: database utama asli berisi segala perubahan yang belum dikirimkan dari antrean pengiriman ke database cermin sebelumnya (log tidak terkirim); dan database cermin sebelumnya berisi perubahan yang terjadi setelah layanan terpaksa dihentikan.

Jika layanan dipaksa karena server utama gagal, potensi kehilangan data tergantung pada apakah ada log transaksi yang tidak dikirim ke server cermin sebelum kegagalan. Dalam mode keamanan tinggi, ini hanya dimungkinkan sampai database cermin menjadi disinkronkan. Dalam mode berkinerja tinggi, akumulasi log yang tidak terkirim selalu merupakan kemungkinan.

Implikasi memaksa layanan sebagian bergantung pada apakah sesi memiliki saksi:

  • Dengan tidak adanya saksi, layanan dapat dipaksa untuk berfungsi jika mitra mengalami pemutusan, misalnya, karena koneksi jaringan bermasalah. Jika server utama asli masih berjalan, kedua mitra memiliki peran utama. Klien yang terhubung ke server utama baru akan mengakses versi database saat ini, sementara klien yang terhubung ke server utama asli akan mengakses database utama asli. Situasi ini meningkatkan potensi kehilangan data. Jika mitra diizinkan untuk terhubung kembali, server utama asli mengasumsikan peran cermin dan mengubah status databasenya menjadi "pulih," sebelum pencerminan ditangguhkan. Jika sesi dilanjutkan, transaksi pada database utama asli yang lognya berada dalam antrean kirim pada pemutusan sambungan terbaru akan hilang. Selain itu, transaksi yang terjadi setelah penghentian layanan secara paksa juga mengalami kehilangan.

  • Jika server cermin terputus dari server utama dan saksi, selama server utama dan saksi tetap terhubung satu sama lain, server utama berjalan dalam kondisi terekspos. Jika server utama kemudian terputus dari saksi, server tersebut berhenti melayani database. Setelah itu, jika server mirror terhubung kembali ke saksi, memungkinkan pemaksaan layanan menjadi dapat dilakukan. Jika layanan dipaksakan, semua perubahan yang dilakukan saat server utama asli berjalan terekspos akan hilang jika server utama asli tersambung kembali.

Untuk informasi selengkapnya, lihat Mengelola Potensi Kehilangan Data, nanti dalam topik ini.

Mengelola Potensi Kehilangan Data

Setelah layanan dipaksa, setelah server utama sebelumnya tersedia, dengan asumsi bahwa databasenya tidak rusak, Anda dapat mencoba mengelola potensi kehilangan data. Pendekatan yang tersedia untuk mengelola potensi kehilangan data tergantung pada apakah server utama asli telah terhubung kembali ke mitranya dan bergabung kembali dengan sesi pencerminan. Dengan asumsi bahwa server utama asli dapat mengakses instans utama baru, koneksi ulang terjadi secara otomatis dan transparan.

Server utama asli telah tersambung kembali

Biasanya, setelah kegagalan, server utama yang asli dengan cepat memulai ulang dan terhubung kembali ke mitranya. Saat menyambungkan kembali, server utama asli menjadi server cermin. Databasenya menjadi database cermin dan memasuki status pemulihan sebelum sesi ditangguhkan. Database cermin tidak akan digulung balik kecuali Anda melanjutkan pencerminan.

Namun, database yang dipulihkan tidak dapat diakses; oleh karena itu, Anda tidak dapat memeriksanya untuk mengevaluasi data apa yang akan hilang jika Anda melanjutkan pencerminan. Oleh karena itu, keputusan tentang apakah akan melanjutkan atau menghapus pencerminan tergantung pada apakah Anda bersedia menerima kehilangan data sama sekali.

  • Jika kehilangan data apa pun tidak dapat diterima, Anda harus menghapus pencerminan untuk menyelamatkan data tersebut.

    Menghapus pencerminan akan memungkinkan administrator database memulihkan database utama asli dan mencoba memulihkan data yang akan hilang. Namun, ketika basis data cermin sebelumnya online, mantan mitra akan menyediakan basis data yang berbeda dengan nama yang sama. Administrator database perlu membuat salah satu database tidak dapat diakses oleh klien untuk menghindari divergensi database lebih lanjut dan untuk mencegah masalah kegagalan klien.

  • Jika kehilangan data tertentu dapat diterima, Anda dapat melanjutkan proses pemulihan pencerminan.

    Meneruskan pencerminan menyebabkan database cermin baru 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.

Server utama asli belum tersambung kembali

Jika Anda dapat mencegah sementara server utama asli terhubung kembali melalui jaringan ke server utama baru, Anda dapat memeriksa database utama asli untuk mengevaluasi data apa yang akan hilang jika pencerminan dilanjutkan.

  • Jika potensi kehilangan data dapat diterima

    Izinkan server utama asli untuk terhubung kembali ke mitranya. Menyambungkan kembali menyebabkan pencerminan dihentikan sementara. Untuk melanjutkan proses pencerminan, cukup lanjutkan sesi. Server utama sebelumnya mengasumsikan peran cermin. Server cermin baru menghilangkan fork pemulihan asli, kehilangan transaksi apa pun yang tidak pernah dikirim atau diterima oleh server cermin sebelumnya.

  • Jika kehilangan data tidak dapat diterima

    Jika database utama asli berisi data penting yang akan hilang jika Anda melanjutkan sesi, Anda dapat mempertahankan data di server utama asli dengan menghapus pencerminan. Kami menyarankan agar Anda mencoba mencadangkan ekor log utama pada saat ini. Kemudian, Anda dapat memperbarui prinsipal saat ini (database cermin sebelumnya) dengan mengekspor data yang ingin Anda selamatkan dari database utama asli dan mengimpornya ke database utama saat ini. Sebaiknya ambil cadangan database lengkap dari database yang diperbarui secepat mungkin.

    Untuk membangun kembali pencerminan dengan database yang diperbarui sebagai database utama awal, gunakan cadangan ini (dan setidaknya satu cadangan log berikutnya) untuk membuat database cermin baru. Setiap pencadangan log yang diambil setelah pencerminan dihapus harus diterapkan. Oleh karena itu, sebaiknya tunda pencadangan log tambahan dari database utama hingga sesi pencerminan baru dimulai.

Tugas Terkait Untuk Mengelola Failover Paksa

Untuk memaksa layanan

Untuk melanjutkan replikasi database

Untuk membuat database cermin baru

Menyiapkan Database Cermin untuk Pencerminan (SQL Server)

Untuk memulai pencerminan database

Lihat Juga

Memperkirakan Gangguan Layanan Selama Pengalihan Peran (Pencerminan Database)
Kemungkinan Kegagalan Selama Pencerminan Database
Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server)
Bukti Pencerminan Database
Pemulihan Database Lengkap (Model Pemulihan Penuh)
Mode Operasi Pencerminan Database
Status Pencerminan (SQL Server)

  • Last updated on