Pengiriman dan Replikasi Log (SQL Server)

Berlaku untuk:SQL Server

Pengiriman log melibatkan dua salinan database tunggal yang biasanya berada di komputer yang berbeda. Pada waktu tertentu, hanya satu salinan database yang saat ini tersedia untuk klien. Salinan ini dikenal sebagai database utama. Pembaruan yang dibuat oleh klien ke database utama disebarluaskan dengan cara pengiriman log ke salinan database lainnya, yang dikenal sebagai database sekunder. Pengiriman log melibatkan penerapan log transaksi dari setiap penyisipan, pembaruan, atau penghapusan yang dilakukan pada database utama ke database sekunder.

Pengiriman log dapat digunakan bersama dengan replikasi, dengan perilaku berikut:

  • Replikasi tidak berlanjut setelah kegagalan pengiriman log. Jika failover terjadi, agen replikasi tidak terhubung ke sekunder, sehingga transaksi tidak direplikasi ke Pelanggan. Jika failback ke sistem utama terjadi, replikasi dilanjutkan. Semua transaksi yang mencatat salinan pengiriman log dari server sekunder kembali ke server primer direplikasi ke pelanggan.

  • Jika primer hilang secara permanen, sekunder dapat diganti namanya sehingga replikasi dapat dilanjutkan. Sisa topik ini menjelaskan persyaratan dan prosedur untuk menangani kasus ini. Contoh yang diberikan adalah database publikasi, yang merupakan database paling umum untuk mencatat pengiriman, tetapi proses serupa juga dapat diterapkan ke database langganan dan distribusi.

Untuk informasi tentang memulihkan database yang terlibat dalam replikasi tanpa perlu mengonfigurasi ulang replikasi, lihat Mencadangkan dan Memulihkan Database yang Direplikasi.

Catatan

Gunakan grup ketersediaan AlwaysOn, bukan pengiriman log, untuk menyediakan ketersediaan untuk database publikasi. Untuk informasi selengkapnya, lihat Mengonfigurasi replikasi dengan grup ketersediaan Always On.

Persyaratan dan Prosedur untuk Mereplikasi dari Sekunder Jika Primer Hilang

Perhatikan persyaratan dan pertimbangan berikut:

  • Jika primer berisi lebih dari satu database publikasi, log mengirimkan semua database publikasi ke sekunder yang sama.

  • Jalur penginstalan untuk instans server sekunder harus sama dengan yang utama. Lokasi database pengguna di server sekunder harus sama seperti pada primer.

  • Cadangkan kunci utama layanan pada server utama. Kunci ini akan dipulihkan di sistem sekunder. Untuk informasi selengkapnya, lihat BACKUPSERVICEBACKUP SERVICE MASTER KEY (Transact-SQL).

  • Pengiriman log tidak menjamin terhadap kehilangan data. Kegagalan pada database utama dapat mengakibatkan hilangnya data yang belum dicadangkan atau data yang cadangannya hilang saat kegagalan terjadi.

Pengiriman Log dengan Replikasi Transaksional

Untuk replikasi transaksional, perilaku pengiriman log tergantung pada sinkronisasi dengan opsi cadangan . Opsi ini dapat diatur pada database publikasi dan database distribusi; dalam log shipping untuk Publisher, hanya pengaturan pada database publikasi yang berlaku.

Mengaktifkan opsi ini pada database publikasi memastikan bahwa transaksi tidak akan dikirimkan ke database distribusi sampai transaksi tersebut dicadangkan pada database publikasi. Cadangan database publikasi terakhir kemudian dapat dipulihkan di server sekunder tanpa kemungkinan database distribusi memiliki transaksi yang tidak dimiliki database publikasi yang dipulihkan. Opsi ini menjamin bahwa jika Publisher beralih ke server sekunder, konsistensi tetap terjaga antara Publisher, Distributor, dan Subscriber. Latensi dan throughput dipengaruhi karena transaksi tidak dapat dikirim ke database distribusi hingga transaksi tersebut dicadangkan di Publisher; jika aplikasi Anda dapat menerima latensi ini, kami sarankan agar Anda mengatur opsi ini di database publikasi. Jika opsi sinkronisasi dengan cadangan tidak diatur, Pelanggan mungkin menerima perubahan yang tidak lagi disertakan dalam database yang dipulihkan di server sekunder. Untuk informasi selengkapnya, lihat Strategi untuk Mencadangkan dan Memulihkan Rekam Jepret dan Replikasi Transaksional.

Untuk mengonfigurasi replikasi transaksional dan pengiriman log dengan opsi sinkronisasi dengan cadangan

  1. Jika opsi sinkronisasi dengan cadangan tidak diatur pada database publikasi, jalankan sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Untuk informasi selengkapnya, lihat sp_replicationdboption (Transact-SQL).

  2. Konfigurasikan pengiriman log untuk database publikasi. Untuk informasi selengkapnya, lihat Mengonfigurasi Pengiriman Log (SQL Server).

  3. Jika Publisher gagal, pulihkan log terakhir dari database tersebut ke server sekunder dengan menggunakan opsi KEEP_REPLICATION dari RESTORE LOG. Ini mempertahankan semua pengaturan replikasi untuk basis data. Untuk informasi selengkapnya, lihat Fail Over to a Log Shipping Secondary (SQL Server) dan RESTORE (Transact-SQL).

  4. Pulihkan database msdb dan database master dari database utama ke sekunder. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database Sistem (SQL Server). Jika primer juga merupakan Distributor, pulihkan database distribusi dari primer ke sekunder.

    Database ini harus konsisten dengan database publikasi di primer dalam hal konfigurasi dan pengaturan replikasi.

  5. Di server sekunder, ganti nama komputer lalu ganti nama instans SQL Server agar sesuai dengan nama server utama. Untuk informasi tentang mengganti nama komputer, lihat dokumentasi Windows. Untuk informasi tentang mengganti nama server, lihat Mengganti nama Komputer yang Menghosting Instans Mandiri SQL Server dan Mengganti Nama Instans Kluster Failover SQL Server.

  6. Di server sekunder, pulihkan kunci master layanan yang telah dicadangkan dari server primer. Untuk informasi selengkapnya, lihat RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

Untuk mengonfigurasi replikasi transaksional dan pengiriman log tanpa opsi sinkronisasi dengan cadangan

  1. Konfigurasikan pengiriman log untuk database publikasi. Untuk informasi selengkapnya, lihat Mengonfigurasi Pengiriman Log (SQL Server).

  2. Jika Publisher gagal, pulihkan log terakhir dari database tersebut ke server sekunder dengan menggunakan opsi KEEP_REPLICATION dari RESTORE LOG. Ini mempertahankan semua pengaturan replikasi untuk basis data. Untuk informasi selengkapnya, lihat Fail Over to a Log Shipping Secondary (SQL Server) dan RESTORE (Transact-SQL).

  3. Pulihkan database msdb dan database master dari database utama ke sekunder. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database Sistem (SQL Server). Jika primer juga merupakan Distributor, pulihkan database distribusi dari primer ke sekunder.

    Database ini harus konsisten dengan database publikasi di primer dalam hal konfigurasi dan pengaturan replikasi.

  4. Di server sekunder, ganti nama komputer lalu ganti nama instans SQL Server agar sesuai dengan nama server utama. Untuk informasi tentang mengganti nama komputer, lihat dokumentasi Windows. Untuk informasi tentang mengganti nama server, lihat Mengganti nama Komputer yang Menghosting Instans Mandiri SQL Server dan Mengganti Nama Instans Kluster Failover SQL Server.

    Anda mungkin menerima pesan kesalahan dari Agen Pembaca Log bahwa database publikasi dan database distribusi tidak disinkronkan.

  5. Di server sekunder, pulihkan kunci master layanan yang telah dicadangkan dari server primer. Untuk informasi selengkapnya, lihat RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

  6. Jalankan sp_replrestart. Prosedur tersimpan ini dapat digunakan untuk memaksa Agen Pembaca Log mengabaikan semua transaksi yang direplikasi sebelumnya dalam log database publikasi. Transaksi yang diterapkan setelah penyelesaian prosedur tersimpan diproses oleh Agen Pembaca Log. Untuk informasi selengkapnya, lihat sp_replrestart (Transact-SQL).

  7. Mulai ulang Agen Pembaca Log setelah prosedur tersimpan berhasil dijalankan. Untuk informasi selengkapnya, lihat Memulai dan Menghentikan Agen Replikasi (SQL Server Management Studio).

  8. Transaksi yang telah didistribusikan ke Pelanggan mungkin diterapkan di Penerbit. Untuk memastikan bahwa Agen Distribusi tidak gagal karena kesalahan saat mencoba menerapkan ulang transaksi ini di Subscriber, tentukan profil agen bernama Lanjutkan pada Kesalahan Konsistensi Data.

Pengiriman Log dengan Gabungkan Replikasi

Ikuti langkah-langkah dalam prosedur di bawah ini untuk mengonfigurasi replikasi penggabungan dan pengiriman log.

Untuk mengonfigurasi replikasi penggabungan dan pengiriman log

  1. Konfigurasikan pengiriman log untuk database publikasi. Untuk informasi selengkapnya, lihat Mengonfigurasi Pengiriman Log (SQL Server).

  2. Jika Publisher gagal, di server sekunder, ganti nama komputer lalu ganti nama instans SQL Server agar sesuai dengan nama server utama. Untuk informasi tentang mengganti nama komputer, lihat dokumentasi Windows. Untuk informasi tentang mengganti nama server, lihat Mengganti nama Komputer yang Menghosting Instans Mandiri SQL Server dan Mengganti Nama Instans Kluster Failover SQL Server.

  3. Pulihkan log terakhir dari database ke server sekunder, menggunakan opsi KEEP_REPLICATION dari RESTORE LOG. Ini mempertahankan semua pengaturan replikasi untuk basis data. Untuk informasi selengkapnya, lihat Fail Over to a Log Shipping Secondary (SQL Server) dan RESTORE (Transact-SQL).

  4. Pulihkan database msdb dan database master dari database utama ke sekunder. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database Sistem (SQL Server). Jika server primer juga merupakan Distributor, pulihkan database distribusi dari primer ke sekunder.

    Database ini harus konsisten dengan database publikasi di primer dalam hal konfigurasi dan pengaturan replikasi.

  5. Di server sekunder, pulihkan kunci master layanan yang telah dicadangkan dari server utama. Untuk informasi selengkapnya, lihat RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

  6. Sinkronkan database publikasi dengan satu atau beberapa database langganan. Ini memungkinkan Anda mengunggah perubahan yang dibuat sebelumnya di database publikasi, tetapi tidak diwakili dalam cadangan yang dipulihkan. Data yang dapat diunggah tergantung pada cara publikasi difilter:

    • Jika publikasi tidak difilter, Anda harus dapat memperbarui database publikasi dengan menyinkronkan dengan Pelanggan terbaru.

    • Jika publikasi difilter, Anda mungkin tidak dapat memperbarui database publikasi. Pertimbangkan tabel yang dipartisi sedih sehingga setiap langganan menerima data pelanggan hanya untuk satu wilayah: Utara, Timur, Selatan, dan Barat. Jika setidaknya ada satu Pelanggan untuk setiap partisi data, sinkronisasi dengan Pelanggan untuk setiap partisi harus memperbarui database publikasi. Namun, jika data di partisi Barat, misalnya, tidak direplikasi ke Pelanggan mana pun, data ini di Penerbit tidak dapat diperbarui. Dalam hal ini, kami sarankan untuk menginisialisasi ulang semua langganan sehingga data di Penerbit dan Pelanggan menyatu. Untuk informasi selengkapnya, lihat Menginisialisasi ulang Langganan.

    Jika Anda menyinkronkan dengan Pelanggan yang menjalankan versi SQL Server sebelum SQL Server 2005 (9.x), langganan tidak boleh anonim; langganan klien atau langganan server (disebut sebagai langganan lokal dan langganan global dalam rilis sebelumnya). Untuk informasi selengkapnya, lihat Menyinkronkan Data.

Lihat Juga

Replikasi SQL Server
Tentang Pengiriman Log (SQL Server)Mengonfigurasi replikasi dengan grup ketersediaan AlwaysOn