Mode Operasi Pencerminan Database

Berlaku untuk:SQL Server

Topik ini menjelaskan mode operasi sinkron dan asinkron untuk sesi pencerminan database.

Catatan

Untuk pengenalan pencerminan database, lihat Pencerminan Database (SQL Server).

Syarat dan Definisi

Bagian ini memperkenalkan beberapa istilah yang menjadi pusat topik ini.

Mode performa tinggi
Sesi pencerminan database beroperasi secara asinkron dan hanya menggunakan server utama dan server cermin. Satu-satunya bentuk pengalihan peran adalah layanan paksa (dengan kemungkinan kehilangan data).

Mode keamanan tinggi
Sesi pencerminan database beroperasi secara sinkron dan, secara opsional, menggunakan server witness, selain server utama dan server cermin.

Keamanan transaksi
Properti database khusus pencerminan yang menentukan apakah sesi pencerminan database beroperasi secara sinkron atau asinkron. Ada dua tingkat keamanan: PENUH dan NONAKTIF.

saksi
Hanya untuk digunakan dengan mode keamanan tinggi, instans SQL Server opsional yang memungkinkan server cermin menentukan apakah akan memulai failover otomatis. Tidak seperti kedua mitra failover, witness tidak menyediakan layanan untuk database. Mendukung failover otomatis adalah satu-satunya peran saksi.

Pencerminan Database Asinkron (Mode Performa Tinggi)

Bagian ini menjelaskan cara kerja pencerminan database asinkron, ketika sesuai untuk menggunakan mode performa tinggi, dan cara merespons jika server utama gagal.

Catatan

Sebagian besar edisi SQL Server hanya mendukung pencerminan database sinkron ("Safety Full Only"). Untuk informasi tentang edisi yang sepenuhnya mendukung pencerminan database, lihat "Ketersediaan Tinggi (Selalu Aktif)" di Edisi dan fitur yang didukung SQL Server 2022.

Ketika keamanan transaksi diatur ke NONAKTIF, sesi pencerminan database beroperasi secara asinkron. Operasi asinkron hanya mendukung satu mode operasi dengan performa tinggi. Mode ini meningkatkan performa dengan mengorbankan ketersediaan tinggi. Mode berkinerja tinggi hanya menggunakan server utama dan server cermin. Masalah pada server cermin tidak pernah berdampak pada server utama. Jika server utama gagal, basis data cermin ditandai sebagai TERPUTUS, tetapi tersedia sebagai mode siaga hangat.

Mode berperforma tinggi, hanya mendukung satu bentuk peralihan peran: layanan paksa (dengan kemungkinan kehilangan data), yang menggunakan server cermin sebagai server siaga hangat. Layanan paksa adalah salah satu kemungkinan respons terhadap kegagalan server utama. Karena ada kemungkinan data hilang, Anda harus mempertimbangkan alternatif lain sebelum memaksa layanan beralih ke mirror. Untuk informasi selengkapnya, lihat Merespons Kegagalan Prinsipal, nanti dalam topik ini.

Gambar berikut menunjukkan konfigurasi sesi menggunakan mode performa tinggi.

Dalam mode performa tinggi, segera setelah server utama mengirim log untuk transaksi ke server cermin, server utama mengirimkan konfirmasi kepada klien, tanpa menunggu pengakuan dari server cermin. Transaksi dikomit tanpa menunggu server cermin menulis log ke disk. Operasi asinkron memungkinkan server utama untuk berjalan dengan latensi transaksi minimum.

Server cermin mencoba mengikuti catatan log yang dikirim oleh server utama. Tetapi database cermin mungkin tertinggal agak di belakang database utama, meskipun biasanya kesenjangan antara database kecil. Namun, selisih tersebut dapat menjadi cukup besar jika server utama menangani beban kerja yang berat atau sistem server cermin mengalami kelebihan beban.

Di bagian ini:

• Kapan mode berkinerja tinggi sesuai?

• Dampak Witness terhadap Mode Performa Tinggi

• Menanggapi Kegagalan Prinsipal

Kapan mode berkinerja tinggi sesuai?

Mode performa tinggi dapat berguna dalam skenario pemulihan bencana di mana server utama dan cermin dipisahkan oleh jarak yang signifikan dan di mana Anda tidak ingin kesalahan kecil berdampak pada server utama.

Catatan

Pengiriman log dapat menjadi suplemen untuk pencerminan database dan merupakan alternatif yang menguntungkan untuk pencerminan database asinkron. Untuk informasi tentang keuntungan pengiriman log, lihat Solusi Ketersediaan Tinggi (SQL Server). Untuk informasi tentang menggunakan pengiriman log dengan pencerminan database, lihat Pencerminan Database dan Pengiriman Log (SQL Server).

Dampak Saksi pada Mode Berkinerja Tinggi

Jika Anda menggunakan Transact-SQL untuk mengonfigurasi mode berkinerja tinggi, setiap kali properti SAFETY diatur ke NONAKTIF, kami sangat menyarankan agar properti WITNESS juga diatur ke NONAKTIF. Seorang saksi dapat hidup berdampingan dengan mode performa tinggi, tetapi saksi tidak memberikan manfaat dan menimbulkan risiko.

Jika witness terputus dari sesi saat salah satu mitra mengalami kegagalan, database menjadi tidak dapat diakses. Ini karena, meskipun mode performa tinggi tidak memerlukan saksi, jika saksi dikonfigurasi, sesi tersebut memerlukan kuorum yang terdiri dari setidaknya dua instans server. Jika sesi kehilangan kuorum, sesi tidak dapat melayani database.

Ketika saksi ditetapkan dalam sesi mode berkinerja tinggi, penerapan kuorum berarti bahwa:

• Jika server cermin hilang, server utama harus terhubung ke saksi. Jika tidak, server utama membuat database menjadi offline hingga server saksi atau server cermin bergabung kembali ke dalam sesi.

• Jika server utama tidak tersedia, pengalihan layanan secara paksa ke server cermin mengharuskan server cermin terhubung ke server saksi.

Catatan

Untuk informasi tentang jenis kuorum, lihat Kuorum: Bagaimana Bukti Memengaruhi Ketersediaan Database (Pencerminan Database).

Menanggapi Kegagalan Prinsipal

Jika principal gagal, pemilik basis data memiliki beberapa pilihan sebagai berikut:

• Biarkan database tidak tersedia sampai server utama tersedia kembali.

  Jika database utama dan log transaksinya utuh, pilihan ini mempertahankan semua transaksi yang dilakukan dengan mengorbankan ketersediaan.

• Hentikan sesi pencerminan database, perbarui database secara manual, lalu mulai sesi pencerminan database baru.

  Jika database utama hilang tetapi server utama masih berjalan, segera upayakan pencadangan bagian akhir log dari database utama. Jika pencadangan log akhir berhasil, menonaktifkan pencerminan mungkin menjadi pilihan terbaik. Setelah menghapus pencerminan, Anda dapat memulihkan log ke database cermin sebelumnya, yang mempertahankan semua data.

  Catatan

  Jika pencadangan log akhir gagal dan Anda tidak dapat menunggu server utama pulih, pertimbangkan untuk memaksakan layanan, yang memiliki kelebihan karena mempertahankan status sesi.

• Paksa servis (dengan kemungkinan kehilangan data) pada server mirror.

  Layanan paksa benar-benar merupakan metode pemulihan bencana dan harus digunakan dengan hemat. Pemaksaan layanan hanya dapat dilakukan jika server utama sedang tidak aktif, sesi bersifat asinkron (keamanan transaksi diatur ke NONAKTIF), dan salah satu dari kondisi berikut terpenuhi: sesi tidak memiliki saksi apa pun (properti WITNESS diatur ke NONAKTIF) atau saksi terhubung ke server cermin (artinya, keduanya memiliki kuorum).

  Pemaksaan layanan menyebabkan server cermin mengambil alih peran utama dan menggunakan salinan basis datanya untuk melayani klien. Saat layanan dipaksakan, log transaksi apa pun yang belum dikirim oleh server principal ke server cermin akan hilang. Oleh karena itu, Anda harus membatasi layanan paksa ke situasi di mana kemungkinan kehilangan data dapat diterima dan ketersediaan database langsung sangat penting. Untuk informasi tentang cara kerja layanan paksa dan praktik terbaik untuk menggunakannya, lihat Pengalihan Peran Selama Sesi Pencerminan Database (SQL Server).

Pencerminan Database Sinkron (Mode Keselamatan Tinggi)

Bagian ini menjelaskan cara kerja pencerminan database sinkron, termasuk mode keamanan tinggi alternatif (dengan failover otomatis dan tanpa failover otomatis), dan berisi informasi tentang peran saksi dalam failover otomatis.

Ketika keamanan transaksi diatur ke PENUH, sesi pencerminan database berjalan dalam mode keamanan tinggi dan beroperasi secara sinkron setelah fase sinkronisasi awal. Bagian ini menjelaskan rincian sesi pencerminan basis data yang dikonfigurasi untuk beroperasi secara sinkron.

Untuk mencapai operasi sinkron untuk sesi, server cermin harus menyinkronkan database cermin dengan database utama. Ketika sesi dimulai, server utama mulai mengirim log aktifnya ke server cermin. Server cermin menulis semua catatan log masuk ke disk secepat mungkin. Segera setelah semua rekaman log yang diterima ditulis ke disk, database disinkronkan. Selama mitra tetap berkomunikasi, database tetap disinkronkan.

Catatan

Untuk memantau perubahan status dalam sesi pencerminan database, gunakan kelas peristiwa Perubahan Status Pencerminan Database. Untuk informasi selengkapnya, lihat Database Mirroring State Change Event Class.

Setelah sinkronisasi selesai, setiap transaksi yang dilakukan pada database utama juga dilakukan di server cermin, menjamin perlindungan data. Hal ini dicapai dengan menunggu untuk melakukan transaksi pada database utama, sampai server utama menerima pesan dari server cermin yang menyatakan bahwa ia telah mengeraskan log transaksi ke disk. Perhatikan bahwa menunggu pesan ini meningkatkan latensi transaksi.

Waktu yang diperlukan untuk sinkronisasi pada dasarnya tergantung pada seberapa jauh database cermin berada di belakang database utama pada awal sesi (diukur dengan jumlah catatan log yang awalnya diterima dari server utama), beban kerja pada database utama, dan kecepatan sistem cermin. Setelah sesi disinkronkan, log yang diperkeras yang belum direbus pada database cermin tetap berada dalam antrean pengulangan.

Segera setelah database cermin disinkronkan, status kedua salinan database berubah menjadi SYNCHRONIZED.

Operasi sinkron dipertahankan dengan cara berikut:

1. Saat menerima transaksi dari klien, server utama menulis log untuk transaksi ke log transaksi.

2. Server utama menulis transaksi ke database dan, secara bersamaan, mengirim catatan log ke server cermin. Server utama menunggu konfirmasi dari server cermin sebelum mengonfirmasi salah satu dari hal berikut kepada klien: komit transaksi atau rollback.

3. Server cermin menyimpan log secara permanen ke disk dan mengirimkan konfirmasi ke server utama.

4. Saat menerima pengakuan dari server cermin, server utama mengirimkan pesan konfirmasi ke klien.

Mode keamanan tinggi melindungi data Anda dengan mengharuskan data disinkronkan di antara dua tempat. Semua transaksi yang telah dikomitkan dijamin akan ditulis ke disk di server cermin.

Di bagian ini:

• Mode Keamanan Tinggi Tanpa Failover Otomatis

• Mode Keamanan Tinggi dengan Failover Otomatis

Mode Keamanan Tinggi Tanpa Failover Otomatis

Gambar berikut menunjukkan konfigurasi mode keamanan tinggi tanpa failover otomatis. Konfigurasi hanya terdiri dari dua mitra.

Ketika partner terhubung dan database sudah disinkronkan, failover manual dapat dilakukan. Jika instans server cermin gagal, instans server utama tidak terpengaruh dan tetap berjalan tanpa perlindungan (artinya tanpa pencerminan data). Jika server utama tidak tersedia, server mirror ditangguhkan, tetapi layanan dapat dialihkan secara paksa ke server mirror (dengan potensi kehilangan data). Untuk informasi selengkapnya, lihat Pengalihan Peran Selama Sesi Pencerminan Database (SQL Server).

Mode Keamanan Tinggi dengan Failover Otomatis

Failover otomatis memberikan ketersediaan tinggi dengan memastikan bahwa database masih dilayani setelah hilangnya satu server. Failover otomatis mengharuskan sesi memiliki instans server ketiga, bukti, yang idealnya berada di komputer ketiga. Gambar berikut menunjukkan konfigurasi sesi mode keselamatan tinggi yang mendukung failover otomatis.

Tidak seperti kedua mitra tersebut, saksi tidak berfungsi melayani basis data. Saksi hanya mendukung failover otomatis dengan memverifikasi apakah server utama aktif dan berfungsi. Server cermin memulai failover otomatis hanya jika cermin dan saksi tetap terhubung satu sama lain setelah keduanya terputus dari server utama.

Ketika witness diatur, sesi memerlukan kuorum—hubungan antara setidaknya dua instans server yang memungkinkan database tersedia. Untuk informasi selengkapnya, lihat Bukti Pencerminan Database dan Kuorum: Bagaimana Bukti Memengaruhi Ketersediaan Database (Pencerminan Database).

Failover otomatis memerlukan kondisi berikut:

• Database sudah disinkronkan.

• Kegagalan terjadi saat semua tiga instans server terhubung, dan server saksi serta server cermin tetap terhubung.

Hilangnya mitra memiliki efek berikut:

• Jika server utama menjadi tidak tersedia dalam kondisi di atas, failover otomatis terjadi. Server cermin beralih ke peran utama, dan menawarkan databasenya sebagai database utama.

• Jika server utama menjadi tidak tersedia ketika kondisi tersebut tidak terpenuhi, memaksa layanan (dengan kemungkinan kehilangan data) mungkin dimungkinkan. Untuk informasi selengkapnya, lihat Pengalihan Peran Selama Sesi Pencerminan Database (SQL Server).

• Jika satu-satunya server cermin tidak tersedia, server utama dan server saksi tetap berjalan.

Jika sesi kehilangan saksi, kuorum mengharuskan kedua mitra. Jika salah satu mitra kehilangan kuorum, kedua mitra kehilangan kuorum, dan database menjadi tidak tersedia sampai kuorum dibuat kembali. Persyaratan kuorum ini memastikan bahwa jika tidak ada saksi, database tidak pernah berjalan dalam keadaan terekspos, yaitu tanpa dicerminkan.

Catatan

Jika Anda memperkirakan saksi akan tetap tidak terhubung selama waktu yang cukup lama, kami sarankan agar Anda mengeluarkan saksi dari sesi sampai koneksinya kembali tersedia.

Pengaturan Transact-SQL dan Mode Operasi Pencerminan Database

Bagian ini menjelaskan sesi pencerminan database berdasarkan pengaturan ALTER DATABASE serta keadaan database yang dicerminkan dan saksi, jika ada. Bagian ini ditujukan untuk pengguna yang mengelola pencerminan database terutama atau secara eksklusif menggunakan Transact-SQL, daripada menggunakan SQL Server Management Studio.

Tips

Sebagai alternatif untuk menggunakan Transact-SQL, Anda dapat mengontrol mode operasi sesi di Object Explorer menggunakan halaman Pencerminan kotak dialog Properti Database. Untuk informasi selengkapnya, lihat Membuat Sesi Pencerminan Database Menggunakan Autentikasi Windows (SQL Server Management Studio).

Di bagian ini:

• Bagaimana Keselamatan Transaksi dan Status Saksi Memengaruhi Mode Operasi

• Melihat Pengaturan Keselamatan dan Status Saksi

• Faktor-Faktor yang Memengaruhi Perilaku saat Server Utama Hilang

Bagaimana Keselamatan Transaksi dan Status Saksi Memengaruhi Mode Operasi

Mode operasi sesi ditentukan oleh kombinasi pengaturan keamanan transaksi dan status saksi. Kapan saja, pemilik database dapat mengubah tingkat keamanan transaksi, dan dapat menambahkan atau menghapus saksi.

Di bagian ini:

• Keamanan Transaksi

• Status Saksi

Keamanan Transaksi

Keamanan transaksi adalah properti database khusus pencerminan yang menentukan apakah sesi pencerminan database beroperasi secara sinkron atau asinkron. Ada dua tingkat keamanan: PENUH dan NONAKTIF.

• KEAMANAN PENUH

  Keamanan transaksi penuh menyebabkan sesi beroperasi secara sinkron dalam mode keamanan tinggi. Jika ada saksi, sesi mendukung failover otomatis.

  Saat Anda membuat sesi menggunakan ALTER DATABASE pernyataan, sesi dimulai dengan properti SAFETY yang diatur ke PENUH; yaitu, sesi dimulai dalam mode keamanan tinggi. Setelah sesi dimulai, Anda dapat menambahkan saksi.

  Untuk informasi selengkapnya, lihat Pencerminan Database Sinkron (Mode Keselamatan Tinggi), sebelumnya dalam topik ini.

• PENGAMAN TIDAK AKTIF

  Mematikan keamanan transaksi menyebabkan sesi beroperasi secara asinkron, dalam mode performa tinggi. Jika properti SAFETY diatur ke NONAKTIF, properti WITNESS juga harus diatur ke NONAKTIF (default). Untuk informasi tentang dampak saksi dalam mode berkinerja tinggi, lihat Status Saksi, nanti dalam topik ini. Untuk informasi selengkapnya tentang menjalankan dengan keamanan transaksi dinonaktifkan, lihat Pencerminan Database Asinkron (Mode Performa Tinggi), sebelumnya dalam topik ini.

Pengaturan keamanan transaksi database dicatat pada setiap mitra dalam tampilan katalog sys.database_mirroring di kolom mirroring_safety_level dan mirroring_safety_level_desc . Untuk informasi selengkapnya, lihat sys.database_mirroring (Transact-SQL).

Pemilik database dapat mengubah tingkat keamanan transaksi kapan saja.

Status Saksi

Jika saksi telah ditetapkan, kuorum diperlukan, sehingga status saksi selalu signifikan.

Jika ada, saksi memiliki salah satu dari dua negara bagian:

• Ketika saksi terhubung ke mitra, saksi berada dalam keadaan CONNECTED terhadap mitra tersebut dan memiliki kuorum dengan mitra tersebut. Dalam hal ini, database dapat tersedia, bahkan jika salah satu mitra tidak tersedia.

• Ketika saksi ada tetapi tidak terhubung ke mitra, saksi berada dalam status TIDAK DIKETAHUI atau TERPUTUS relatif terhadap mitra tersebut. Dalam hal ini, saksi tidak memiliki kuorum dengan mitra tersebut, dan jika mitra tidak terhubung satu sama lain, database menjadi tidak tersedia.

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

Status setiap saksi pada instans server dicatat dalam tampilan katalog sys.database_mirroring di kolom mirroring_witness_state dan mirroring_witness_state_desc . Untuk informasi selengkapnya, lihat sys.database_mirroring (Transact-SQL).

Tabel berikut ini meringkas bagaimana mode operasi sesi tergantung pada pengaturan keamanan transaksi dan status saksi.

Mode operasi	Keamanan transaksi	Status saksi
Mode performa tinggi	TIDAK AKTIF	NULL (tidak ada saksi)**
Mode keamanan tinggi tanpa failover otomatis	FULL	NULL (tidak ada saksi)
Mode keamanan tinggi dengan failover otomatis*	FULL	TERHUBUNG

*Jika saksi terputus koneksinya, kami sarankan Anda menyetel WITNESS ke OFF hingga instance server saksi kembali tersedia.

**Jika saksi hadir dalam mode performa tinggi, saksi tidak berpartisipasi dalam sidang. Namun, untuk membuat database tersedia, setidaknya dua instans server harus tetap terhubung. Oleh karena itu, kami menyarankan agar properti WITNESS tetap diatur ke OFF dalam sesi mode performa tinggi. Untuk informasi selengkapnya, lihat Kuorum: Bagaimana Bukti Memengaruhi Ketersediaan Database (Pencerminan Database).

Melihat Pengaturan Keselamatan dan Status Saksi

Untuk melihat pengaturan keamanan dan status saksi untuk database, gunakan tampilan katalog sys.database_mirroring . Kolom yang relevan adalah sebagai berikut:

Faktor	Kolom	Deskripsi
Keamanan transaksi	mirroring_safety_level atau mirroring_safety_level_desc	Pengaturan keamanan transaksi untuk pembaruan pada basis data cermin, salah satunya: UNKNOWN TIDAK AKTIF Penuh NULL= database tidak online.
Apakah ada saksi?	mirroring_witness_name	Nama server dari bukti pencerminan database atau NULL, menunjukkan bahwa tidak ada saksi.
Status saksi	mirroring_witness_state atau mirroring_witness_state_desc	Status saksi dalam database pada mitra tertentu: UNKNOWN TERHUBUNG Terputus NULL = tidak ada bukti atau database tidak online.

Misalnya, pada server utama atau cermin, masukkan:

SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring  

Untuk informasi selengkapnya tentang tampilan katalog ini, lihat sys.database_mirroring (Transact-SQL).

Faktor-Faktor yang Memengaruhi Perilaku saat Server Utama Hilang

Tabel berikut ini meringkas efek gabungan dari pengaturan keamanan transaksi, status database, dan status saksi tentang perilaku sesi pencerminan pada hilangnya server utama.

Keamanan transaksi	Status pencerminan database cermin	Status saksi	Perilaku ketika prinsipal hilang
PENUH	Tersinkronisasi	TERHUBUNG	Failover otomatis terjadi.
PENUH	TERSINKRONISASI	TIDAK TERHUBUNG	Server mirror berhenti; failover tidak dapat dilakukan, dan database tidak dapat dibuat tersedia.
TIDAK AKTIF	DITANGGUHKAN atau TERPUTUS	NULL (tidak ada saksi)	Layanan dapat dipaksa ke server cermin (dengan kemungkinan kehilangan data).
FULL	MENYINKRONKAN atau DITANGGUHKAN	NULL (tidak ada saksi)	Layanan dapat dipaksa ke server cermin (dengan kemungkinan kehilangan data).

Tugas Terkait

• Menambahkan atau Mengganti Bukti Pencerminan Database (SQL Server Management Studio)

• Membuat Sesi Pencerminan Database Menggunakan Autentikasi Windows (SQL Server Management Studio)

• Menambahkan Bukti Pencerminan Database Menggunakan Autentikasi Windows (Transact-SQL)

• Menghapus Saksi dari Sesi Pencerminan Database (SQL Server)

• Mengubah Keamanan Transaksi dalam Sesi Pencerminan Database (T-SQL)

Lihat Juga

Memantau Pencerminan Database (SQL Server)
Bukti Pencerminan Database