Praktik terbaik untuk administrasi replikasi

Berlaku untuk: SQL ServerAzure SQL Managed Instance

Setelah Anda mengonfigurasi replikasi, penting untuk memahami cara mengelola topologi replikasi. Artikel ini memberikan panduan praktik terbaik dasar di sejumlah bidang dengan tautan ke informasi lebih lanjut untuk setiap area. Selain mengikuti panduan praktik terbaik yang disajikan dalam artikel ini, pertimbangkan untuk membaca pertanyaan yang sering diajukan untuk mengenal pertanyaan dan masalah umum: Pertanyaan yang Sering Diajukan untuk Administrator Replikasi.

Bagi panduan praktik terbaik menjadi dua area:

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

    • Mengembangkan dan menguji strategi pencadangan dan pemulihan.

    • Tuliskan skrip untuk 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 sebaiknya Anda pertimbangkan, namun 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

Cadangkan semua database secara rutin, dan uji kemampuan untuk memulihkan cadangan tersebut secara berkala. Database replikasi tidak berbeda. Cadangkan database berikut secara berkala:

  • Basis data publikasi

  • Database distribusi

  • Basis data berlangganan

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

Basis data yang direplikasi memerlukan perhatian khusus saat mencadangkan dan memulihkan data. Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database yang Direplikasi.

Membuat skrip topologi replikasi

Skrip semua komponen replikasi dalam sebuah topologi sebagai bagian dari rencana pemulihan bencana. Anda juga dapat menggunakan skrip untuk mengotomatisasi tugas-tugas berulang. Sebuah skrip berisi prosedur tersimpan sistem Transact-SQL yang diperlukan untuk mengimplementasikan komponen replikasi, seperti publikasi atau langganan. Buat skrip di wizard (seperti New Publication Wizard) atau di SQL Server Management Studio setelah Anda membuat komponen. Anda dapat melihat, memodifikasi, dan menjalankan skrip menggunakan SQL Server Management Studio atau sqlcmd. Simpan skrip dengan file cadangan jika Anda perlu mengonfigurasi ulang topologi replikasi. Untuk informasi selengkapnya, lihat Pembuatan Skrip Replikasi.

Reskrip ulang komponen jika Anda melakukan perubahan properti. Jika Anda menggunakan prosedur tersimpan khusus dengan replikasi transaksional, simpan salinan setiap prosedur bersama skrip. Perbarui salinan jika prosedurnya berubah. Prosedur biasanya berubah karena perubahan skema atau kebutuhan aplikasi yang berubah. Untuk informasi selengkapnya tentang prosedur kustom, lihat Menentukan Bagaimana Perubahan Disebarkan untuk Artikel Transaksional.

Menetapkan garis besar performa dan menyetel replikasi jika perlu

Sebelum Anda mengonfigurasi replikasi, kenali faktor-faktor yang memengaruhi kinerja replikasi:

  • Server dan perangkat keras jaringan

  • Desain Database

  • Konfigurasi distributor

  • Desain dan opsi publikasi

  • Desain dan penggunaan filter

  • Opsi langganan

  • Opsi cuplikan

  • Parameter agen

  • Pemeliharaan

Setelah Anda mengonfigurasi replikasi, kembangkan baseline kinerja. Baseline ini membantu Anda memahami bagaimana replikasi berperilaku 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: waktu yang dibutuhkan perubahan data untuk menyebar antar node 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 replikasi penggabungan, karena sistem yang dibangun di atas replikasi penggabungan sering memiliki sejumlah besar Subscriber, dan Publisher dapat memiliki sejumlah besar sinkronisasi yang berlangsung bersamaan dengan Subscriber ini.

Setelah Anda menetapkan angka baseline, atur ambang batas di Replication Monitor. Untuk informasi selengkapnya, lihat Ambang Batas dan Peringatan di Monitor Replikasi dan Pemberitahuan untuk Peristiwa Agen Replikasi. Jika Anda mengalami masalah kinerja, tinjau saran dalam artikel peningkatan kinerja yang telah disebutkan sebelumnya. Terapkan perubahan di area yang memengaruhi masalah yang Anda hadapi.

Membuat ambang batas dan pemberitahuan

Replication Monitor memungkinkan Anda mengatur ambang batas terkait status dan kinerja. Tetapkan ambang batas yang sesuai untuk topologi Anda. Ketika ambang batas tercapai, peringatan akan ditampilkan, dan peringatan dapat dikirimkan secara opsional ke akun email, pager, atau perangkat lain. Untuk informasi selengkapnya, lihat Atur Ambang Batas dan Peringatan di Monitor Replikasi.

Selain peringatan yang dapat dikaitkan dengan ambang batas pemantauan, replikasi menyediakan peringatan yang telah ditentukan untuk merespons tindakan agen replikasi. Gunakan peringatan ini untuk tetap mendapatkan informasi tentang kondisi topologi replikasi. Tinjau artikel yang menjelaskan peringatan dan gunakan yang sesuai dengan kebutuhan administrasi Anda. Anda juga dapat membuat peringatan tambahan jika diperlukan. Untuk informasi lebih lanjut, lihat Menggunakan Alert untuk Peristiwa Agen Replikasi.

Memantau topologi replikasi

Setelah Anda membuat topologi replikasi dan mengonfigurasi ambang batas serta peringatan, pantau replikasi secara rutin. Memantau topologi replikasi adalah aspek penting dalam menyebarkan replikasi. Karena aktivitas replikasi terdistribusi, Anda harus melacak aktivitas dan status di semua komputer yang terlibat dalam replikasi. Gunakan alat berikut untuk memantau replikasi:

  • Replication Monitor adalah alat terpenting untuk memantau replikasi. Ini 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 Sistem Monitor.

Memvalidasi data secara berkala

Replikasi tidak memerlukan validasi, tetapi Anda harus menjalankan validasi secara berkala untuk replikasi transaksional dan replikasi penggabungan. Validasi memverifikasi bahwa data di Subscriber cocok dengan data di Publisher. Validasi yang berhasil menunjukkan bahwa pada titik tersebut semua perubahan dari Publisher direplikasi ke Subscriber (dan dari Subscriber ke Publisher jika pembaruan didukung di Subscriber) dan kedua database tersebut sinkronisasi.

Lakukan validasi sesuai jadwal backup database publikasi. Misalnya, jika database publikasi memiliki backup penuh sekali seminggu, jalankan validasi sekali seminggu setelah backup 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. Anda juga dapat menentukan parameter pada baris perintah agen, tetapi biasanya lebih tepat menggunakan profil agen yang telah ditentukan sebelumnya atau membuat profil baru jika Anda perlu mengubah nilai parameter. Misalnya, jika Anda menggunakan merge replication dan seorang Subscriber berpindah dari koneksi broadband ke koneksi dial-up, pertimbangkan menggunakan profil slow link untuk Merge Agent. Profil ini menggunakan seperangkat 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. Gunakan pengaturan default pada awalnya, tetapi pantau topologi Anda untuk menentukan apakah pengaturan perlu disesuaikan. Misalnya, dalam kasus replikasi penggabungan, periode retensi publikasi (yang default menjadi 14 hari) menentukan berapa lama metadata disimpan dalam tabel sistem. Jika langganan selalu sinkron dalam waktu lima hari, pertimbangkan untuk menyesuaikan pengaturannya ke angka yang lebih rendah. Perubahan ini mengurangi metadata dan mungkin memberikan kinerja yang lebih baik. Untuk informasi selengkapnya, lihat Kedaluwarsa dan Pennonaktifkan langganan.

Memahami cara mengubah publikasi jika persyaratan aplikasi berubah

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

Memahami cara membuat perubahan skema jika persyaratan aplikasi berubah

Dalam banyak kasus, Anda perlu melakukan perubahan skema setelah aplikasi dalam tahap produksi. Dalam topologi replikasi, Anda sering perlu menyebarkan perubahan ini ke semua Subscriber. Replikasi mendukung berbagai perubahan skema pada objek yang diterbitkan. Ketika Anda melakukan perubahan skema berikut pada objek yang dipublikasikan sesuai pada Microsoft SQL Server Publisher, perubahan tersebut secara default dipropagandakan ke semua Pelanggan SQL Server:

  • ALTER TABLE

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

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

Konten terkait

  • Last updated on