Replikasi Transaksional
Berlaku untuk: SQL ServerAzure SQL Database Azure SQL Managed Instance
Replikasi transaksional biasanya dimulai dengan rekam jepret objek dan data database publikasi. Segera setelah rekam jepret awal diambil, perubahan data berikutnya dan modifikasi skema yang dilakukan di Penerbit biasanya dikirimkan ke Pelanggan saat terjadi (mendekati real time). Perubahan data diterapkan pada Pelanggan dalam urutan yang sama dan dalam batas transaksi yang sama seperti yang terjadi di Penerbit; oleh karena itu, dalam publikasi, konsistensi transaksi dijamin.
Replikasi transaksional biasanya digunakan di lingkungan server-ke-server dan sesuai dalam setiap kasus berikut:
Anda ingin perubahan bertahap disebarkan ke Pelanggan saat terjadi.
Aplikasi memerlukan latensi rendah antara perubahan waktu yang dilakukan di Penerbit dan perubahan tiba di Pelanggan.
Aplikasi ini memerlukan akses ke status data perantara. Misalnya, jika baris berubah lima kali, replikasi transaksional memungkinkan aplikasi merespons setiap perubahan (seperti menembakkan pemicu), bukan hanya data bersih yang berubah ke baris.
Publisher memiliki volume aktivitas sisipkan, perbarui, dan hapus yang sangat tinggi.
Penerbit atau Pelanggan adalah database non-SQL Server, seperti Oracle.
Secara default, Pelanggan ke publikasi transaksional harus diperlakukan sebagai baca-saja, karena perubahan tidak disebarluaskan kembali ke Penerbit. Namun, replikasi transaksional memang menawarkan opsi yang memungkinkan pembaruan di Pelanggan.
Catatan
Azure SQL Managed Instance dapat menjadi penerbit, distributor, dan pelanggan untuk rekam jepret dan replikasi transaksional. Database di Azure SQL Database hanya dapat menjadi pelanggan pendorongan untuk rekam jepret dan replikasi transaksional. Untuk informasi selengkapnya, lihat Replikasi transaksional dengan Azure SQL Database dan Azure SQL Managed Instance.
Cara Kerja Replikasi Transaksional
Replikasi transaksional diimplementasikan oleh Agen Rekam Jepret SQL Server, Agen Pembaca Log, dan Agen Distribusi. Agen Rekam Jepret menyiapkan file rekam jepret yang berisi skema dan data tabel dan objek database yang diterbitkan, menyimpan file di folder rekam jepret, dan merekam pekerjaan sinkronisasi dalam database distribusi di Distributor.
Agen Pembaca Log memantau log transaksi setiap database yang dikonfigurasi untuk replikasi transaksional dan menyalin transaksi yang ditandai untuk replikasi dari log transaksi ke dalam database distribusi, yang bertindak sebagai antrean penyimpanan dan penerusan yang andal. Agen Distribusi menyalin file rekam jepret awal dari folder rekam jepret dan transaksi yang disimpan dalam tabel database distribusi kepada Pelanggan.
Perubahan bertahap yang dilakukan pada alur Penerbit kepada Pelanggan sesuai dengan jadwal Agen Distribusi, yang dapat berjalan terus menerus untuk latensi minimal, atau pada interval terjadwal. Karena perubahan pada data harus dilakukan di Penerbit (ketika replikasi transaksional digunakan tanpa opsi pembaruan segera atau pembaruan antrean), konflik pembaruan dihindari. Pada akhirnya, semua Pelanggan akan mencapai nilai yang sama dengan Penerbit. Jika opsi pembaruan segera atau pembaruan antrean digunakan dengan replikasi transaksional, pembaruan dapat dilakukan di Pelanggan, dan dengan pembaruan antrean, konflik mungkin terjadi.
Ilustrasi berikut menunjukkan komponen utama replikasi transaksional.
Himpunan Data Awal
Sebelum Pelanggan replikasi transaksional baru dapat menerima perubahan bertahap dari Penerbit, Pelanggan harus berisi tabel dengan skema dan data yang sama dengan tabel di Penerbit. Himpunan data awal biasanya merupakan rekam jepret yang dibuat oleh Agen Rekam Jepret dan didistribusikan dan diterapkan oleh Agen Distribusi. Himpunan data awal juga dapat disediakan melalui cadangan atau cara lain, seperti SQL Server Integration Services.
Ketika rekam jepret didistribusikan dan diterapkan ke Pelanggan, hanya Pelanggan yang menunggu rekam jepret awal yang terpengaruh. Pelanggan lain untuk publikasi tersebut (yang telah diinisialisasi) tidak terpengaruh.
Pemrosesan Rekam Jepret Bersamaan
Replikasi rekam jepret menempatkan kunci bersama pada semua tabel yang diterbitkan sebagai bagian dari replikasi selama pembuatan rekam jepret. Ini dapat mencegah pembaruan dibuat pada tabel penerbitan. Pemrosesan rekam jepret bersamaan, default dengan replikasi transaksional, tidak menahan kunci berbagi selama seluruh pembuatan rekam jepret, yang memungkinkan pengguna untuk terus bekerja tanpa gangguan saat replikasi membuat file rekam jepret awal.
Agen Snapshot
Prosedur di mana Agen Rekam Jepret menerapkan rekam jepret awal dalam replikasi transaksional adalah prosedur yang sama yang digunakan dalam replikasi rekam jepret (kecuali seperti yang diuraikan di atas sehubungan dengan pemrosesan rekam jepret bersamaan).
Setelah file rekam jepret dibuat, Anda dapat melihatnya di folder rekam jepret menggunakan Microsoft Windows Explorer.
Memodifikasi Data dan Agen Pembaca Log
Agen Pembaca Log berjalan di Distributor; biasanya berjalan terus menerus, tetapi juga dapat berjalan sesuai dengan jadwal yang Anda tetapkan. Saat menjalankan, Agen Pembaca Log terlebih dahulu membaca log transaksi publikasi (log database yang sama yang digunakan untuk pelacakan dan pemulihan transaksi selama operasi Mesin Database SQL Server reguler) dan mengidentifikasi pernyataan INSERT, UPDATE, dan DELETE, atau modifikasi lain yang dilakukan pada data dalam transaksi yang telah ditandai untuk replikasi. Selanjutnya, agen menyalin transaksi tersebut dalam batch ke database distribusi di Distributor. Agen Pembaca Log menggunakan prosedur tersimpan internal sp_replcmds untuk mendapatkan kumpulan perintah berikutnya yang ditandai untuk replikasi dari log. Database distribusi kemudian menjadi antrean store-and-forward tempat perubahan dikirim ke Pelanggan. Hanya transaksi yang berkomitmen yang dikirim ke database distribusi.
Setelah seluruh batch transaksi berhasil ditulis ke database distribusi, itu dilakukan. Setelah penerapan setiap batch perintah ke Distributor, Agen Pembaca Log memanggil sp_repldone untuk menandai tempat replikasi terakhir selesai. Akhirnya, agen menandai baris dalam log transaksi yang siap untuk dibersihkan. Baris yang masih menunggu untuk direplikasi tidak dihapus menyeluruh.
Perintah transaksi disimpan dalam database distribusi hingga disebarluaskan ke semua Pelanggan atau sampai periode retensi distribusi maksimum tercapai. Pelanggan menerima transaksi dalam urutan yang sama di mana mereka diterapkan di Penerbit.
Agen distribusi
Agen Distribusi berjalan di Distributor untuk langganan pendorongan dan di Pelanggan untuk langganan penarikan. Agen memindahkan transaksi dari database distribusi ke Pelanggan. Jika langganan ditandai untuk validasi, Agen Distribusi juga memeriksa apakah data di Penerbit dan Pelanggan cocok.
Jenis publikasi
Replikasi transaksional menawarkan empat jenis publikasi:
Jenis Publikasi | Deskripsi |
---|---|
Publikasi transaksi standar | Sesuai untuk topologi di mana semua data di Pelanggan bersifat baca-saja (replikasi transaksional tidak memberlakukan ini di Pelanggan). Publikasi transaksional standar dibuat secara default saat menggunakan Transact-SQL atau Objek Manajemen Replikasi (RMO). Saat menggunakan Wizard Publikasi Baru, mereka dibuat dengan memilih Publikasi transaksional di halaman Jenis Publikasi. Untuk informasi selengkapnya tentang membuat publikasi, lihat Menerbitkan Data dan Objek Database. |
Publikasi transaksi dengan langganan yang dapat diperbarui | Karakteristik jenis publikasi ini adalah: -Setiap lokasi memiliki data yang identik, dengan satu Penerbit dan satu Pelanggan. -Dimungkinkan untuk memperbarui baris di Pelanggan -Topologi ini paling cocok untuk lingkungan server yang membutuhkan ketersediaan tinggi dan skalabilitas baca. Untuk informasi selengkapnya, lihat Langganan yang Dapat Diperbarui. |
Topologi peer-to-peer | Karakteristik jenis publikasi ini adalah: - Setiap lokasi memiliki data yang identik dan bertindak sebagai Penerbit dan Pelanggan. - Baris yang sama hanya dapat diubah di satu lokasi pada satu waktu. - Mendukung deteksi konflik - Topologi ini paling cocok untuk lingkungan server yang membutuhkan ketersediaan tinggi dan skalabilitas baca. Untuk informasi selengkapnya, lihat Replikasi Transaksional Peer-to-Peer. |
Replikasi transaksional dua arah | Karakteristik jenis publikasi ini adalah: Replikasi dua arah mirip dengan replikasi Peer-to-Peer, namun, replikasi tidak memberikan resolusi konflik. Selain itu, replikasi dua arah dibatasi hingga 2 server. Untuk informasi selengkapnya, lihat Replikasi Transaksional Dua Arah |