Replikasi transaksional dengan Azure SQL Managed Instance

  • Artikel

Berlaku untuk:Azure SQL Managed Instance

Replikasi transaksional adalah fitur Azure SQL Managed Instance dan SQL Server yang memungkinkan Anda mereplikasi data dari tabel di Azure SQL Managed Instance atau instans SQL Server, ke tabel yang ditempatkan di database jarak jauh. Fitur ini memungkinkan Anda menyinkronkan beberapa tabel dalam database yang berbeda.

Gambaran Umum

Anda dapat menggunakan replikasi transaksional untuk mendorong perubahan yang dilakukan dalam instans terkelola Azure SQL ke:

  • Database SQL Server (lokal atau di Azure Virtual Machine)
  • Database di Microsoft Azure SQL Database
  • Database instans di Azure SQL Managed Instance

Catatan

Untuk menggunakan semua fitur Azure SQL Managed Instance, Anda harus menggunakan versi terbaru SQL Server Management Studio (SSMS) dan SQL Server Data Tools (SSDT).

Komponen

Komponen utama dalam replikasi transaksional adalah Penerbit, Distributor, dan Pelanggan, seperti yang ditunjukkan pada gambar berikut:

Diagram of replication with Azure SQL.

Peran Azure SQL Database Instans Terkelola Azure SQL
Penerbit Tidak Ya
Distributor Tidak Ya
Penarikan pelanggan Tidak Ya
Pendorongan pelanggan Ya Ya

Penerbit menerbitkan perubahan yang dibuat pada beberapa tabel (artikel) dengan mengirimkan pembaruan ke Distributor. Penerbit dapat menjadi instans terkelola Azure SQL atau instans SQL Server.

Distributor mengumpulkan perubahan di dalam artikel dari Penerbit dan mendistribusikannya kepada Pelanggan. Distributor dapat berupa instans terkelola Azure SQL atau instans SQL Server (versi apa pun selama sama dengan atau lebih tinggi dari versi Publisher).

Pelanggan menerima perubahan yang dibuat di Penerbit. Instans SQL Server dan instans terkelola Azure SQL dapat berupa pelanggan pendorongan dan penarikan, meskipun langganan penarikan tidak didukung saat distributor adalah instans terkelola Azure SQL dan pelanggan tidak. Database di Microsoft Azure SQL Database hanya bisa menjadi pelanggan pendorongan.

Azure SQL Managed Instance dapat mendukung menjadi Pelanggan dari versi Microsoft SQL Server berikut ini:

Catatan

Untuk versi SQL Server lain yang tidak mendukung penerbitan ke objek di Azure, Anda dapat menggunakan metode penerbitan ulang data untuk memindahkan data ke versi SQL Server yang lebih baru.

Mencoba mengonfigurasi replikasi menggunakan versi yang lebih lama dapat mengakibatkan kesalahan MSSQL_REPL20084 (Proses tidak dapat tersambung ke Pelanggan), dan MSSQL_REPL40532 (Tidak dapat membuka nama> server <yang diminta oleh login. Proses masuk gagal).

Jenis Replikasi

Ada berbagai jenis replikasi:

Replikasi Azure SQL Database Instans Terkelola Azure SQL
Transaksional standar Ya (hanya sebagai pelanggan) Ya
Snapshot Ya (hanya sebagai pelanggan) Ya
Penggabungan replikasi Tidak Tidak
Peer-to-peer Tidak Tidak
Dua arah Tidak Ya
Langganan yang dapat diperbarui Tidak Tidak

Matriks dukungan

Matriks dukungan replikasi transaksional untuk Azure SQL Managed Instance sama dengan matriks dukungan replikasi transaksional untuk Microsoft SQL Server.

Penerbit Distributor Pelanggan
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016		 SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014		 SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012		 SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Waktu menggunakan

Replikasi transaksional berguna dalam skenario berikut:

  • Terbitkan perubahan yang dibuat dalam satu atau beberapa tabel dalam database dan distribusikan ke satu atau banyak database di instans SQL Server atau Azure SQL Database yang berlangganan untuk perubahan tersebut.
  • Pertahankan beberapa database terdistribusi dalam status tersinkronisasi.
  • Migrasikan database dari satu instans SQL Server atau Azure SQL Managed Instance ke database lain dengan terus menerbitkan perubahan.

Membandingkan Sinkronisasi Data dengan replikasi transaksional

Kategori Sinkronisasi Data Replikasi Transaksional
Kelebihan - Aktif-dukungan aktif
- Dua arah antara lokal dan Azure SQL Database		 - Latensi yang lebih rendah
- Konsistensi transaksional
- Gunakan kembali topologi yang ada setelah migrasi
Kerugian - Tidak ada konsistensi transaksional
- Dampak performa yang lebih tinggi		 - Tidak dapat menerbitkan dari Azure SQL Database
- Biaya pemeliharaan tinggi

Konfigurasi umum

Secara umum, penerbit dan distributor harus berada di cloud atau lokal. Konfigurasi berikut didukung:

Penerbit dengan Distributor lokal di Azure SQL Managed Instance

Single instance as Publisher and Distributor.

Penerbit dan distributor dikonfigurasi dalam satu instans terkelola SQL dan mendistribusikan perubahan ke instans terkelola SQL lainnya, SQL Database, atau instans SQL Server.

Penerbit dengan distributor jarak jauh pada Azure SQL Managed Instance

Dalam konfigurasi ini, satu instans terkelola SQL menerbitkan perubahan pada distributor yang ditempatkan pada instans terkelola SQL lain yang dapat melayani banyak instans terkelola SQL sumber dan mendistribusikan perubahan ke satu atau banyak target di Azure SQL Database, Azure SQL Managed Instance, atau SQL Server.

Separate instances for Publisher and Distributor.

Penerbit dan distributor dikonfigurasi di dua instans terkelola. Ada beberapa batasan mengenai konfigurasi ini:

  • Kedua instans terkelola berada di vNet yang sama.
  • Kedua instans terkelola berada di lokasi yang sama.

Penerbit/Distributor lokal dengan pelanggan jarak jauh

Azure SQL Database as subscriber.

Dalam konfigurasi ini, database di Azure SQL Database atau Azure SQL Managed Instance adalah pelanggan. Konfigurasi ini mendukung migrasi dari lokal ke Azure. Jika pelanggan adalah database di Azure SQL Database, maka harus dalam mode push.

Persyaratan

  • Gunakan Autentikasi SQL untuk konektivitas antara peserta replikasi.
  • Gunakan berbagi Akun Microsoft Azure Storage untuk direktori kerja yang digunakan oleh replikasi.
  • Buka port keluar TCP 445 di aturan keamanan subnet untuk mengakses berbagi file Azure.
  • Buka port keluar TCP 1433 saat instans terkelola SQL adalah Penerbit/Distributor, dan Pelanggan tidak. Anda mungkin juga perlu mengubah aturan keamanan keluar NSG instans terkelola SQL untuk allow_linkedserver_outbound tag Port 1433 Destination Service dari virtualnetwork ke internet.
  • Tempatkan penerbit dan distributor di cloud, atau di lokal.
  • Konfigurasikan peering VPN antara jaringan virtual peserta replikasi jika jaringan virtualnya berbeda.

Catatan

Anda mungkin mengalami kesalahan 53 saat menyambungkan ke File Microsoft Azure Storage jika port kelompok keamanan jaringan (NSG) keluar 445 diblokir ketika distributornya adalah database Azure SQL Managed Instance dan pelanggannya berada di lokal. Perbarui vNet NSG untuk mengatasi masalah ini.

Pembatasan

Replikasi transaksional memiliki beberapa batasan yang khusus untuk Azure SQL Managed Instance. Pelajari selengkapnya tentang batasan ini di bagian ini.

File rekam jepret tidak dihapus dari Akun Azure Storage

Azure SQL Managed Instance menggunakan Akun Azure Storage yang dikonfigurasi pengguna untuk file rekam jepret yang digunakan untuk replikasi transaksional. Tidak seperti SQL Server di lingkungan lokal, Azure SQL Managed Instance tidak menghapus file rekam jepret dari Akun Azure Storage. Setelah file tidak lagi diperlukan, Anda harus menghapusnya. Ini dapat dilakukan melalui antarmuka Azure Storage di portal Azure, Microsoft Azure Storage Explorer, atau melalui klien baris perintah (Azure PowerShell atau CLI) atau Azure Storage Management REST API.

Berikut adalah contoh cara menghapus file dan cara menghapus folder kosong.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Jumlah agen distribusi yang berjalan terus menerus

Jumlah agen distribusi yang dikonfigurasi untuk berjalan terus menerus dibatasi hingga 30 pada Azure SQL Managed Instance. Untuk memiliki lebih banyak agen distribusi, mereka harus berjalan sesuai permintaan atau dengan jadwal yang ditentukan. Jadwal dapat didefinisikan dengan frekuensi harian dan kemunculan pada setiap 10 detik (atau lebih), jadi meskipun tidak berkelanjutan, Anda masih dapat memiliki distributor yang memperkenalkan latensi yang hanya beberapa detik. Ketika sejumlah besar distributor diperlukan, disarankan untuk menggunakan konfigurasi terjadwal dan bukan berkelanjutan.

Dengan grup failover

Menggunakan replikasi transaksional dengan instans yang berada dalam grup failover didukung. Namun, jika Anda mengonfigurasi replikasi sebelum menambahkan instans terkelola SQL Anda ke dalam grup failover, replikasi berhenti sementara saat Anda mulai membuat grup failover, dan monitor replikasi menunjukkan status Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikasi dilanjutkan setelah grup failover berhasil dibuat.

Jika penerbit atau distributor instans terkelola SQL berada dalam grup failover, administrator instans terkelola SQL harus membersihkan semua publikasi pada primer lama dan mengonfigurasi ulang pada primer baru setelah failover terjadi. Aktivitas berikut diperlukan dalam skenario ini:

  1. Hentikan semua pekerjaan replikasi yang berjalan di database, jika ada.

  2. Hilangkan metadata langganan dari penerbit dengan menjalankan skrip berikut pada database penerbit. Ganti nilai <name of publication> dan <name of subscriber> :

    EXEC sp_dropsubscription @publication = '<name of publication>',
    @article = 'all',
    @subscriber = '<name of subscriber>'

  3. Hilangkan metadata langganan dari pelanggan. Jalankan skrip berikut pada database langganan pada instans terkelola SQL pelanggan. <full DNS of publisher> Ganti nilai. Misalnya, example.ac2d23028af5.database.windows.net:

    EXEC sp_subscription_cleanup
   @publisher = N'<full DNS of publisher>',
   @publisher_db = N'<publisher database>',
   @publication = N'<name of publication>';

  4. Lepaskan semua objek replikasi secara paksa dari penerbit dengan menjalankan skrip berikut di database yang diterbitkan:

    EXEC sp_removedbreplication;

  5. Hilangkan distributor lama dengan paksa dari instans terkelola SQL utama asli (jika failback ke primer lama yang digunakan untuk memiliki distributor). Jalankan skrip berikut pada master database di instans terkelola SQL distributor lama:

    EXEC sp_dropdistributor 1, 1;

Jika instans terkelola SQL pelanggan berada dalam grup failover, publikasi harus dikonfigurasi untuk terhubung ke titik akhir pendengar grup failover untuk instans terkelola SQL pelanggan. Jika terjadi failover, tindakan berikutnya oleh administrator instans terkelola SQL bergantung pada jenis failover yang terjadi:

  • Untuk failover tanpa kehilangan data, replikasi akan terus berfungsi setelah failover.
  • Untuk failover dengan kehilangan data, replikasi juga berfungsi. Ini mereplikasi perubahan yang hilang lagi.
  • Untuk failover dengan kehilangan data, tetapi kehilangan data berada di luar periode retensi database distribusi, administrator instans terkelola SQL perlu menginisialisasi ulang database langganan.

Pemecahan Masalah Umum

Log transaksi dan Replikasi Transaksional

Dalam keadaan biasa, log transkasi digunakan untuk merekam perubahan data dalam database. Perubahan dicatat dalam log transaksi, dan itu membuat konsumsi penyimpanan log tumbuh. Ada juga proses otomatis yang memungkinkan pemotongan log transaksi yang aman, dan proses ini mengurangi ruang penyimpanan yang digunakan untuk log. Saat penerbitan untuk Replikasi Transaksional dikonfigurasi, pemotongan log transaksi dicegah hingga perubahan dalam log diproses oleh pekerjaan pembaca log. Dalam beberapa keadaan, pemrosesan log transaksi diblokir secara efektif, dan status tersebut dapat menyebabkan pengisian seluruh penyimpanan yang dicadangkan untuk log transaksi. Ketika tidak ada ruang kosong untuk log transaksi, dan tidak ada lagi ruang bagi log transaksi untuk tumbuh, kami memiliki log transaksi penuh. Dalam status ini, database tidak dapat lagi memproses beban kerja tulis apa pun, dan secara efektif menjadi database baca-saja.

Agen pembaca log yang dinonaktifkan

Terkadang publikasi Replikasi Transaksional dikonfigurasi untuk database, tetapi agen pembaca log tidak dikonfigurasi untuk dijalankan. Dalam hal ini, perubahan terakumulasi dalam log transaksi, dan tidak sedang diproses. Hal ini menyebabkan pertumbuhan konstan log transaksional, dan akhirnya ke log transkasi penuh. Pengguna harus memastikan bahwa pekerjaan pembaca log ada dan aktif. Alternatifnya adalah menonaktifkan Replikasi Transaksional, jika tidak diperlukan.

Batas waktu kueri agen pembaca log habis

Terkadang, pekerjaan pembaca log tidak dapat membuat kemajuan yang efektif karena batas waktu kueri berulang. Cara untuk memperbaiki batas waktu kueri adalah dengan meningkatkan pengaturan batas waktu kueri untuk pekerjaan agen pembaca log.

Meningkatkan batas waktu kueri untuk pekerjaan pembaca log dapat dilakukan dengan SSMS. Di penjelajah objek, di bawah SQL Server Agent, temukan pekerjaan yang ingin Anda ubah. Pertama hentikan, lalu buka propertinya. Temukan step 2 dan edit. Tambahkan nilai perintah dengan -QueryTimeout <timeout_in_seconds>. Untuk nilai batas waktu kueri coba 21600 atau yang lebih tinggi. Akhirnya, mulai pekerjaan lagi.

Ukuran penyimpanan log mencapai batas maksimum 2 TB

Ketika ukuran penyimpanan log transaksi mencapai batas maksimum, yaitu 2 TB, log secara fisik tidak dapat tumbuh lebih dari itu. Dalam hal ini, satu-satunya mitigasi yang tersedia adalah menandai semua transaksi yang akan direplikasi sebagai diproses, untuk memungkinkan log transaksi terpotong. Ini secara efektif berarti bahwa sisa transaksi dalam log tidak akan direplikasi, dan Anda perlu menginisialisasi ulang replikasi.

Catatan

Setelah melakukan mitigasi, Anda harus menginisialisasi ulang replikasi, yang berarti mereplikasi seluruh himpunan data lagi. Ini adalah ukuran operasi data, dan mungkin berjalan lama, tergantung pada jumlah data yang harus direplikasi.

Untuk melakukan mitigasi, pertama-tama Anda perlu menghentikan agen pembaca log pada distributor. Kemudian Anda harus menjalankan prosedur tersimpan sp_repldone dengan reset bendera yang diatur ke 1 pada database penerbit, untuk memungkinkan pemotongan log transaksi. Perintah ini akan terlihat seperti ini EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1. Setelah ini, Anda harus menginisialisasi ulang replikasi.

Langkah berikutnya

Untuk mengetahui informasi selengkapnya tentang mengonfigurasi replikasi transaksional, lihat tutorial berikut:

Baca juga