SQL Server Replikasi: Panduan Lengkap untuk DBA [2026]

SQL Server Replikasi adalah serangkaian teknologi untuk menyalin dan mendistribusikan data dan objek basis data dari satu basis data ke basis data lain, kemudian melakukan sinkronisasi antar basis data untuk menjaga konsistensi. Fitur ini memungkinkan Anda untuk membuat dan memelihara beberapa salinan data Anda di berbagai server dan lokasi, sehingga memastikan ketersediaan dan keandalan data.

1.2 Tujuan dan Manfaat Replikasi

SQL Server Replikasi memenuhi berbagai kebutuhan bisnis penting dan memberikan keuntungan signifikan untuk manajemen basis data dan distribusi data:

Distribusi Data di Berbagai Lokasi: Replikasi memungkinkan Anda untuk berbagi data di seluruh kantor regional atau lokasi global, meningkatkan efisiensi operasional dengan memastikan akses lokal ke data yang dibutuhkan. Hal ini mengurangi latensi jaringan dan memberikan kinerja yang lebih baik bagi pengguna yang tersebar secara geografis.
Ketersediaan Tinggi dan Pemulihan Bencana: Dengan memelihara replika data penting di beberapa server, replikasi memberikan redundansi yang melindungi dari kegagalan perangkat keras dan bencana. Jika server utama mengalami kegagalan, salinan yang direplikasi dapat berfungsi sebagai sumber cadangan, meminimalkan waktu henti dan kehilangan data.
Penyeimbangan Beban dan Skalabilitas: Replikasi mendistribusikan operasi baca ke beberapa server, mencegah satu server menjadi hambatan. Pendekatan ini meningkatkan kinerja sistem dan memungkinkan infrastruktur Anda untuk berkembang secara horizontal seiring pertumbuhan data dan permintaan pengguna.
Pelaporan dan Analisis Waktu Nyata: Mengalihkan beban kueri pelaporan dan analitik ke server replikasi mengurangi beban pada basis data produksi. Pengguna dapat menjalankan kueri analitik kompleks terhadap data mendekati waktu nyata tanpa memengaruhi sistem operasional, sehingga memastikan kinerja dan kesegaran data.
Integrasi dan Konsolidasi Data: Replikasi memfasilitasi penggabungan data dari berbagai sumber ke dalam satu tampilan terpadu. Hal ini sangat berharga bagi organisasi dengan banyak kantor cabang yang perlu mengumpulkan data di kantor pusat, atau untuk membuat gudang data terpusat dari sistem operasional yang tersebar.

2. SQL Server Arsitektur dan Komponen Replikasi

SQL Server Arsitektur replikasi terdiri dari beberapa komponen yang saling terhubung dan bekerja sama untuk mendistribusikan dan menyinkronkan data di seluruh infrastruktur basis data Anda. Bagian ini membahas komponen inti, termasuk penerbit, distributor, pelanggan, publikasi, artikel, langganan, dan agen yang mengoordinasikan aliran data di antara mereka:

Publisher: Penerbit adalah sebuah SQL Server contoh bahwa hostIni adalah satu atau lebih basis data yang berisi data yang akan direplikasi. Basis data ini berfungsi sebagai sumber otoritatif dalam topologi replikasi.
Distributor: Distributor adalah seorang SQL Server Instance yang mengelola aliran data antara penerbit dan pelanggan. Instance distributor hosts adalah basis data distribusi, yang menyimpan metadata replikasi dan transaksi.
Pelanggan: Pelanggan adalah seorang SQL Server Sebuah instance yang menerima dan menyimpan data yang direplikasi dari penerbit. Sebuah instance pelanggan tunggal dapat memilikiost beberapa basis data pelanggan, masing-masing menerima data dari publikasi yang berbeda.
Publikasi: Suatu publikasi menentukan data apa yang akan direplikasi dan bagaimana data tersebut akan didistribusikan kepada pelanggan. Publikasi tersebut mengelompokkan artikel-artikel terkait dan menetapkan metodologi replikasi yang berlaku untuk semua objek yang terk contained di dalamnya.
Pasal: Artikel adalah blok bangunan fundamental dari replikasi, yang mewakili objek basis data individual yang akan didistribusikan kepada pelanggan.
Berlangganan: Langganan menetapkan hubungan antara publikasi dan pelanggan, menentukan bagaimana dan kapan data dikirimkan ke basis data tujuan.
Agen: Agen adalah proses khusus yang melakukan pekerjaan sebenarnya dalam memindahkan dan menyinkronkan data antar komponen replikasi.

3. Jenis SQL Server sahutan

SQL Server menyediakan beberapa jenis replikasi, yang masing-masing dirancang untuk skenario distribusi data dan kebutuhan bisnis tertentu. Memahami karakteristik, keunggulan, dan keterbatasan setiap jenis sangat penting untuk memilih pendekatan yang tepat untuk lingkungan Anda.

3.1 Replikasi Snapshot

Replikasi snapshot mengambil snapshot data yang akan dipublikasikan pada waktu tertentu, kemudian mendistribusikan salinan lengkap yang persis sama ke pelanggan. Replikasi ini tidak memantau perubahan selanjutnya hingga snapshot berikutnya dihasilkan. Replikasi snapshot adalah bentuk replikasi yang paling sederhana, sehingga cocok untuk skenario di mana data jarang berubah atau di mana memiliki data yang sedikit usang dapat diterima.

Kasus penggunaan umum meliputi pendistribusian data referensi seperti daftar harga atau nilai tukar yang diperbarui secara berkala, penyediaan kumpulan data awal untuk gudang data, dan skenario di mana pembaruan data lengkap lebih disukai daripada melacak perubahan individual. Misalnya, sebuah perusahaan dapat menggunakan replikasi snapshot untuk mendistribusikan katalog produk yang diperbarui ke kantor cabang sekali sehari.

Keunggulan utama replikasi snapshot adalah kesederhanaannya, persyaratan pemeliharaan yang rendah, dan kemampuan untuk mereplikasi data tanpa kunci utama. Namun, ia memiliki beberapa kelemahan signifikan, termasuk dampak yang tinggi saat snapshot dibuat karena penguncian tabel, latensi tinggi antar pembaruan, dan inefisiensi untuk kumpulan data besar atau data yang sering berubah. Setiap modifikasi yang dilakukan pada pelanggan akanost saat snapshot berikutnya diterapkan.

3.2 Replikasi Transaksional

Replikasi transaksional mengirimkan perubahan dari penerbit ke pelanggan hampir secara real-time dengan mereplikasi transaksi individual saat terjadi. Proses ini dimulai dengan snapshot awal untuk menetapkan garis dasar, kemudian terus memantau log transaksi untuk perubahan pada artikel yang diterbitkan dan mengirimkannya ke pelanggan secara bertahap.

Replikasi transaksional ideal untuk skenario server-ke-server yang membutuhkan throughput tinggi dan latensi rendah. Kasus penggunaan umum meliputi peningkatan skalabilitas dan ketersediaan dengan mengalihkan operasi baca ke server pelanggan, mendukung penyimpanan data dan pelaporan dengan data mendekati waktu nyata, mengintegrasikan data dari beberapa situs ke lokasi pusat, dan mengalihkan pemrosesan batch ke server khusus. Misalnya, platform e-commerce dapat menggunakan replikasi transaksional untuk menjaga sinkronisasi data inventaris di seluruh basis data regional.

Keunggulan replikasi transaksional meliputi pengiriman data dengan latensi rendah, throughput tinggi untuk volume transaksi besar, dan kemampuan untuk melakukan modifikasi non-replikasi pada pelanggan. Kekurangannya meliputi kompleksitas yang lebih besar dibandingkan dengan replikasi snapshot, persyaratan kunci utama pada tabel yang direplikasi, dan potensi kegagalan replikasi jika terjadi konflik seperti pelanggaran kunci utama pada pelanggan.

3.3 Penggabungan Replikasi

Replikasi penggabungan (merge replication) dirancang khusus untuk lingkungan di mana pelanggan (subscriber) perlu bekerja secara offline atau dengan konektivitas yang terputus-putus, kemudian menyinkronkan perubahan saat koneksi tersedia. Jenis replikasi ini memungkinkan data diubah baik di penerbit (publisher) maupun pelanggan (subscriber) secara independen, melacak perubahan menggunakan pemicu (trigger) dan tabel metadata, serta secara otomatis menggabungkan modifikasi selama sinkronisasi.

Replikasi gabungan dirancang untuk aplikasi seluler dan lingkungan server terdistribusi di mana perubahan otonom terjadi. Kasus penggunaannya meliputi otomatisasi tenaga penjualan di mana pengguna seluler bekerja secara offline dan melakukan sinkronisasi kemudian, sistem titik penjualan yang beroperasi secara independen dan mengkonsolidasikan data secara berkala, dan aplikasi terdistribusi di mana beberapa lokasi perlu memperbarui data bersama. Misalnya, sebuah jaringan ritel dapat menggunakan replikasi gabungan sehingga setiap toko dapat mengelola inventaris lokal sambil melakukan sinkronisasi dengan sistem gudang pusat.

Keunggulan replikasi penggabungan (merge replication) meliputi dukungan untuk pelanggan otonom yang dapat melakukan perubahan, toleransi terhadap konektivitas jaringan yang terputus-putus, dan resolusi konflik yang fleksibel. Kekurangannya meliputi kompleksitas yang lebih besar dalam pengaturan dan pemeliharaan, beban kinerja dari pelacakan metadata dan pemicu, penambahan kolom pengidentifikasi unik ke tabel, dan potensi konflik yang memerlukan pengelolaan dan penyelesaian.

3.4 Replikasi Peer-to-Peer

Replikasi peer-to-peer dibangun di atas replikasi transaksional dan memungkinkan beberapa instance server (tiga node atau lebih) untuk bertindak sebagai rekan yang setara, dengan setiap node berfungsi sebagai penerbit dan pelanggan secara bersamaan. Dalam topologi ini, semua node menyimpan salinan data yang identik dan dapat menangani operasi baca dan tulis, sehingga menyediakan lingkungan multi-master yang benar-benar terdistribusi.

Replikasi peer-to-peer cocok untuk aplikasi yang membutuhkan skalabilitas operasi baca dan ketersediaan tinggi. Kasus penggunaannya meliputi aplikasi web yang mendistribusikan kueri katalog ke beberapa node sambil mempertahankan konsistensi data, skenario yang membutuhkan pemeliharaan atau peningkatan tanpa downtime dengan menonaktifkan node satu per satu, dan aplikasi global dengan pusat data di berbagai wilayah. Misalnya, organisasi dukungan perangkat lunak di seluruh dunia mungkin menggunakan replikasi peer-to-peer di berbagai kantor di zona waktu yang berbeda sehingga setiap lokasi memiliki akses lokal ke data terkini.

Keunggulan replikasi peer-to-peer meliputi peningkatan performa baca melalui skalabilitas, ketersediaan yang lebih tinggi dengan banyak node aktif, dan konsistensi data mendekati waktu nyata. Kekurangannya meliputi persyaratan untuk Edisi Enterprise, kompleksitas dalam mengelola topologi multi-node, kebutuhan akan skema dan data yang identik di semua node, dan potensi konflik ketika operasi penulisan tidak dipartisi dengan benar.

3.5 Replikasi Dua Arah

Replikasi dua arah adalah topologi replikasi transaksional spesifik yang dirancang khusus untuk lingkungan dua server di mana kedua server perlu bertukar perubahan satu sama lain. Setiap server mempublikasikan data dan berlangganan data yang sama dari server lain, menciptakan alur sinkronisasi dua arah yang sederhana. Meskipun replikasi peer-to-peer juga dapat mendukung dua node, replikasi dua arah memberikan peningkatan kinerja untuk skenario spesifik ini.

Replikasi dua arah cocok untuk skenario yang membutuhkan dua server aktif dengan data yang tersinkronisasi, seperti konfigurasi aktif-aktif untuk ketersediaan tinggi atau aplikasi yang didistribusikan secara geografis di mana setiap lokasi membutuhkan akses tulis lokal. Topologi ini membutuhkan desain aplikasi yang cermat untuk mempartisi pembaruan data dan mencegah konflik.

Keuntungannya meliputi kinerja yang dioptimalkan untuk skenario dua server, konfigurasi yang lebih sederhana dibandingkan dengan replikasi peer-to-peer, sinkronisasi mendekati waktu nyata, dan overhead yang lebih rendah daripada replikasi penggabungan. Kerugiannya meliputi keterbatasan hanya pada dua server, kurangnya resolusi konflik bawaan yang memerlukan desain aplikasi yang cermat, dan perlunya strategi partisi yang tepat untuk mencegah konflik.

3.6 Langganan yang Dapat Diperbarui

Langganan yang dapat diperbarui memperluas replikasi transaksional untuk memungkinkan pelanggan melakukan perubahan sesekali pada data yang direplikasi, yang kemudian menyebar kembali ke penerbit dan ke pelanggan lain. Tidak seperti replikasi gabungan atau topologi peer-to-peer yang dirancang untuk pembaruan dua arah yang sering, langganan yang dapat diperbarui ditujukan untuk skenario di mana aliran data utama adalah satu arah (penerbit ke pelanggan) tetapi pelanggan sesekali perlu melakukan koreksi atau pembaruan.

Langganan yang dapat diperbarui cocok untuk skenario di mana most Pembaruan terjadi di pihak penerbit, tetapi pembaruan sesekali di pihak pelanggan diperlukan, seperti kantor lapangan yang terutama membaca data tetapi perlu melakukan koreksi atau pembaruan lokal. Topologi ini memerlukan perencanaan yang cermat untuk meminimalkan konflik dan memastikan konsistensi data.

Keuntungan utamanya meliputi memungkinkan operasi penulisan terbatas pada pelanggan sambil mempertahankan karakteristik kinerja replikasi transaksional. Kerugiannya meliputi peningkatan kompleksitas, potensi konflik yang memerlukan penyelesaian, beban kinerja dari protokol two-phase commit dalam mode pembaruan langsung, dan persyaratan bahwa semua tabel yang direplikasi memiliki kunci utama.

3.7 Perbandingan Berbagai Jenis Replikasi

Jenis Replikasi	Update Waktu	Jumlah Penerbit	Kepemimpinan	Gunakan Skenario
Potret	Titik waktu	1	Satu arah (Penerbit → Pelanggan)	Data referensi yang jarang berubah (daftar harga, nilai tukar)
Transaksional	Hampir real-time	1	Satu arah (Penerbit → Pelanggan)	Skenario dengan throughput tinggi (inventaris e-commerce, penyimpanan data, pelaporan)
Bergabung	Periodik (bila terhubung)	1	Dua arah (Penerbit ↔ Pelanggan)	Aplikasi seluler, pekerja offline (otomatisasi tenaga penjualan, layanan lapangan)
Peer-to-Peer	Hampir real-time	Banyak (3 atau lebih)	Dua arah (semua node)	Penyebaran multi-pusat data global (kantor di seluruh dunia dengan akses baca-tulis lokal)
Dua arah	Hampir real-time	2	Dua arah (kedua server)	Konfigurasi aktif-aktif dua pusat data (ketersediaan tinggi dua lokasi)
Langganan yang Dapat Diperbarui	Hampir real-time	1	Pada dasarnya satu arah (pembaruan terbalik sesekali)	Kantor cabang yang terutama membaca tetapi kadang-kadang memperbarui (koreksi lokal)

4. Pengaturan SQL Server sahutan

4.1 Prasyarat dan Persyaratan

4.1.1 Persyaratan Perangkat Lunak

SQL Server replikasi membutuhkan kompatibilitas SQL Server versi di seluruh peserta dalam topologi. Versi distributor harus sama dengan atau lebih tinggi dari versi penerbit, dan pelanggan dapat berada dalam rentang dua versi dari penerbit. Misalnya, sebuah SQL Server Penerbit tahun 2016 dapat mereplikasi ke SQL Server Pelanggan tahun 2012, 2014, 2016, 2017, atau 2019.

4.1.2 Persyaratan Izin

Mengonfigurasi replikasi memerlukan izin khusus di setiap level. Anggota peran server tetap sysadmin dapat melakukan semua tugas konfigurasi replikasi. Untuk izin yang lebih terperinci, pengguna perlu menjadi anggota peran basis data db_owner untuk basis data penerbit dan pelanggan.

4.2 Langkah 1: Konfigurasi Distribusi

Mengonfigurasi distribusi adalah langkah pertama dalam pengaturan. SQL Server replikasi.

Untuk mengkonfigurasi distribusi menggunakan SQL Server Studio Manajemen:

Hubungkan ke SQL Server contoh di SQL Server Studio Manajemen.
Di Object Explorer, klik kanan sahutan folder dan pilih Konfigurasi Distribusi.
Di Panduan Konfigurasi Distribusi, klik Selanjutnya di halaman selamat datang.
pada Distributor Pada halaman ini, pilih salah satu opsi berikut berdasarkan kebutuhan topologi Anda:
- Distributor LokalPilih “ServerName akan bertindak sebagai Distributornya sendiri; SQL Server akan membuat basis data distribusi dan log” jika Anda ingin penerbit dan distributor berjalan pada instance yang sama (instance saat ini). Konfigurasi ini lebih mudah diatur dan cocok untuk lingkungan yang lebih kecil atau ketika latensi jaringan antara penerbit dan distributor akan menyebabkan masalah.
- Distributor Jarak JauhPilih “Gunakan server berikut sebagai Distributor” dan klik Add Untuk menentukan server distributor jarak jauh jika Anda ingin memindahkan pemrosesan distribusi ke instance terpisah. Konfigurasi ini meningkatkan kinerja saat volume replikasi tinggi dengan mendistribusikan beban kerja ke beberapa server. Anda perlu memberikan nama distributor jarak jauh dan menentukan kata sandi yang akan digunakan penerbit untuk terhubung ke distributor.
Klik Selanjutnya Untuk menentukan lokasi folder snapshot. Gunakan jalur UNC (seperti \\servername\share\folder) daripada jalur lokal untuk memastikan aksesibilitas melalui jaringan.
pada Basis Data Distribusi Pada halaman tersebut, terima nama basis data distribusi default (biasanya "distribution") atau tentukan nama khusus, lalu konfigurasikan lokasi file data dan log.
pada Penerbit Pada halaman tersebut, verifikasi bahwa server saat ini diaktifkan sebagai penerbit. Jika Anda mengkonfigurasi server saat ini sebagai distributor, Anda dapat menambahkan penerbit tambahan yang akan menggunakan distributor ini.
Tinjau tindakan wizard dan klik Finish untuk mengkonfigurasi distribusi.

4.3 Langkah 2: Membuat Publikasi

Setelah mengkonfigurasi distribusi, langkah selanjutnya adalah membuat publikasi yang menentukan objek data mana yang akan direplikasi ke pelanggan.

Untuk membuat publikasi menggunakan SQL Server Studio Manajemen:

Di Object Explorer, perluas sahutan folder.
Klik kanan Publikasi Lokal dan pilih Publikasi Baru.
Penyihir Publikasi Barutarts; klik Selanjutnya di halaman selamat datang.
Pilih basis data yang ingin Anda publikasikan dari Basis Data Publikasi halaman. Ini secara otomatis mengaktifkan penerbitan pada basis data yang dipilih.
pada Jenis Publikasi halaman, pilih jenis replikasi: Publikasi Snapshot, Publikasi transaksional, Publikasi antar-peer, atau Gabungkan publikasi.
pada Artikel halaman, perluas Meja Pilih node dan tabel yang akan disertakan sebagai artikel.
Perluasan opsional Prosedur Tersimpan, views, atau jenis objek lain untuk menyertakan artikel tambahan.
Klik Properti Artikel untuk mengkonfigurasi pemfilteran atau pengaturan khusus artikel lainnya.
pada Filter Baris Tabel halaman, tambahkan filter baris jika diperlukan.
pada Agen Snapshot Di halaman ini, pilih kapan snapshot akan dibuat: segera, pada waktu tertentu, atau sesuai jadwal.
pada Keamanan Agen Pada halaman tersebut, tentukan konteks keamanan untuk Agen Snapshot.
pada Tindakan Penyihir halaman, pilih Buat publikasinya.
Berikan nama publikasi dan klik Finish.

4.4 Langkah 3: Buat Langganan

Setelah membuat publikasi, langkah selanjutnya adalah membuat langganan yang menghubungkan publikasi tersebut dengan basis data pelanggan.

Langganan dapat berupa langganan dorong (dikelola oleh distributor) atau langganan tarik (dikelola oleh pelanggan). Perbedaan utamanya terletak pada tempat Anda membuat langganan dan lokasi agen yang Anda pilih, yang menentukan tindakan langganan (dorong atau tarik).

Untuk Langganan Push (dikelola oleh Distributor):

pada penerbit server, perluas sahutan -> Publikasi Lokal.
Klik kanan publikasi dan pilih Langganan Baru.

Untuk Langganan Tarik (dikelola oleh Pelanggan):

pada langganan server, perluas sahutan, klik kanan Langganan Lokal, Lalu pilih Langganan Baru.
pada Publikasi Halaman, klik Menemukan SQL Server Publisher dan terhubung ke server penerbit.

Langkah-langkah umum dalam wizard untuk kedua jenis langganan:

Di Panduan Langganan Baru, klik Selanjutnya di halaman selamat datang.
Pilih publikasi dan klik Selanjutnya.
pada Lokasi Agen Distribusi halaman, pilih lokasi agen:
- Berlangganan pushPilih “Jalankan semua agen di Distributor” – Distributor akan mengirimkan perubahan ke pelanggan.
- Tarik langgananPilih “Jalankan setiap agen di Pelanggannya” – setiap pelanggan akan menarik perubahan dari Distributor.
pada Pelanggan halaman, pilih server pelanggan yang sudah ada atau klik Tambahkan Subscriber untuk menambahkan yang baru.
Untuk setiap pelanggan, pilih basis data tujuan atau buat basis data baru. Catatan: Basis data langganan harus berbeda dari basis data penerbit, meskipun menggunakan hal yang sama. SQL Server contoh.
pada Keamanan Agen Distribusi Pada halaman tersebut, klik tombol properti untuk setiap langganan guna mengkonfigurasi konteks keamanan.
pada Jadwal Sinkronisasi Pada halaman tersebut, pilih sinkronisasi berkelanjutan atau sinkronisasi terjadwal.
pada Inisialisasi Langganan halaman, pilih Segera untuk menginisialisasi selama penyelesaian wizard atau Pada sinkronisasi pertama.
Tinjau tindakan wizard dan klik Finish.

5. Pemantauan dan Pengelolaan SQL Server sahutan

5.1 Memantau Replikasi dengan Replication Monitor

Untuk menjalankan Replication Monitor:

In SQL Server Studio Manajemen, perluas sahutan di Object Explorer.
Klik kanan sahutan dan pilih Luncurkan Monitor Replikasi.
Jika belum ada penerbit yang terdaftar, klik Tambahkan Penerbit di sebelah kiri.
Pilih Add SQL Server Publisher dan terhubung ke server penerbit.
Penerbit muncul di panel sebelah kiri dengan node yang dapat diperluas untuk publikasi dan langganan.

5.2 Pemantauan Kinerja

5.2.1 Memantau Latensi

Latensi replikasi adalah penundaan waktu antara perubahan yang terjadi di penerbit dan perubahan tersebut diterapkan di pelanggan. Pantau latensi untuk memastikan kesegaran data memenuhi persyaratan bisnis.

Gunakan Replication Monitor untuk melihat metrik latensi pada tab Semua Langganan. Kolom Latensi menunjukkan latensi rata-rata dalam detik. Untuk replikasi transaksional, token pelacak memberikan pengukuran latensi yang tepat dengan menyisipkan transaksi penanda yang dilacak melalui pipeline replikasi.

Untuk menggunakan token pelacak:

Di Replication Monitor, pilih publikasi transaksional.
klik Token Pelacak Tab.
Klik Sisipkan Pelacak untuk menyuntikkan transaksi penanda.
Pantau pergerakan token saat berpindah dari penerbit ke distributor hingga ke pelanggan.
Lihat waktu yang dibutuhkan untuk setiap segmen untuk mengidentifikasi hambatan.

5.2.2 Memantau Throughput

Throughput mengukur volume data yang direplikasi dari waktu ke waktu, biasanya dinyatakan sebagai transaksi per detik atau perintah per detik. Pantau throughput untuk memastikan replikasi dapat mengimbangi aktivitas penerbit.

Meskipun Replication Monitor menyediakan status sinkronisasi dasar, tingkat pengiriman dan metrik throughput terperinci tidak terlihat di GUI. Gunakan kueri T-SQL terhadap basis data distribusi untuk memantau throughput:

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

Kode status: 1 = Start, 2 = Sedang berlangsung, 3 = Berhasil, 4 = Menganggur, 5 = Coba lagi, 6 = Gagal. Bandingkan tingkat pengiriman dengan tingkat transaksi penerbit untuk mengidentifikasi situasi di mana replikasi tertinggal. Penghitung kinerja di Monitor Kinerja Windows menyediakan metrik throughput tambahan untuk setiap agen replikasi.

5.2.3 Mengidentifikasi Hambatan

Kemacetan replikasi dapat terjadi di beberapa titik dalam topologi. Pada penerbit, waktu pembuatan snapshot yang berlebihan atau penundaan Agen Pembaca Log dapat mengindikasikan keterbatasan sumber daya. Pantau CPU, memori, dan I/O disk pada penerbit selama aktivitas replikasi.

Di distributor, periksa akumulasi transaksi dalam basis data distribusi. Sejumlah besar perintah yang belum didistribusikan menunjukkan bahwa distributor tidak dapat mengimbangi pengiriman. Pantau sumber daya server distributor dan pertimbangkan untuk menggunakan distributor jarak jauh khusus untuk skenario volume tinggi.

Di sisi pelanggan, lambatnya penerapan perubahan dapat disebabkan oleh sumber daya yang tidak memadai, indeks yang hilang, atau kendala yang memperlambat operasi penyisipan. Pantau pemanfaatan sumber daya pelanggan dan kinerja kueri saat Distribution Agent berjalan. Keterbatasan bandwidth jaringan antar komponen juga menyebabkan hambatan, terutama untuk volume data yang besar.

5.3 Mengelola Agen Replikasi

5.3.1 StarAgen t dan Stop

Untuk staratau menghentikan agen replikasi:

In SQL Server Studio Manajemen, perluas SQL Server Agen -> Jobs.
Cari tugas agen replikasi (nama biasanya mencakup informasi publikasi dan pelanggan).
Klik kanan pada pekerjaan tersebut dan pilih StarPekerjaan t or Berhenti Kerja.

5.3.2 Mengkonfigurasi Profil Agen

Profil agen berisi kumpulan parameter yang mengontrol perilaku agen. SQL Server menyediakan profil default yang dioptimalkan untuk skenario umum, dan Anda dapat membuat profil khusus untuk kebutuhan spesifik.

Untuk memodifikasi profil agen:

Di Object Explorer, perluas sahutan.
Klik kanan sahutan dan pilih Properti Distributor.
klik Pengaturan Profil Default .
Pilih jenis agen (Snapshot, Pembaca Log, Distribusi, atau Penggabungan) dari menu tarik-turun.
Pilih profil dan klik Properties untuk melihat nilai parameter.
Klik Profil Baru untuk membuat profil khusus berdasarkan profil yang sudah ada.
Ubah parameter sesuai kebutuhan dan klik. OK.

Terapkan profil ke agen dengan mengedit properti langganan dan memilih profil yang diinginkan dari menu tarik-turun Profil agen.

5.3.3 Parameter dan Pengaturan Agen

Parameter agen menyempurnakan kinerja dan perilaku. Parameter kunci untuk Agen Distribusi meliputi CommitBatchSize (jumlah transaksi yang diterapkan per commit), CommitBatchThreshold (jumlah perintah sebelum commit), SubscriptionStreams (koneksi paralel untuk pengiriman yang lebih cepat), dan QueryTimeout (batas waktu untuk perintah).

Untuk Log Reader Agent, parameter penting meliputi ReadBatchSize (transaksi yang dibaca per pemindaian), ReadBatchThreshold (perintah sebelum pengiriman), dan PollingInterval (penundaan antara pemindaian log). Sesuaikan parameter ini berdasarkan volume transaksi dan persyaratan latensi.

5.4 Pertimbangan Pencadangan dan Pemulihan

Melakukan pencadangan basis data yang terlibat dalam replikasi memerlukan pertimbangan khusus. Untuk basis data penerbit, pencadangan penuh dan log transaksi secara berkala sangat penting. Tandai pencadangan basis data untuk dukungan replikasi dengan menggunakan opsi WITH REPLICATION saat mencadangkan basis data dalam replikasi transaksional. Cadangkan basis data distribusi secara berkala untuk melindungi konfigurasi replikasi.

Saat memulihkan basis data penerbit ke server yang sama dengan nama yang sama, gunakan opsi WITH KEEP_REPLICATION untuk mempertahankan status replikasi. Opsi ini memastikan bahwa transaksi yang belum diproses oleh Agen Pembaca Log tetap ditandai untuk replikasi, memungkinkan replikasi berlanjut secara otomatis tanpa menginisialisasi ulang langganan.

Dalam skenario pemulihan bencana di mana cadangan tidak tersedia, rusak, atau file basis data mengalami kerusakan, alat pemulihan khusus mungkin diperlukan. DataNumen SQL Recovery Dapat mengekstrak data dari file MDF dan NDF yang rusak atau tidak dapat diakses, memberikan opsi terakhir ketika prosedur pemulihan standar gagal.

Untuk detail lebih lanjut tentang SQL Server cadangan, lihat kami panduan komprehensif.

6. Pertanyaan yang Sering Diajukan (FAQ)

T: Apa perbedaan antara replikasi snapshot dan replikasi transaksional?

A: Replikasi snapshot mengambil salinan lengkap data pada titik waktu tertentu dan menerapkannya ke pelanggan, cocok untuk data yang jarang berubah. Replikasi transaksional...tarts mengambil snapshot awal dan kemudian terus mereplikasi transaksi individual saat terjadi, sehingga memberikan sinkronisasi mendekati waktu nyata untuk data yang sering berubah.

T: Bisakah saya mereplikasi antara yang berbeda? SQL Server versi?

A: Ya, SQL Server Replikasi mendukung kompatibilitas versi dalam rentang terbatas. Versi distributor harus sama dengan atau lebih tinggi dari versi penerbit, dan pelanggan dapat berada dalam rentang dua versi dari penerbit. Misalnya, jika penerbit adalah SQL Server 2016, pelanggan dapat menjadi SQL Server Tahun 2012, 2014, 2016, 2017, atau 2019.

T: Bagaimana cara menangani konflik dalam replikasi penggabungan (merge replication)?

A: Replikasi penggabungan menyediakan mekanisme deteksi dan penyelesaian konflik bawaan. Anda dapat mengkonfigurasi penyelesai konflik pada tingkat artikel, memilih dari penyelesai bawaan atau mengimplementasikan penyelesai konflik khusus. Konflik biasanya diselesaikan menggunakan metode berbasis prioritas atau berbasis stempel waktu, dengan opsi untuk mencatat konflik untuk tinjauan manual.

T: Apa dampak replikasi terhadap kinerja?

A: Replikasi memengaruhi kinerja dalam beberapa cara: penerbit mengalami beban tambahan dari pelacakan perubahan dan pembuatan snapshot, distributor menggunakan sumber daya untuk menyimpan dan meneruskan transaksi, dan bandwidth jaringan dikonsumsi selama transfer data. Dampaknya bervariasi tergantung jenis replikasi, dengan replikasi snapshot menyebabkan lonjakan dampak tinggi secara berkala dan replikasi transaksional mempertahankan beban yang lebih konsisten tetapi berkelanjutan.

T: Bagaimana cara mengamankan topologi replikasi saya?

A: Amankan topologi replikasi Anda dengan menerapkan beberapa praktik terbaik: gunakan Otentikasi Windows atau keamanan yang kuat. SQL Server otentikasi, enkripsi koneksi menggunakan TLS, amankan folder snapshot dengan cara yang sesuai. NTFS Atur izin, konfigurasikan Publication Access List (PAL) untuk mengontrol akses, gunakan akun layanan terpisah dengan izin minimal yang diperlukan untuk setiap agen replikasi, dan audit pengaturan keamanan replikasi secara berkala.

T: Bisakah saya mereplikasi ke Azure SQL Database?

A: Ya, Anda dapat melakukan replikasi ke Azure SQL Database menggunakan replikasi transaksional dengan basis data lokal. SQL Server atau Azure SQL Managed Instance sebagai penerbit dan distributor. Azure SQL Database dapat berfungsi sebagai pelanggan tetapi tidak sebagai penerbit atau distributor. Replikasi gabungan dan replikasi peer-to-peer tidak didukung dengan Azure SQL Database.

T: Bagaimana cara memantau keterlambatan replikasi?

A: Pantau keterlambatan replikasi menggunakan Replication Monitor di SQL Server Management Studio, yang menampilkan metrik latensi untuk setiap langganan. Anda juga dapat menanyakan tabel basis data distribusi seperti MSdistribution_history dan MSrepl_commands, menggunakan penghitung kinerja khusus untuk agen replikasi, atau menyiapkan peringatan berdasarkan ambang batas latensi untuk secara proaktif mendeteksi dan mengatasi penundaan sinkronisasi.

T: Apa yang terjadi ketika pelanggan sedang offline?

A: Saat pelanggan sedang offline, perilakunya bergantung pada jenis replikasi. Untuk replikasi transaksional, transaksi terakumulasi dalam basis data distribusi hingga pelanggan kembali online, kemudian sinkronisasi dilanjutkan. Untuk replikasi penggabungan (merge replication), perubahan dilacak di kedua sisi dan digabungkan saat konektivitas dipulihkan. Pengaturan periode retensi menentukan berapa lama data disimpan sebelum harus diinisialisasi ulang.

T: Bagaimana cara menambahkan artikel baru ke publikasi yang sudah ada?

A: Untuk menambahkan artikel baru ke publikasi yang sudah ada, gunakan SQL Server Gunakan Management Studio untuk memodifikasi properti publikasi dan memilih objek tambahan, atau gunakan stored procedure sp_addarticle. Setelah menambahkan artikel, buat snapshot baru dan inisialisasi ulang semua langganan untuk memastikan pelanggan menerima artikel baru. Beberapa perubahan mungkin memerlukan inisialisasi ulang langganan tergantung pada pengaturan publikasi.

T: Bagaimana cara menghapus replikasi dari basis data?

A: Hapus replikasi dari basis data dengan terlebih dahulu menghapus semua langganan menggunakan sp_dropsubscription, kemudian menghapus publikasi dengan sp_droppublication, dan terakhir menonaktifkan penerbitan pada basis data menggunakan sp_replicationdboption. Jika server adalah distributor, nonaktifkan distribusi menggunakan sp_dropdistributor. Selalu cadangkan basis data sebelum menghapus konfigurasi replikasi.

T: Apa perbedaan antara SQL Server Replikasi dan AlwaysOn Availability Groups?

A: Replikasi adalah solusi distribusi dan integrasi data yang beroperasi pada tingkat objek, sedangkan Grup Ketersediaan Selalu Aktif adalah solusi ketersediaan tinggi dan pemulihan bencana yang beroperasi pada tingkat basis data.

7. Kesimpulan

SQL Server Replikasi menyediakan kerangka kerja yang kuat untuk mendistribusikan dan menyinkronkan data di berbagai basis data dan lokasi. Teknologi ini mendukung berbagai skenario melalui berbagai jenis replikasi.

Memilih strategi replikasi yang tepat bergantung pada kebutuhan spesifik Anda. Pertimbangkan frekuensi perubahan data, persyaratan latensi, apakah pelanggan perlu melakukan pembaruan, karakteristik jaringan, dan kebutuhan otonomi pelanggan. Replikasi snapshot paling cocok untuk data referensi yang jarang berubah di mana latensi tidak kritis. Replikasi transaksional cocok untuk skenario volume tinggi yang membutuhkan latensi rendah dan aliran data satu arah.

Pilih replikasi gabungan (merge replication) ketika pelanggan membutuhkan operasi otonom dengan kemampuan offline dan sinkronisasi dua arah. Terapkan replikasi peer-to-peer untuk penyeimbangan beban operasi baca di beberapa node aktif dengan konsistensi mendekati waktu nyata. Pertimbangkan pendekatan hibrida yang menggabungkan beberapa jenis replikasi untuk skenario kompleks dengan beragam persyaratan.

Referensi

tentang Penulis

Yuan Sheng adalah administrator basis data senior (DBA) dengan lebih dari 10 tahun pengalaman di SQL Server lingkungan dan manajemen basis data perusahaan. Ia telah berhasil menyelesaikan ratusan skenario pemulihan basis data di berbagai organisasi jasa keuangan, layanan kesehatan, dan manufaktur.

Yuan mengkhususkan diri dalam SQL Server Pemulihan basis data, solusi ketersediaan tinggi, dan optimasi kinerja. Pengalaman langsungnya yang luas mencakup pengelolaan basis data multi-terabyte, penerapan Always On Availability Group, dan pengembangan strategi pencadangan dan pemulihan otomatis untuk sistem bisnis yang sangat penting.

Melalui keahlian teknis dan pendekatan praktisnya, Yuan berfokus pada pembuatan panduan komprehensif yang membantu administrator basis data dan profesional TI memecahkan masalah kompleks SQL Server tantangan secara efisien. Dia selalu mengikuti perkembangan terbaru SQL Server rilis dan teknologi basis data Microsoft yang terus berkembang, secara berkala menguji skenario pemulihan untuk memastikan rekomendasinya mencerminkan praktik terbaik di dunia nyata.

Memiliki pertanyaan tentang SQL Server pemulihan atau butuh panduan pemecahan masalah basis data tambahan? Yuan menyambut masukan dan saran untuk meningkatkan sumber daya teknis ini.