Replikasi Transaksional

Berlaku untuk: SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Artikel ini memperkenalkan Replikasi transaksional untuk SQL Server. Replikasi transaksional biasanya dimulai dengan rekam jepret objek dan data database publikasi. Segera setelah snapshot awal dibuat, perubahan data berikutnya dan modifikasi skema yang dilakukan pada Publisher biasanya dikirimkan ke Subscriber seiring terjadinya perubahan tersebut (hampir secara 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.

Gambaran Umum

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 bawaan, Subscriber ke publikasi transaksional harus diperlakukan sebagai hanya untuk dibaca, karena perubahan tidak disebarluaskan kembali ke Penerbit. Namun, replikasi transaksional memang menawarkan opsi yang memungkinkan dilakukannya pembaruan pada Subscriber.

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 push untuk replikasi rekam jepret dan transaksional. Untuk informasi selengkapnya, lihat Replikasi transaksional dengan Azure SQL Database dan Azure SQL Managed Instance.

Konfigurasikan enkripsi TLS 1.3

SQL Server 2025 (17.x) memperkenalkan dukungan TDS 8.0 untuk replikasi transaksional, yang meliputi:

• Mengonfigurasi agen replikasi untuk menggunakan enkripsi TLS 1.3 antara instans SQL Server 2025 (17.x) dan juga antara SQL Server 2025 (17.x) dan Azure SQL Managed Instance.
• Enkripsi default untuk komunikasi server tertaut antar instans antara instans SQL Server 2025 (17.x) dalam topologi replikasi. Server tertaut di SQL Server 2025 (17.x) menggunakan driver OLE DB v19, yang secara default menggunakan Encrypt=Mandatory enkripsi.

Catatan

Untuk topologi replikasi dengan distributor jarak jauh:

• Komponen replikasi dapat gagal setelah peningkatan ke SQL Server 2025 untuk instans dengan distributor jarak jauh
• Menambahkan distributor jarak jauh ke penerbit SQL Server 2025 bisa gagal

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 basis data yang dikonfigurasi untuk replikasi transaksional dan menyalin transaksi yang ditandai untuk replikasi dari log transaksi ke dalam basis data distribusi, yang berfungsi sebagai antrean simpan-dan-terus yang andal. Agen Distribusi menyalin file rekam jepret awal dari folder rekam jepret dan transaksi yang disimpan dalam tabel database distribusi kepada Pelanggan.

Perubahan inkremental yang dibuat di Publisher diteruskan ke Subscriber sesuai jadwal Agen Distribusi, yang dapat berjalan terus-menerus untuk meminimalkan latensi, 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 tertunda digunakan dengan replikasi transaksional, pembaruan dapat dilakukan pada Subscriber, dan dengan pembaruan tertunda, konflik mungkin terjadi.

Ilustrasi berikut menunjukkan komponen utama replikasi transaksional.

Himpunan Data Awal

Sebelum Subscriber replikasi transaksional yang baru dapat menerima perubahan inkremental dari Publisher, Subscriber tersebut harus terlebih dahulu memiliki tabel dengan skema dan data yang sama seperti tabel pada Publisher. 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 Layanan Integrasi SQL Server.

Ketika rekam jepret didistribusikan dan diterapkan ke Pelanggan, hanya Pelanggan yang menunggu rekam jepret awal yang terpengaruh. Pelanggan lain dari publikasi tersebut (yang sudah diinisialisasi sebelumnya) tidak terpengaruh.

Pemrosesan Rekam Jepret Bersamaan

Replikasi snapshot menerapkan kunci berbagi pada semua tabel yang dipublikasikan sebagai bagian dari replikasi selama proses pembuatan snapshot. Ini dapat mencegah pembaruan dibuat pada tabel penerbitan. Pemrosesan snapshot bersamaan, yang merupakan default pada replikasi transaksional, tidak menahan kunci share selama keseluruhan pembuatan snapshot, yang memungkinkan pengguna untuk terus bekerja tanpa terganggu saat replikasi membuat file snapshot 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 sebelumnya mengenai 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 dijalankan, Agen Pembaca Log terlebih dahulu membaca log transaksi publikasi (log database yang sama yang digunakan untuk pelacakan dan pemulihan transaksi selama operasi reguler Mesin Database SQL Server) dan mengidentifikasi pernyataan INSERT, UPDATE, dan DELETE, atau modifikasi lain yang dilakukan terhadap 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 mengambil kumpulan perintah selanjutnya yang ditandai untuk replikasi dari log. Database distribusi kemudian menjadi antrean store-and-forward yang darinya perubahan dikirimkan ke Pelanggan. Hanya transaksi yang telah dikomit yang dikirim ke database distribusi.

Setelah seluruh batch transaksi berhasil ditulis ke database distribusi, transaksi tersebut dikonfirmasi. Setelah setiap batch perintah dikomitkan ke Distributor, Agen Pembaca Log memanggil sp_repldone untuk menandai titik terakhir penyelesaian replikasi. Akhirnya, agen menandai baris dalam log transaksi yang siap untuk dibersihkan. Baris yang masih menunggu untuk direplikasi tidak dihapus.

Perintah transaksi disimpan dalam database distribusi hingga disebarluaskan ke semua Pelanggan atau hingga periode retensi distribusi maksimum tercapai. Subscriber menerima transaksi dalam urutan yang sama seperti saat transaksi tersebut diterapkan pada Publisher.

Agen distribusi

Distribution Agent berjalan di Distributor untuk langganan push dan di Subscriber untuk langganan pull. 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 transaksional standar	Sesuai untuk topologi di mana semua data pada subscriber bersifat hanya-bisa-dibaca (replikasi transaksional tidak memberlakukan ini pada subscriber). 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 pada Subscriber -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 tersebut tidak memberikan resolusi konflik. Selain itu, replikasi dua arah dibatasi hingga 2 server. Untuk informasi selengkapnya, lihat Replikasi Transaksional Dua Arah