praktik terbaik tautan Managed Instance - Azure SQL Managed Instance

Aplikasi ke:Azure SQL Managed Instance

Artikel ini menguraikan praktik terbaik untuk menggunakan tautan Managed Instance untuk mereplikasi data antara Azure SQL Managed Instance dan instans SQL Server Anda yang dihosting di mana saja. Tautan ini menyediakan duplikasi data hampir real-time antara replika yang ditautkan.

Melakukan cadangan log secara teratur

Jika SQL Server adalah primer awal Anda, ambil cadangan log pertama pada SQL Server setelah penyemaian awal selesai, ketika database tidak lagi berada dalam status Restoring... pada Azure SQL Managed Instance. Lakukan pencadangan log transaksi SQL Server secara teratur untuk menjaga ukuran file log transaksi tetap terkontrol saat SQL Server dalam peran utama.

Fitur tautan mereplikasi data dengan menggunakan teknologi grup ketersediaan terdistribusi berdasarkan grup ketersediaan AlwaysOn. Replikasi data grup ketersediaan terdistribusi didasarkan pada replikasi catatan log transaksi. Instans SQL Server utama tidak dapat memotong catatan log transaksi apa pun dari database hingga direplikasi ke database pada replika sekunder. Jika masalah koneksi jaringan menyebabkan replikasi catatan log transaksi lambat atau diblokir, file log terus bertambah pada instans utama. Intensitas beban kerja dan kecepatan jaringan menentukan kecepatan pertumbuhan. Jika pemadaman koneksi jaringan berkepanjangan dan beban kerja pada instans utama berat, file log dapat mengambil semua ruang penyimpanan yang tersedia.

Mengambil cadangan log transaksi reguler memotong log transaksi dan meminimalkan risiko kehabisan ruang pada instans SQL Server utama karena pertumbuhan file log. Tidak ada tindakan tambahan yang diperlukan ketika SQL Managed Instance adalah yang utama karena cadangan log sudah diambil secara otomatis. Dengan mengambil cadangan log secara teratur pada SQL Server utama Anda, Anda membuat database Anda lebih tahan terhadap peristiwa pertumbuhan log yang tidak diencana. Pertimbangkan untuk menjadwalkan tugas pencadangan log harian dengan menggunakan pekerjaan SQL Server Agent.

Anda dapat menggunakan skrip Transact-SQL (T-SQL) untuk mencadangkan file log, seperti sampel yang disediakan di bagian ini. Ganti tempat penampung dalam skrip sampel dengan nama dari database Anda, nama dan jalur file cadangan, serta deskripsinya.

Untuk mencadangkan log transaksi Anda, gunakan contoh skrip Transact-SQL (T-SQL) berikut di SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Gunakan perintah Transact-SQL (T-SQL) berikut untuk memeriksa log berspasi yang digunakan oleh database Anda di SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

Output kueri terlihat seperti contoh berikut untuk database tpccsampel :

Cuplikan layar dengan hasil perintah yang memperlihatkan ukuran file log dan ruang yang digunakan

Dalam contoh ini, database telah menggunakan 76% dari log yang tersedia, dengan ukuran file log absolut sekitar 27 GB (27.971 MB). Ambang untuk tindakan bervariasi berdasarkan beban kerja Anda. Dalam contoh sebelumnya, ukuran log transaksi dan persentase penggunaan log biasanya menunjukkan bahwa Anda harus mengambil cadangan log transaksi untuk memotong file log dan membebaskan beberapa ruang, atau, Anda harus mengambil cadangan log yang lebih sering. Ini juga bisa menjadi indikasi bahwa pemotongan log transaksi sedang diblokir oleh transaksi terbuka. Untuk informasi lebih lanjut tentang pemecahan masalah log transaksi di SQL Server, silakan lihat Pemecahan Masalah Log Transaksi Penuh (Kesalahan SQL Server 9002). Untuk informasi selengkapnya tentang pemecahan masalah log transaksi di Azure SQL Managed Instance, lihat Troubleshoot transaction log errors with Azure SQL Managed Instance.

Catatan

Saat berpartisipasi dalam tautan, SQL Managed Instance melakukan pencadangan penuh dan log transaksi secara otomatis, terlepas dari apakah itu replika utama atau bukan. Pencadangan diferensial tidak dilakukan, yang dapat menyebabkan waktu pemulihan yang lebih lama.

Mencocokkan kapasitas performa antar replika

Saat Anda menggunakan fitur tautan, cocokkan kapasitas performa antara SQL Server dan SQL Managed Instance. Pencocokan ini membantu Anda menghindari masalah performa jika replika sekunder tidak dapat mengikuti replikasi dari replika utama, atau setelah failover. Kapasitas performa mencakup inti CPU (atau vCore dalam Azure), memori, dan throughput I/O.

Anda dapat memantau performa replikasi dengan memeriksa ukuran antrean pengulangan pada replika sekunder. Ukuran antrean redo menunjukkan jumlah rekaman log yang menunggu untuk diproses ulang pada replika sekunder. Ukuran antrean ulang yang konsisten tinggi menunjukkan bahwa replika sekunder tidak dapat mengimbangi replika utama. Anda dapat memeriksa ukuran antrean redo dengan cara berikut:

Jika ukuran antrean ulang secara konsisten tinggi, pertimbangkan untuk meningkatkan sumber daya pada replika sekunder.

Memantau jeda replikasi

Memantau lag replikasi membantu Anda menentukan kecepatan replika sekunder yang disinkronkan dengan replika utama. Perbedaan besar menunjukkan bahwa replika sekunder mengalami kesulitan mengikuti replika utama, yang biasanya disebabkan oleh throughput jaringan yang lambat dalam tautan antara dua instans, alokasi sumber daya yang tidak cocok antara kedua replika, atau oleh beban kerja yang terlalu tinggi pada replika utama.

Memantau lag replikasi sangat penting saat melakukan failover yang direncanakan, yang mengharuskan replika sekunder untuk sepenuhnya disinkronkan dengan replika utama sebelum failover dapat dijalankan. Jika lag replikasi tinggi, proses failover mungkin membutuhkan waktu lebih lama untuk diselesaikan, dan dalam beberapa kasus, mungkin bahkan gagal.

Gunakan kueri T-SQL berikut pada SQL Server dan SQL Managed Instance untuk memantau jeda replikasi antara replika:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Putar sertifikat

Anda mungkin perlu memutar sertifikat yang digunakan secara manual untuk mengamankan titik akhir pencerminan database pada SQL Server. Karena layanan mengelola dan secara otomatis memutar sertifikat yang digunakan untuk mengamankan titik akhir pencerminan database pada SQL Managed Instance, Anda tidak perlu memutarnya secara manual.

SQL Server

Sertifikat yang Anda gunakan untuk mengamankan titik akhir pencerminan database pada SQL Server dapat kedaluwarsa. Jika sertifikat kedaluwarsa, sertifikat dapat menyebabkan degradasi tautan. Untuk mencegah masalah ini, putar sertifikat sebelum kedaluwarsa.

Gunakan perintah Transact-SQL (T-SQL) berikut untuk memeriksa tanggal kedaluwarsa sertifikat saat ini:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Jika sertifikat Anda akan kedaluwarsa, atau telah kedaluwarsa, buat sertifikat baru, lalu ubah titik akhir yang ada untuk mengganti sertifikat saat ini.

Setelah mengonfigurasi titik akhir untuk menggunakan sertifikat baru, Anda dapat menghilangkan sertifikat yang kedaluwarsa.

SQL Managed Instance

Sertifikat titik akhir pencerminan database pada SQL Managed Instance secara otomatis diputar secara berkala. Anda tidak perlu memantau tanggal kedaluwarsa untuk sertifikat titik akhir pencerminan database pada SQL Managed Instance, selama Anda dapat validasi rantai sertifikat pada SQL Server berhasil.

Memvalidasi rantai sertifikat pada SQL Server

Catatan

Validasi rantai sertifikat secara berkala untuk tautan yang ada atau untuk memecahkan masalah dengan tautan yang terdegradasi. Jika Anda mengonfigurasi tautan baru atau baru-baru ini menyelesaikan langkah-langkah di bagian Dapatkan kunci umum sertifikat dari SQL Managed Instance dan mengimpornya ke SQL Server dan Mengimpor kunci otoritas sertifikat akar tepercaya Azure ke SQL Server, lewati bagian ini.

Masalah dengan rantai sertifikat dapat menurunkan tautan. Untuk mencegah masalah ini, memvalidasi rantai sertifikat secara teratur pada SQL Server.

Skenario berikut dapat menyebabkan masalah dengan rantai sertifikat pada SQL Server:

  • Rotasi sertifikat terjadwal pada SQL Managed Instance.
  • Perubahan yang tidak disengaja pada sertifikat di SQL Server, seperti menghapus atau mengubah sertifikat yang digunakan untuk mengamankan titik akhir pencerminan database.

Pertama, tentukan certificate_id sertifikat titik akhir MI yang diimpor dengan mengganti nilai <ManagedInstanceFQDN> lalu jalankan kueri berikut pada SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Selanjutnya, validasi sertifikat dengan mengganti nilai <certificate_id> dari hasil kueri sebelumnya lalu jalankan kueri berikut pada SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Respons Commands completed successfully. Completion time: ... menunjukkan sertifikat titik akhir MI berhasil divalidasi.

Penting

Prosedur sp_validate_certificate_ca_chain tersimpan bergantung pada layanan OS host untuk melakukan validasi sertifikat, yang mungkin melibatkan pemeriksaan pencabutan sertifikat online. Jika OS host tidak dikonfigurasi untuk mengakses internet, eksekusi gagal meskipun rantai sertifikat valid.

Jika Anda mengalami kesalahan, mitigasi yang paling andal adalah memulihkan rantai sertifikat dengan terlebih dahulu menghapus semua sertifikat yang dibuat di bagian Impor kunci publik sertifikat dari SQL Managed Instance dan impor ke SQL Server dan Impor kunci otoritas sertifikat akar tepercaya Azure ke SQL Server, lalu mengimpor ulang sertifikat tersebut.

Menambahkan bendera pelacakan startup

Dalam SQL Server, ada dua bendera pelacakan (-T1800 dan -T9567) yang, ketika ditambahkan sebagai parameter startup, dapat mengoptimalkan performa replikasi data melalui tautan. Lihat Mengaktifkan bendera pelacakan startup untuk mempelajari lebih lanjut.

Gunakan komit sinkron dengan hati-hati

Mode penerapan default untuk tautan adalah asinkron. Meskipun dimungkinkan untuk mengubah mode komit menjadi sinkron, tidak disarankan dan tidak perlu untuk mencegah potensi kehilangan data.

Selama failover terhubung yang direncanakan, replikasi untuk sementara beralih ke mode komit sinkron hingga failover selesai. Setelah failover, mode penerapan beralih kembali ke asinkron, meskipun secara eksplisit diatur ke mode penerapan sinkron sebelum failover.

Menggunakan mode penerapan sinkron untuk tautan dapat memengaruhi performa replika utama Anda, terutama jika ada latensi jaringan yang tinggi antara replika. Dalam mode penerapan sinkron, transaksi pada replika utama harus menunggu konfirmasi bahwa catatan log transaksi diperkuat pada replika sekunder sebelum transaksi dapat dilakukan pada primer. Waktu tunggu ini meningkat dengan latensi jaringan yang lebih tinggi, yang dapat menyebabkan peningkatan waktu respons transaksi dan pengurangan throughput pada replika utama.

Konten terkait

Untuk menggunakan tautan:

Untuk mempelajari selengkapnya tentang tautan:

Untuk skenario replikasi dan migrasi lainnya, pertimbangkan:

  • Last updated on