Bagikan melalui

Pengalihan Peran Selama Sesi Pencerminan Database (SQL Server)

  • Artikel

Berlaku untuk: 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. Berpotensi, peran dapat beralih bolak-balik baik sebagai respons terhadap beberapa kegagalan atau untuk tujuan administratif.

Catatan

Topik ini mengasumsikan bahwa Anda terbiasa dengan mode operasi pencerminan database. Untuk informasi selengkapnya, lihat Mode Operasi Pencerminan Database.

Ilustrasi berikut menunjukkan mitra pencerminan, Partner_A dan Partner_B, mengalihkan peran utama dan cermin melalui serangkaian failover otomatis atau manual.

Mitra beralih dua kali di antara peran

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.

Catatan

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

  • Failover manual

    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, nanti dalam topik ini.

  • Failover otomatis

    Di hadapan saksi, mode keselamatan tinggi mendukung failover otomatis. Failover otomatis hanya terjadi pada hilangnya server utama ketika server saksi dan cermin masih terhubung satu sama lain dan database sudah disinkronkan. Untuk informasi selengkapnya, lihat Failover Otomatis, nanti dalam topik ini.

  • Layanan paksa (dengan kemungkinan kehilangan data)

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

    Catatan

    Sebaiknya properti WITNESS diatur ke NONAKTIF dalam mode performa tinggi. Jika tidak, untuk membuat database online, server cermin harus terhubung 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.

Bentuk failover Performa tinggi Mode keamanan tinggi tanpa saksi Mode keselamatan tinggi dengan saksi
Failover otomatis Tidak No Ya
Failover 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, pekerjaan pencadangan harus dibuat di server utama baru, untuk memastikan bahwa database terus dicadangkan pada jadwal regulernya. 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).

Failover Manual

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

Di bagian ini:

Mempertahankan Ketersediaan Selama Peningkatan

Administrator database dapat menggunakan failover manual untuk meningkatkan perangkat keras atau perangkat lunak tanpa mengorbankan ketersediaan. Untuk menggunakan pencerminan database untuk peningkatan perangkat lunak, server cermin dan/atau sistem harus sudah menerima peningkatan.

Catatan

Pencerminan database harus dapat melakukan peningkatan bergulir, tetapi ini tidak dijamin, karena perubahan di masa mendatang tidak diketahui. Untuk informasi selengkapnya, lihat Meningkatkan Instans Cermin.

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 yang direncanakan

Kondisi yang Diperlukan untuk Failover Manual

Failover manual memerlukan keamanan transaksi untuk diatur ke FULL (yaitu, mode keselamatan tinggi). Ketika mitra tersambung dan database sudah disinkronkan, failover manual didukung.

Cara Kerja Failover Manual

Failover manual memulai urutan tindakan berikut:

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

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

    Catatan

    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 selesai meneruskan database cermin. Jumlah waktu yang diperlukan tergantung pada kecepatan sistem, beban kerja terbaru, dan jumlah log dalam antrean pengulangan. Untuk mode operasi sinkron, waktu failover dapat diatur dengan membatasi ukuran antrean pengulangan. Namun, ini dapat menyebabkan server utama melambat untuk memungkinkan server cermin mengikuti.

    Catatan

    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 baru mengembalikan transaksi yang tidak diterapkan dan membawa salinan databasenya secara 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.

    Catatan

    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 bukti dalam mode keselamatan tinggi (mode keselamatan tinggi dengan failover otomatis). Dalam mode keamanan tinggi dengan failover otomatis, setelah database disinkronkan, jika database utama menjadi tidak tersedia, 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.

Di bagian ini:

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 Mode Operasi Pencerminan Database.

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

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

    Catatan

    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 antrean pengulangan, server cermin selesai meneruskan database cermin.

    Catatan

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

  4. Database cermin sebelumnya bergerak online sebagai database utama baru, dan pemulihan membersihkan semua transaksi yang tidak dilakukan 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 telah menyinkronkan ulang database, failover kembali dimungkinkan, tetapi ke arah terbalik.

Ilustrasi berikut menunjukkan satu instans failover 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 mengenali bahwa prinsipal tidak lagi tersedia sesi 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).

Catatan

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 bukti.

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 memaksa risiko layanan kemungkinan kehilangan data, layanan harus digunakan dengan hati-hati dan 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, saksi dapat ada untuk sesi mode berkinerja tinggi. Dalam hal ini, memaksa 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 keamanan tinggi dengan failover otomatis mendukung layanan pemaksaan setiap kali server cermin dan bukti terhubung satu sama lain dan tidak terhubung ke server utama (selama server cermin tidak dalam proses menggulung balik database cermin ketika terakhir terhubung ke prinsipal).

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. Memaksa layanan memulai transisi peran utama yang lancar 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. Jika tidak, setelah layanan dipaksa, database utama asli dan database utama saat ini dapat diperbarui secara independen dari yang lain.

Di bagian ini:

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 diekspos (yaitu, tidak disarankan). Pada titik ini, klien dapat terhubung kembali ke Partner_B.

Ketika Partner_A tersedia, ia terhubung kembali ke server utama baru, bergabung kembali dengan sesi dan dengan asumsi 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 database memilih untuk melanjutkan pencerminan. Pada saat itu, Partner_A mengambil alih peran server cermin dan mengembalikan database utama sebelumnya ke titik waktu transaksi terakhir yang berhasil disinkronkan; jika ada transaksi yang diterapkan tidak ditulis ke disk di server cermin sebelum layanan dipaksa, mereka 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.

Catatan

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

Risiko Layanan Memaksa

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 fork pemulihan baru. Karena database utama asli dan database cermin berada di fork pemulihan yang berbeda, setiap database sekarang berisi data yang tidak dilakukan database lain: database utama asli berisi perubahan apa pun yang belum dikirim dari antrean pengirimannya ke database cermin sebelumnya (log tidak terkirim); database cermin sebelumnya berisi perubahan apa pun yang terjadi setelah layanan dipaksa.

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. Di bawah mode berkinerja tinggi, akumulasi log tidak terkirman selalu merupakan kemungkinan.

Implikasi memaksa layanan sebagian bergantung pada apakah sesi memiliki saksi:

  • Dengan tidak adanya saksi, layanan dapat dipaksa jika mitra terputus, misalnya, karena koneksi jaringan mereka rusak. 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, setiap transaksi yang terjadi setelah layanan dipaksa juga hilang.

  • Di hadapan saksi, jika server cermin terputus dari server utama dan saksi, selama dua yang terakhir tetap terhubung satu sama lain, prinsipal berjalan terekspos. Jika server utama kemudian terputus dari saksi, server tersebut berhenti melayani database. Setelah itu, jika server cermin terhubung kembali ke saksi, memaksa layanan menjadi mungkin. 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, ketika server utama asli memulai ulang dengan cepat 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 akan dapat diterima, Anda harus menghapus pencerminan untuk menyelamatkannya.

    Menghapus pencerminan akan memungkinkan administrator database memulihkan database utama asli dan mencoba memulihkan data yang akan hilang. Namun, ketika database cermin sebelumnya online, mantan mitra akan melayani database 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 apa pun akan dapat diterima, Anda dapat melanjutkan 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 ditangguhkan. Untuk melanjutkan 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 pencerminan 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 Mirroring Database
Status Pencerminan (SQL Server)