Praktik Terbaik untuk Administrasi Replikasi

Berlaku untuk:SQL ServerAzure SQL Managed Instance

Setelah Anda mengonfigurasi replikasi, penting untuk memahami cara mengelola topologi replikasi. Topik ini memberikan panduan praktik terbaik dasar di sejumlah area dengan tautan ke informasi lebih lanjut untuk setiap area. Selain mengikuti panduan praktik terbaik yang disajikan dalam topik ini, pertimbangkan untuk membaca topik pertanyaan yang sering diajukan untuk mengenali diri Anda dengan pertanyaan dan masalah umum: Tanya Jawab Umum untuk Administrator Replikasi.

Hal ini berguna untuk membagi panduan praktik terbaik menjadi dua area:

• Informasi berikut mencakup praktik terbaik yang harus diterapkan untuk semua topologi replikasi:

  • Mengembangkan dan menguji strategi pencadangan dan pemulihan.

  • Skrip topologi replikasi.

  • Buat ambang batas dan pemberitahuan.

  • Pantau topologi replikasi.

  • Tetapkan garis besar performa dan setel replikasi jika perlu.

• Informasi berikut mencakup praktik terbaik yang harus dipertimbangkan, tetapi mungkin tidak diperlukan untuk topologi Anda:

  • Validasi data secara berkala.

  • Sesuaikan parameter agen melalui profil.

  • Sesuaikan periode retensi publikasi dan distribusi.

  • Pahami cara mengubah properti artikel dan publikasi jika persyaratan aplikasi berubah.

  • Pahami cara membuat perubahan skema jika persyaratan aplikasi berubah.

Mengembangkan dan menguji strategi pencadangan dan pemulihan

Semua database harus dicadangkan secara teratur, dan kemampuan untuk memulihkan cadangan tersebut harus diuji secara berkala; database yang direplikasi tidak berbeda. Database berikut harus dicadangkan secara teratur:

• Database publikasi

• Database distribusi

• Database langganan

• database msdb dan database master di Penerbit, Distributor, dan semua Pelanggan

Database yang direplikasi memerlukan perhatian khusus sehubungan dengan pencadangan dan pemulihan data. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database yang Direplikasi.

Membuat skrip topologi replikasi

Semua komponen replikasi dalam topologi harus ditulis sebagai bagian dari rencana pemulihan bencana, dan skrip juga dapat digunakan untuk mengotomatiskan tugas berulang. Skrip berisi prosedur tersimpan sistem Transact-SQL yang diperlukan untuk mengimplementasikan komponen replikasi yang diskrip, seperti publikasi atau langganan. Skrip dapat dibuat dalam wizard (seperti Wizard Publikasi Baru) atau di Microsoft SQL Server Management Studio setelah Anda membuat komponen. Anda dapat melihat, memodifikasi, dan menjalankan skrip menggunakan SQL Server Management Studio atau sqlcmd. Skrip dapat disimpan dengan file cadangan yang akan digunakan jika topologi replikasi harus dikonfigurasi ulang. Untuk informasi selengkapnya, lihat Replikasi Pembuatan Skrip.

Komponen harus diskrip ulang jika ada perubahan properti yang dibuat. Jika Anda menggunakan prosedur tersimpan kustom dengan replikasi transaksional, salinan setiap prosedur harus disimpan dengan skrip; salinan harus diperbarui jika prosedur berubah (prosedur biasanya diperbarui karena perubahan skema atau mengubah persyaratan aplikasi). Untuk informasi selengkapnya tentang prosedur kustom, lihat Menentukan Bagaimana Perubahan Disebarkan untuk Artikel Transaksional.

Menetapkan garis besar performa dan menyetel replikasi jika perlu

Sebelum replikasi dikonfigurasi, disarankan untuk membiasakan diri dengan faktor-faktor yang memengaruhi performa replikasi:

• Server dan perangkat keras jaringan

• Desain Database

• Konfigurasi distributor

• Desain dan opsi publikasi

• Memfilter desain dan penggunaan

• Opsi langganan

• Opsi rekam jepret

• Parameter agen

• Pemeliharaan

Setelah replikasi dikonfigurasi, disarankan untuk mengembangkan garis besar performa, yang akan memungkinkan Anda menentukan bagaimana replikasi berpura-pura dengan beban kerja yang khas untuk aplikasi dan topologi Anda. Gunakan Monitor Replikasi dan Monitor Sistem untuk menentukan angka umum untuk lima dimensi performa replikasi berikut:

• Latensi: jumlah waktu yang diperlukan agar perubahan data disebarluaskan di antara simpul dalam topologi replikasi.

• Throughput: jumlah aktivitas replikasi (diukur dalam perintah yang dikirimkan selama jangka waktu tertentu) yang dapat dipertahankan sistem dari waktu ke waktu.

• Konkurensi: jumlah proses replikasi yang dapat beroperasi pada sistem secara bersamaan.

• Durasi sinkronisasi: berapa lama waktu yang dibutuhkan sinkronisasi tertentu untuk diselesaikan.

• Konsumsi sumber daya: sumber daya perangkat keras dan jaringan yang digunakan sebagai hasil dari pemrosesan replikasi.

Latensi dan throughput paling relevan dengan replikasi transaksional, karena sistem yang dibangun di atas replikasi transaksional umumnya memerlukan latensi rendah dan throughput tinggi. Konkurensi dan durasi sinkronisasi paling relevan untuk menggabungkan replikasi, karena sistem yang dibangun di atas replikasi penggabungan sering memiliki sejumlah besar Pelanggan, dan Penerbit dapat memiliki sejumlah besar sinkronisasi bersamaan dengan Pelanggan ini.

Setelah Anda menetapkan nomor dasar, atur ambang batas di Monitor Replikasi. Untuk informasi selengkapnya, lihat Mengatur Ambang batas dan Peringatan di Monitor Replikasi dan Menggunakan Pemberitahuan untuk Peristiwa Agen Replikasi. Jika Anda mengalami masalah performa, disarankan untuk membaca saran dalam meningkatkan topik performa yang tercantum di atas dan untuk menerapkan perubahan di area yang memengaruhi masalah yang Anda temui.

Membuat ambang batas dan pemberitahuan

Monitor Replikasi memungkinkan Anda mengatur sejumlah ambang yang terkait dengan status dan performa. Disarankan untuk mengatur ambang batas yang sesuai untuk topologi Anda; jika ambang tercapai, peringatan ditampilkan, dan, secara opsional, pemberitahuan dapat dikirim ke akun email, pager, atau perangkat lainnya. Untuk informasi selengkapnya, lihat Mengatur Ambang batas dan Peringatan di Monitor Replikasi.

Selain pemberitahuan yang dapat dikaitkan dengan ambang pemantauan, replikasi menyediakan sejumlah pemberitahuan yang telah ditentukan sebelumnya yang merespons tindakan agen replikasi. Pemberitahuan ini dapat digunakan oleh administrator untuk tetap mendapatkan informasi tentang status topologi replikasi. Disarankan untuk membaca topik yang menjelaskan pemberitahuan dan menggunakan apa pun yang sesuai dengan kebutuhan administrasi Anda (dimungkinkan juga untuk membuat pemberitahuan tambahan jika perlu). Untuk informasi selengkapnya, lihat Menggunakan Pemberitahuan untuk Peristiwa Agen Replikasi.

Memantau topologi replikasi

Setelah topologi replikasi diberlakukan dan ambang batas dan pemberitahuan telah dikonfigurasi, disarankan untuk memantau replikasi secara teratur. Memantau topologi replikasi adalah aspek penting dalam menyebarkan replikasi. Karena aktivitas replikasi didistribusikan, penting untuk melacak aktivitas dan status di semua komputer yang terlibat dalam replikasi. Alat berikut dapat digunakan untuk memantau replikasi:

• Monitor Replikasi adalah alat terpenting untuk memantau replikasi, memungkinkan Anda memantau kesehatan keseluruhan topologi replikasi. Untuk informasi selengkapnya, lihat Memantau Replikasi.

• Objek Manajemen Transact-SQL dan Replikasi (RMO) menyediakan antarmuka untuk memantau replikasi. Untuk informasi selengkapnya, lihat Memantau Replikasi.

• Monitor Sistem juga dapat berguna untuk memantau performa replikasi. Untuk informasi selengkapnya, lihat Memantau Replikasi dengan Monitor Sistem.

Memvalidasi data secara berkala

Validasi tidak diperlukan oleh replikasi, tetapi disarankan untuk menjalankan validasi secara berkala untuk replikasi transaksional dan replikasi penggabungan. Validasi memungkinkan Anda memverifikasi bahwa data di Pelanggan cocok dengan data di Publisher. Validasi yang berhasil menunjukkan bahwa pada saat itu semua perubahan dari Penerbit telah direplikasi ke Pelanggan (dan dari Pelanggan ke Penerbit jika pembaruan didukung pada Pelanggan) dan bahwa kedua database tersebut sinkron.

Disarankan agar validasi dilakukan sesuai dengan jadwal pencadangan database publikasi. Misalnya, jika database publikasi memiliki cadangan penuh sekali per minggu, validasi dapat dijalankan sekali per minggu setelah pencadangan selesai. Untuk informasi selengkapnya, lihat Memvalidasi Data yang Direplikasi.

Menggunakan profil agen untuk mengubah parameter agen jika perlu

Profil agen menyediakan metode yang nyaman untuk mengatur parameter agen replikasi. Parameter juga dapat ditentukan pada baris perintah agen, tetapi biasanya lebih tepat untuk menggunakan profil agen yang telah ditentukan sebelumnya atau untuk membuat profil baru jika Anda perlu mengubah nilai parameter. Misalnya, jika Anda menggunakan replikasi penggabungan dan Pelanggan berpindah dari koneksi broadband ke koneksi dialup, pertimbangkan untuk menggunakan profil tautan lambat untuk Agen Penggabungan; profil ini menggunakan sekumpulan parameter yang lebih cocok untuk tautan komunikasi yang lebih lambat. Untuk informasi selengkapnya, lihat Profil Agen Replikasi.

Menyesuaikan periode retensi publikasi dan distribusi jika perlu

Replikasi transaksional dan replikasi penggabungan menggunakan periode retensi untuk menentukan, masing-masing, berapa lama transaksi disimpan dalam database distribusi, dan seberapa sering langganan harus disinkronkan. Disarankan untuk menggunakan pengaturan default awalnya, tetapi untuk memantau topologi Anda untuk menentukan apakah pengaturan memerlukan penyesuaian. Misalnya, dalam kasus replikasi penggabungan, periode retensi publikasi (yang default menjadi 14 hari) menentukan berapa lama metadata disimpan dalam tabel sistem. Jika langganan selalu disinkronkan dalam waktu lima hari, pertimbangkan untuk menyesuaikan pengaturan ke angka yang lebih rendah, yang akan mengurangi metadata dan mungkin memberikan performa yang lebih baik. Untuk informasi selengkapnya, lihat Kedaluwarsa dan Pennonaktifkan langganan.

Memahami cara mengubah publikasi jika persyaratan aplikasi berubah

Setelah Anda membuat publikasi, mungkin perlu menambahkan atau menghilangkan artikel, atau mengubah properti publikasi dan artikel. Sebagian besar perubahan diizinkan setelah publikasi dibuat, tetapi dalam beberapa kasus, perlu untuk menghasilkan rekam jepret baru untuk publikasi dan/atau menginisialisasi ulang langganan ke publikasi. Untuk informasi selengkapnya, lihat Mengubah Publikasi dan Artikel Properti dan Menambahkan Artikel ke dan Menghapus Artikel dari Publikasi yang Ada.

Memahami cara membuat perubahan skema jika persyaratan aplikasi berubah

Dalam banyak kasus, perubahan skema diperlukan setelah aplikasi dalam produksi. Dalam topologi replikasi, perubahan ini sering kali harus disebarluaskan ke semua Pelanggan. Replikasi mendukung berbagai perubahan skema pada objek yang diterbitkan. Saat Anda membuat salah satu perubahan skema berikut pada objek yang diterbitkan yang sesuai di Penerbit Microsoft SQL Server, perubahan tersebut disebarluaskan secara default ke semua Pelanggan SQL Server:

• ALTER TABLE

• UBAH TAMPILAN

• ALTER PROCEDURE

• ALTER FUNCTION

• UBAH PEMICU

Untuk informasi selengkapnya, lihat Membuat Perubahan Skema pada Database Publikasi.

Lihat Juga

Tanya Jawab Umum Administrasi Replikasi