Bagikan melalui

Peer-to-Peer - Replikasi Transaksional

  • Artikel

Berlaku untuk: SQL Server

Replikasi peer-to-peer menyediakan solusi peer-out dan ketersediaan tinggi dengan mempertahankan salinan data di beberapa instans server, juga disebut sebagai simpul. Dibangun di atas dasar replikasi transaksional, replikasi peer-to-peer menyebarkan perubahan yang konsisten secara transaksional dalam waktu dekat secara real time. Ini memungkinkan aplikasi yang memerlukan peluasan skala operasi baca untuk mendistribusikan bacaan dari klien di beberapa simpul. Karena data dipertahankan di seluruh simpul dalam replikasi peer-to-peer yang hampir real-time menyediakan redundansi data, yang meningkatkan ketersediaan data.

Pertimbangkan aplikasi web. Ini dapat memperoleh manfaat dari replikasi peer-to-peer dengan cara berikut:

  • Kueri katalog dan bacaan lainnya tersebar di beberapa simpul. Ini memungkinkan performa tetap konsisten saat pembacaan meningkat.

  • Jika salah satu node dalam sistem gagal, lapisan aplikasi dapat mengalihkan penulisan untuk simpul tersebut ke simpul lain. Ini menjaga ketersediaan.

  • Jika simpul memerlukan pemeliharaan atau seluruh sistem memerlukan peningkatan, setiap simpul dapat diambil secara offline dan ditambahkan kembali ke sistem tanpa memengaruhi ketersediaan aplikasi.

Meskipun replikasi peer-to-peer memungkinkan penskalaan dari operasi baca, performa tulis untuk topologi seperti itu untuk satu simpul. Ini karena pada akhirnya semua sisipan, pembaruan, dan penghapusan disebarluaskan ke semua simpul. Replikasi mengenali kapan perubahan telah diterapkan pada simpul tertentu dan mencegah perubahan bersepeda melalui simpul lebih dari satu kali. Kami sangat menyarankan agar operasi tulis untuk setiap baris dilakukan hanya pada satu node, karena alasan berikut:

  • Jika baris dimodifikasi pada lebih dari satu simpul, baris dapat menyebabkan konflik atau bahkan pembaruan yang hilang saat baris disebarkan ke simpul lain.

  • Selalu ada beberapa latensi yang terlibat ketika perubahan direplikasi. Untuk aplikasi yang memerlukan perubahan terbaru untuk segera dilihat, penyeimbangan beban dinamis aplikasi di beberapa simpul dapat bermasalah.

Replikasi peer-to-peer menyertakan opsi untuk mengaktifkan deteksi konflik di seluruh topologi peer-to-peer. Opsi ini membantu mencegah masalah yang disebabkan dari konflik yang tidak terdeteksi, termasuk perilaku aplikasi yang tidak konsisten dan pembaruan yang hilang. Dengan mengaktifkan opsi ini, secara default perubahan yang bertentangan diperlakukan sebagai kesalahan penting yang menyebabkan kegagalan Agen Distribusi. Jika terjadi konflik, topologi tetap dalam keadaan tidak konsisten sampai konflik diselesaikan secara manual dan data dibuat konsisten di seluruh topologi. Untuk informasi selengkapnya, lihat Deteksi Konflik di Replikasi Peer-to-Peer.

Catatan

Untuk menghindari potensi inkonsistensi data, pastikan Anda menghindari konflik dalam topologi peer-to-peer, bahkan dengan deteksi konflik diaktifkan. Untuk memastikan bahwa operasi tulis untuk baris tertentu hanya dilakukan pada satu simpul, aplikasi yang mengakses dan mengubah data harus menyisipkan, memperbarui, dan menghapus operasi partisi. Pemartisian ini memastikan bahwa modifikasi pada baris tertentu yang berasal dari satu node disinkronkan dengan semua simpul lain dalam topologi sebelum baris dimodifikasi oleh node yang berbeda. Jika aplikasi memerlukan kemampuan deteksi dan resolusi konflik yang canggih, gunakan replikasi penggabungan. Untuk informasi selengkapnya, lihat Menggabungkan Replikasi dan Mendeteksi dan Mengatasi Konflik Replikasi Penggabungan.

Topologi Peer-to-Peer

Skenario berikut mengilustrasikan penggunaan umum untuk replikasi peer-to-peer.

Topologi yang Memiliki Dua Database yang Berpartisipasi

Replikasi peer-to-peer, dua simpul

Kedua ilustrasi sebelumnya menunjukkan dua database yang berpartisipasi, dengan lalu lintas pengguna diarahkan ke database melalui server aplikasi. Konfigurasi ini dapat digunakan untuk sejumlah aplikasi, dari situs Web hingga aplikasi grup kerja, dan memberikan manfaat berikut:

  • Peningkatan performa baca, karena bacaan tersebar di dua server.

  • Ketersediaan yang lebih tinggi jika pemeliharaan diperlukan atau kegagalan pada satu simpul.

Dalam kedua ilustrasi, aktivitas baca diseimbangkan beban antara database yang berpartisipasi, tetapi pembaruan ditangani secara berbeda:

  • Di sebelah kiri, pembaruan dipartisi di antara kedua server. Jika database berisi katalog produk, Anda dapat, misalnya, memiliki pembaruan langsung aplikasi kustom ke node A untuk nama produk yang dimulai dengan A hingga M, dan pembaruan langsung ke node B untuk nama produk yang dimulai dengan N hingga Z. Pembaruan kemudian direplikasi ke simpul lain.

  • Di sebelah kanan, semua pembaruan diarahkan ke node B. Dari sana, pembaruan direplikasi ke simpul A. Jika B offline (misalnya, untuk pemeliharaan), server aplikasi dapat mengarahkan semua aktivitas ke A. Ketika B kembali online, pembaruan dapat mengalir ke sana, dan server aplikasi dapat memindahkan semua pembaruan kembali ke B atau terus mengarahkannya ke A.

Replikasi peer-to-peer dapat mendukung salah satu pendekatan, tetapi contoh pembaruan pusat di sebelah kanan juga sering digunakan dengan replikasi transaksional standar.

Topologi yang Memiliki Tiga atau Lebih Database yang Berpartisipasi

Replikasi peer-to-peer ke lokasi yang tersebar

Ilustrasi sebelumnya menunjukkan tiga database yang berpartisipasi yang menyediakan data untuk organisasi dukungan perangkat lunak di seluruh dunia, dengan kantor di Los Angeles, London, dan Taipei. Teknisi dukungan di setiap kantor melakukan panggilan pelanggan dan memasukkan dan memperbarui informasi tentang setiap panggilan pelanggan. Zona waktu untuk tiga kantor terpisah delapan jam, jadi tidak ada tumpang tindih di hari kerja. Ketika kantor Taipei tutup, kantor London dibuka untuk hari itu. Jika panggilan masih berlangsung saat satu kantor ditutup, panggilan akan ditransfer ke perwakilan di kantor berikutnya untuk dibuka.

Setiap lokasi memiliki database dan server aplikasi, yang digunakan oleh teknisi dukungan saat mereka memasukkan dan memperbarui informasi tentang panggilan pelanggan. Topologi dipartisi berdasarkan waktu. Oleh karena itu, pembaruan hanya terjadi pada simpul yang saat ini terbuka untuk bisnis, dan kemudian pembaruan mengalir ke database lain yang berpartisipasi. Topologi ini memberikan manfaat berikut:

  • Independensi tanpa isolasi: Setiap kantor dapat menyisipkan, memperbarui, atau menghapus data secara independen tetapi juga dapat berbagi data karena direplikasi ke semua database lain yang berpartisipasi.

  • Ketersediaan yang lebih tinggi jika terjadi kegagalan atau untuk memungkinkan pemeliharaan pada satu atau beberapa database yang berpartisipasi.

    Replikasi peer-to-peer, tiga dan empat node

    Ilustrasi sebelumnya menunjukkan penambahan node ke topologi tiga node. Simpul dapat ditambahkan dalam skenario ini karena alasan berikut:

  • Karena kantor lain dibuka.

  • Untuk memberikan ketersediaan yang lebih tinggi untuk mendukung pemeliharaan atau meningkatkan toleransi kesalahan jika kegagalan disk, atau kegagalan besar lainnya terjadi.

Perhatikan bahwa dalam topologi tiga dan empat node, semua database menerbitkan dan berlangganan semua database lainnya. Ini memberikan ketersediaan maksimum jika ada kebutuhan pemeliharaan atau kegagalan satu atau beberapa simpul. Saat simpul ditambahkan, Anda harus menyeimbangkan ketersediaan dan kebutuhan skalabilitas terhadap performa dan kompleksitas penyebaran dan administrasi.

Mengonfigurasi Replikasi Peer-to-Peer

Mengonfigurasi topologi replikasi peer-to-peer mirip dengan mengonfigurasi serangkaian publikasi transaksional standar dan langganan. Langkah-langkah yang dijelaskan dalam artikel berikut menunjukkan konfigurasi sistem tiga node, mirip dengan konfigurasi yang ditampilkan di sebelah kiri dalam ilustrasi sebelumnya yang menunjukkan topologi peer-to-peer.

Pertimbangan untuk Menggunakan Replikasi Peer-to-Peer

Bagian ini menyediakan informasi dan panduan yang perlu dipertimbangkan saat Anda menggunakan replikasi peer-to-peer.

Pertimbangan Umum

  • Replikasi peer-to-peer hanya tersedia di SQL Server edisi perusahaan.

  • Semua database yang berpartisipasi dalam replikasi peer-to-peer harus berisi skema dan data yang identik:

    • Nama objek, skema objek, dan nama publikasi harus identik.

    • Publikasi harus mengizinkan perubahan skema direplikasi. (Ini adalah pengaturan 1 untuk properti publikasi replicate_ddl, yang merupakan pengaturan default.) Untuk informasi selengkapnya, lihat Membuat Perubahan Skema pada Database Publikasi.

    • Pemfilteran baris dan kolom tidak didukung.

  • Setiap simpul harus menggunakan database distribusinya sendiri. Ini menghilangkan potensi mengalami satu titik kegagalan.

  • Tabel dan objek lainnya tidak dapat disertakan dalam beberapa publikasi peer-to-peer dalam satu database publikasi.

  • Publikasi harus diaktifkan untuk replikasi peer-to-peer sebelum langganan dibuat.

  • Langganan harus diinisialisasi dengan menggunakan cadangan atau dengan replication support only opsi . Untuk informasi selengkapnya, lihat Menginisialisasi Langganan Transaksi tanpa Rekam Jepret.

  • Jangan gunakan kolom identitas. Saat menggunakan identitas, Anda harus mengelola rentang yang ditetapkan secara manual ke tabel di setiap database yang berpartisipasi. Untuk informasi selengkapnya, lihat Menetapkan rentang untuk manajemen rentang identitas manual.

Pembatasan Fitur

Replikasi peer-to-peer mendukung fitur inti replikasi transaksional, tetapi tidak mendukung opsi berikut:

  • Inisialisasi dan reinisialisasi dengan rekam jepret.

  • Filter baris dan kolom.

  • Kolom tanda waktu.

  • Penerbit dan Pelanggan Non-SQL Server.

  • Segera memperbarui dan mengantre memperbarui langganan.

  • Langganan anonim.

  • Langganan parsial.

  • Langganan yang dapat dilampirkan dan langganan yang dapat diubah. (Kedua opsi ini tidak digunakan lagi di SQL Server 2005 (9.x).)

  • Agen Distribusi Bersama.

  • Parameter Agen Distribusi -SubscriptionStreams dan parameter Agen Pembaca Log -MaxCmdsInTran.

  • Properti @destination_owner artikel dan @destination_table.

  • Replikasi transaksional Peer-to-Peer tidak mendukung pembuatan langganan transaksional satu arah ke publikasi Peer-to-Peer

  • Replikasi transaksional Peer-to-Peer tidak mendukung penerbitan tabel dengan kolom komputasi sebagai bagian dari kunci utamanya.

Properti berikut memiliki pertimbangan khusus:

  • Properti @allow_initialize_from_backup publikasi memerlukan nilai true.

  • Properti @replicate_ddl artikel memerlukan nilai true; @identityrangemanagementoption memerlukan nilai manual; dan @status mengharuskan opsi 24 diatur.

  • Nilai untuk properti @ins_cmdartikel , @del_cmd, dan @upd_cmd tidak dapat diatur ke SQL.

  • Properti @sync_type langganan memerlukan nilai tidak ada atau otomatis.

  • SQL Server 2019 (15.x) CU 13 memperkenalkan properti publikasi, @p2p_confictdetection_policy. Nilai parameter default adalah originatorid dan menyelesaikan konflik berdasarkan ID pendana. Nilai lastwriter parameter menyelesaikan konflik berdasarkan penulis terakhir.

Pertimbangan Pemeliharaan

Beberapa tindakan mengharuskan sistem berhenti. Ini berarti menghentikan aktivitas pada tabel yang diterbitkan di semua simpul dan memastikan bahwa setiap simpul telah menerima semua perubahan dari semua simpul lainnya.

Perbuatan Rekan SQL Server 2005 saja atau campuran rekan SQL Server 2005 dengan rekan SQL Server 2008 dan yang lebih tinggi Rekan SQL Server 2005 saja atau campuran rekan SQL Server 2005 dengan rekan SQL Server 2008 dan yang lebih tinggi SQL2008 rekan dan yang lebih tinggi SQL2008 rekan dan yang lebih tinggi
Menambahkan simpul ke topologi 2 simpul dalam topologi lengkap: Tidak perlu berhenti. Gunakan sync_type = 'initialize with backup'. Lebih dari 2 simpul: Diperlukan pengisian. sync_type = 'replication support only': Pengisian diperlukan. sync_type = 'initialize with backup' dan 'initialize from lsn': Tidak perlu berhenti.

Perubahan skema topologi (menambahkan atau menghilangkan artikel) memerlukan penghentian. Untuk informasi selengkapnya, lihat Mengelola Topologi Peer-to-Peer (Pemrograman Transact-SQL Replikasi).

Menghapus node dari topologi tidak pernah memerlukan pengisian.

Mengubah properti artikel dengan menggunakan sp_changearticle tidak pernah memerlukan pengisian. Perubahan yang diizinkan (untuk P2P) adalah descriptionproperti , , upd_cmdins_cmd, dan del_cmd .

Perubahan skema artikel (menambahkan/menjatuhkan kolom) tidak pernah memerlukan penghentian.

  • Menambahkan artikel: Untuk menambahkan artikel ke konfigurasi yang ada- kita perlu menghentikan sistem, menjalankan pernyataan CREATE TABLE & memuat data awal di setiap node dalam topologi dan menambahkan artikel baru di setiap simpul dalam topologi.

  • Menjatuhkan artikel: Jika kita ingin status yang konsisten pada semua node, kita perlu menghentikan topologi

Untuk informasi selengkapnya, lihat Menghentikan Topologi Replikasi (Pemrograman Transact-SQL Replikasi) dan Mengelola Topologi Peer-to-Peer (Pemrograman Transact-SQL Replikasi).

  • Jika Anda menambahkan simpul baru ke topologi peer-to-peer, Anda harus memulihkan hanya dari cadangan yang dibuat setelah simpul baru ditambahkan.

  • Anda tidak dapat menginisialisasi ulang langganan dalam topologi peer-to-peer. Jika Anda harus memastikan bahwa simpul memiliki salinan data baru, pulihkan cadangan di simpul.

Lihat Juga

Mengelola Topologi Peer-to-Peer (Pemrograman Transact-SQL Replikasi)
Strategi untuk Mencadangkan dan Memulihkan Rekam Jepret dan Replikasi Transaksional
Replikasi Transaksional