Bagikan melalui


Langganan yang Dapat Diperbarui untuk Replikasi Transaksional

Berlaku untuk: SQL Server 2008 (dan yang lebih baru)

Catatan

Fitur ini akan dihapus dalam versi Microsoft SQL Server mendatang. Hindari menggunakan fitur ini dalam pekerjaan pengembangan baru, dan rencanakan untuk memodifikasi aplikasi yang saat ini menggunakan fitur ini.

Pada SQL Server 2014, replikasi transaksional mendukung pembaruan di Pelanggan melalui langganan yang dapat diperbarui dan replikasi peer-to-peer. Berikut ini adalah dua jenis langganan yang dapat diperbarui:

  • Segera memperbarui. Penerbit dan Pelanggan harus terhubung untuk memperbarui data di Pelanggan.

  • Mengantre memperbarui Penerbit dan Pelanggan tidak harus terhubung untuk memperbarui data di Pelanggan. Updates dapat dibuat saat Pelanggan atau Penerbit sedang offline.

Ketika data diperbarui di Pelanggan, data pertama kali disebarluaskan ke Penerbit dan kemudian disebarluaskan ke Pelanggan lain. Jika pembaruan segera digunakan, perubahan segera disebarluaskan menggunakan protokol penerapan dua fase. Jika pembaruan antrean digunakan, perubahan disimpan dalam antrean; transaksi antrean kemudian diterapkan secara asinkron di Publisher setiap kali konektivitas jaringan tersedia. Karena pembaruan disebarluaskan secara asinkron ke Publisher, data yang sama mungkin telah diperbarui oleh Penerbit atau oleh Pelanggan dan konflik lain dapat terjadi saat menerapkan pembaruan. Konflik terdeteksi dan diselesaikan sesuai dengan kebijakan resolusi konflik yang ditetapkan saat membuat publikasi.

Jika Anda membuat publikasi transaksional dengan langganan yang dapat diperbarui di Wizard Publikasi Baru, pembaruan segera dan pembaruan antrean akan diaktifkan. Jika Anda membuat publikasi dengan prosedur tersimpan, Anda dapat mengaktifkan satu atau kedua opsi. Saat membuat langganan ke publikasi, Anda menentukan mode pembaruan mana yang akan digunakan. Anda kemudian dapat beralih di antara mode pembaruan jika perlu. Untuk informasi selengkapnya, lihat bagian berikut "Beralih antar Mode Pembaruan".

Untuk mengaktifkan langganan yang dapat diperbarui untuk publikasi transaksional, Aktifkan Memperbarui Langganan untuk Publikasi Transaksional

Untuk membuat langganan yang dapat diperbarui untuk publikasi transaksi, lihat Membuat Langganan yang Dapat Diperbarui ke Publikasi Transaksi

Beralih Antar Mode Pembaruan

Saat menggunakan langganan yang dapat diperbarui, Anda dapat menentukan bahwa langganan harus menggunakan satu mode pembaruan lalu beralih ke mode lainnya jika aplikasi memerlukannya. Misalnya, Anda dapat menentukan bahwa langganan harus menggunakan pembaruan segera, tetapi beralih ke pembaruan antrean jika kegagalan sistem mengalihkan hilangnya konektivitas jaringan.

Catatan

Replikasi tidak beralih secara otomatis di antara mode pembaruan. Anda harus mengatur mode pembaruan melalui SQL Server Management Studio atau aplikasi Anda harus memanggil sp_setreplfailovermode (Transact-SQL) untuk beralih antar mode.

Jika Anda beralih dari pembaruan segera ke pembaruan antrean, Anda tidak dapat beralih kembali ke pembaruan segera hingga Pelanggan dan Penerbit tersambung dan Agen Pembaca Antrean telah menerapkan semua pesan yang tertunda dalam antrean ke Penerbit.

Untuk beralih di antara mode pembaruan

Untuk beralih antara mode pembaruan, Anda harus mengaktifkan publikasi dan langganan untuk kedua mode pembaruan, lalu beralih di antara mode tersebut jika perlu. Untuk mengetahui informasi selengkapnya, lihat
Beralih Antar Mode Pembaruan untuk Langganan Transaksi yang Dapat Diperbarui.

Pertimbangan untuk Menggunakan Langganan yang Dapat Diperbarui

  • Setelah publikasi diaktifkan untuk memperbarui langganan atau mengantre memperbarui langganan, opsi tidak dapat dinonaktifkan untuk publikasi (meskipun langganan tidak perlu menggunakannya). Untuk menonaktifkan opsi, publikasi harus dihapus dan yang baru dibuat.

  • Penerbitan ulang data tidak didukung.

  • Replikasi menambahkan kolom msrepl_tran_version ke tabel yang diterbitkan untuk tujuan pelacakan. Karena kolom tambahan ini, semua INSERT pernyataan harus menyertakan daftar kolom.

  • Untuk membuat perubahan skema pada tabel dalam publikasi yang mendukung pembaruan langganan, semua aktivitas pada tabel harus dihentikan di Penerbit dan Pelanggan, dan perubahan data yang tertunda harus disebarluaskan ke semua simpul sebelum membuat perubahan skema apa pun. Ini memastikan bahwa transaksi yang terutang tidak bertentangan dengan perubahan skema yang tertunda. Setelah perubahan skema disebarluaskan ke semua simpul, aktivitas dapat dilanjutkan pada tabel yang diterbitkan. Untuk informasi selengkapnya, lihat Menghentikan Topologi Replikasi (Pemrograman Transact-SQL Replikasi).

  • Jika Anda berencana untuk beralih di antara mode pembaruan, Agen Pembaca Antrean harus berjalan setidaknya sekali setelah langganan diinisialisasi (secara default, Agen Pembaca Antrean berjalan terus menerus).

  • Jika database Pelanggan dipartisi secara horizontal dan ada baris dalam partisi yang ada di Pelanggan, tetapi tidak di Penerbit, Pelanggan tidak dapat memperbarui baris yang sudah ada sebelumnya. Mencoba memperbarui baris ini mengembalikan kesalahan. Baris harus dihapus dari tabel lalu ditambahkan di Publisher.

Updates di Pelanggan

  • Updates di Pelanggan disebarluaskan ke Penerbit meskipun langganan kedaluwarsa atau tidak aktif. Pastikan langganan tersebut dihilangkan atau diinisialisasi ulang.

  • Jika TIMESTAMP kolom atau IDENTITY digunakan, dan direplikasi sebagai jenis data dasarnya, nilai dalam kolom ini tidak boleh diperbarui di Pelanggan.

  • Pelanggan tidak dapat memperbarui atau menyisipkan textnilai , ntext atau image karena tidak dimungkinkan untuk membaca dari tabel yang disisipkan atau dihapus di dalam pemicu pelacakan perubahan replikasi. Demikian pula, Pelanggan tidak dapat memperbarui atau menyisipkan atau image nilai text menggunakan WRITETEXT atau UPDATETEXT karena data ditimpa oleh Penerbit. Sebagai gantinya, Anda dapat mempartisi text kolom dan image menjadi tabel terpisah dan mengubah dua tabel dalam transaksi.

    Untuk memperbarui objek besar di Pelanggan, gunakan jenis varchar(max)data , nvarchar(max), varbinary(max) bukan textjenis data , ntext, dan image masing-masing.

  • Updates ke kunci unik (termasuk kunci primer) yang menghasilkan duplikat (misalnya, pembaruan formulir UPDATE <column> SET <column> =<column>+1 tidak diizinkan dan akan ditolak karena pelanggaran keunikan. Ini karena set pembaruan yang dibuat pada Pelanggan disebarluaskan oleh replikasi sebagai pernyataan individual UPDATE untuk setiap baris yang terpengaruh.

  • Jika database Pelanggan dipartisi secara horizontal dan ada baris dalam partisi yang ada di Pelanggan tetapi tidak di Penerbit, Pelanggan tidak dapat memperbarui baris yang sudah ada sebelumnya. Mencoba memperbarui baris ini mengembalikan kesalahan. Baris harus dihapus dari tabel dan disisipkan lagi.

Pemicu yang ditentukan pengguna

  • Jika aplikasi memerlukan pemicu di Pelanggan, pemicu harus ditentukan dengan NOT FOR REPLICATION opsi di Penerbit dan Pelanggan. Ini memastikan bahwa pemicu diaktifkan hanya untuk perubahan data asli, tetapi tidak ketika perubahan tersebut direplikasi.

    Pastikan bahwa pemicu yang ditentukan pengguna tidak diaktifkan saat pemicu replikasi memperbarui tabel. Ini dilakukan dengan memanggil prosedur sp_check_for_sync_trigger dalam isi pemicu yang ditentukan pengguna. Untuk informasi selengkapnya, lihat sp_check_for_sync_trigger (Transact-SQL).

Segera Memperbarui

  • Untuk segera memperbarui langganan, perubahan di Pelanggan disebarluaskan ke Penerbit dan diterapkan menggunakan Koordinator Transaksi Terdistribusi Microsoft (MS DTC). Pastikan MS DTC diinstal dan dikonfigurasi di Penerbit dan Pelanggan. Untuk informasi selengkapnya, lihat dokumentasi Windows.

  • Pemicu yang digunakan dengan segera memperbarui langganan memerlukan koneksi ke Publisher untuk mereplikasi perubahan.

  • Jika publikasi memungkinkan segera memperbarui langganan dan artikel dalam publikasi memiliki filter kolom, Anda tidak dapat memfilter kolom yang tidak dapat diubah ke null tanpa default.

Pembaruan Antrean

  • Tabel yang disertakan dalam publikasi gabungan juga tidak dapat diterbitkan sebagai bagian dari publikasi transaksional yang memungkinkan antrean memperbarui langganan.

  • Updates dibuat untuk kolom kunci primer tidak disarankan saat menggunakan pembaruan antrean karena kunci primer digunakan sebagai pencari catatan untuk semua kueri. Ketika kebijakan resolusi konflik diatur ke Pelanggan Wins, pembaruan pada kunci primer harus dilakukan dengan hati-hati. Jika pembaruan pada kunci primer dilakukan di Penerbit dan di Pelanggan, hasilnya akan menjadi dua baris dengan kunci primer yang berbeda.

  • Untuk kolom jenis SQL_VARIANTdata : ketika data disisipkan atau diperbarui di Pelanggan, data dipetakan dengan cara berikut oleh Agen Pembaca Antrean saat disalin dari Pelanggan ke antrean:

    • BIGINT, , NUMERICDECIMAL, MONEY, dan SMALLMONEY dipetakan ke NUMERIC.

    • BINARY dan VARBINARY dipetakan ke VARBINARY data.

Deteksi dan Resolusi Konflik

  • Untuk kebijakan konflik Pelanggan Wins: resolusi konflik tidak didukung untuk pembaruan pada kolom kunci primer.

  • Konflik karena kegagalan batasan kunci asing tidak diselesaikan dengan replikasi:

    • Jika konflik tidak diharapkan dan data dipartisi dengan baik (Pelanggan tidak memperbarui baris yang sama), Anda dapat menggunakan batasan kunci asing pada Penerbit dan Pelanggan.

    • Jika konflik diharapkan: Anda tidak boleh menggunakan batasan kunci asing di Penerbit atau Pelanggan jika Anda menggunakan resolusi konflik "Pelanggan menang"; Anda tidak boleh menggunakan batasan kunci asing di Pelanggan jika Anda menggunakan resolusi konflik "Publisher wins".

Lihat juga

Replikasi Transaksional Peer-to-Peer
Replikasi Transaksional
Menerbitkan Data dan Objek Database
Berlangganan Publikasi