Gambaran Umum Layanan Pemutaran Ulang Log dengan Azure SQL Managed Instance

2024-10-31

Berlaku untuk:Azure SQL Managed Instance

Artikel ini menyediakan gambaran umum Log Replay Service (LRS), yang dapat Anda gunakan untuk memigrasikan database dari SQL Server ke Azure SQL Managed Instance. LRS adalah layanan cloud gratis yang tersedia untuk Azure SQL Managed Instance dan berdasarkan teknologi pengiriman log SQL Server.

Karena LRS memulihkan file cadangan SQL Server standar, Anda dapat menggunakannya untuk bermigrasi dari SQL Server yang dihosting di mana saja (baik lokal, atau cloud apa pun) ke Azure SQL Managed Instance.

Untuk memulai migrasi Anda dengan LRS, tinjau Memigrasikan database dengan menggunakan Log Replay Service.

Penting

Sebelum Anda memigrasikan database ke tingkat layanan Business Critical , pertimbangkan batasan ini, yang tidak berlaku untuk tingkat layanan Tujuan Umum.

Kapan harus menggunakan Layanan Pemutaran Ulang Log

Azure Database Migration Service, ekstensi migrasi Azure SQL untuk Azure Data Studio, dan LRS semuanya menggunakan teknologi dan API migrasi yang mendasar yang sama. LRS selanjutnya memungkinkan migrasi kustom yang kompleks dan arsitektur hibrid antara instans SQL Server lokal dan penyebaran SQL Managed Instance.

Saat Anda tidak dapat menggunakan Azure Database Migration Service, atau ekstensi Azure SQL untuk migrasi, Anda dapat menggunakan LRS secara langsung dengan PowerShell, cmdlet Azure CLI, atau API untuk membangun dan mengatur migrasi database secara manual ke SQL Managed Instance.

Pertimbangkan untuk menggunakan LRS dalam kasus berikut, ketika:

Anda memerlukan kontrol lebih untuk proyek migrasi database Anda.
Ada sedikit toleransi untuk waktu henti selama peralihan migrasi.
File eksekusi Database Migration Service tidak dapat diinstal ke lingkungan Anda.
Berkas eksekusi Database Migration Service tidak memiliki akses file ke cadangan database Anda.
Ekstensi migrasi Azure SQL tidak dapat diinstal ke lingkungan Anda, atau tidak dapat mengakses cadangan database Anda.
Tidak ada akses ke sistem operasi host yang tersedia, atau tidak ada hak istimewa administrator.
Anda tidak dapat membuka port jaringan dari lingkungan Anda ke Azure.
Pembatasan jaringan, atau masalah pemblokiran proksi, ada di lingkungan Anda.
Cadangan disimpan langsung di akun Azure Blob Storage melalui TO URL opsi .
Anda perlu menggunakan cadangan diferensial.

Karena LRS bekerja dengan memulihkan file cadangan SQL Server standar, LRS harus mendukung migrasi dari sumber apa pun. Sumber berikut telah diuji:

SQL Server di lokasi/fisik
SQL Server di Mesin Virtual
Amazon EC2 (Elastic Compute Cloud)
Amazon RDS (Relational Database Service) untuk SQL Server
Mesin Komputasi Google
Cloud SQL untuk SQL Server - GCP (Google Cloud Platform)
Alibaba Cloud RDS untuk SQL Server

Jika Anda mengalami masalah tak terduga saat bermigrasi dari sumber yang tidak terdaftar, buka tiket dukungan untuk mendapatkan bantuan.

Catatan

Kami menyarankan agar Anda mengotomatiskan migrasi database dari SQL Server ke Azure SQL Managed Instance dengan menggunakan ekstensi migrasi Azure SQL untuk Azure Data Studio. Pertimbangkan untuk menggunakan LRS untuk mengatur migrasi saat ekstensi migrasi Azure SQL tidak sepenuhnya mendukung skenario Anda.
LRS adalah satu-satunya metode untuk memulihkan cadangan diferensial pada instans terkelola. Tidak dimungkinkan untuk memulihkan cadangan diferensial secara manual pada instans terkelola atau mengatur NORECOVERY mode secara manual dengan menggunakan T-SQL.

Cara kerja LRS

Membangun solusi kustom untuk memigrasikan database ke cloud dengan LRS memerlukan beberapa langkah orkestrasi, seperti yang ditunjukkan pada diagram dan tabel nanti di bagian ini.

Migrasi terdiri dari mengambil cadangan database di SQL Server, dan menyalin file cadangan ke akun Azure Blob Storage. Pencadangan penuh, log, dan diferensial adalah jenis backup yang didukung. Anda kemudian menggunakan layanan cloud LRS untuk memulihkan file cadangan dari akun Azure Blob Storage ke SQL Managed Instance. Akun Blob Storage berfungsi sebagai penyimpanan perantara untuk file cadangan antara SQL Server dan SQL Managed Instance.

LRS memantau akun Blob Storage Anda untuk setiap pencadangan diferensial atau log baru yang ditambahkan setelah pencadangan penuh dipulihkan. LRS kemudian secara otomatis memulihkan file baru ini. Anda dapat menggunakan layanan untuk memantau kemajuan file cadangan yang sedang dipulihkan ke SQL Managed Instance, dan menghentikan proses jika perlu.

LRS tidak memerlukan konvensi penamaan khusus untuk file cadangan. Ini memindai semua file yang ditempatkan di akun Azure Blob Storage dan membuat rantai cadangan dengan hanya membaca header file. Database berada dalam status memulihkan selama proses migrasi. Database dipulihkan dalam mode NORECOVERY , sehingga tidak dapat digunakan untuk beban kerja baca atau tulis hingga proses migrasi selesai.

Jika Anda memigrasikan beberapa database, Anda perlu:

Tempatkan file cadangan untuk setiap database di folder terpisah pada akun Blob Storage dalam struktur file datar. Misalnya, gunakan folder database terpisah: blobcontainer/database1/files, blobcontainer/database2/files, dan sebagainya.
Jangan gunakan folder berlapis di dalam folder database, karena struktur folder berlapis tidak didukung. Misalnya, jangan gunakan subfolder seperti blobcontainer/database1/subfolder/files.
Memulai LRS secara terpisah untuk setiap database.
Tentukan jalur URI yang berbeda untuk memisahkan folder database pada akun Blob Storage.

Meskipun mengaktifkan CHECKSUM untuk pencadangan tidak diwajibkan, kami sangat merekomendasikannya. Memulihkan database tanpa CHECKSUM memakan waktu lebih lama, karena SQL Managed Instance melakukan pemeriksaan integritas pada cadangan yang dipulihkan tanpa CHECKSUM diaktifkan.

Untuk informasi selengkapnya, lihat Memigrasikan database dari SQL Server ke SQL Managed Instance dengan menggunakan Layanan Pemutaran Ulang Log.

Perhatian

Mengambil cadangan di SQL Server dengan CHECKSUM diaktifkan sangat disarankan karena ada risiko untuk memulihkan database yang rusak ke Azure tanpanya.

Pelengkapan otomatis vs. migrasi mode kontinu

Anda dapat memulai LRS dengan mode pelengkapan otomatis atau berkelanjutan.

Gunakan mode autocomplete ketika Anda memiliki seluruh rantai cadangan yang telah dihasilkan sebelumnya, dan ketika Anda tidak berencana untuk menambahkan file lagi setelah migrasi dimulai. Mode migrasi ini direkomendasikan untuk beban kerja pasif yang tidak memerlukan ketertinggalan data. Unggah semua file cadangan ke akun Blob Storage, dan mulai migrasi mode lengkapi otomatis. Migrasi akan selesai secara otomatis ketika file cadangan terakhir yang ditentukan telah dipulihkan. Database yang dimigrasikan akan tersedia untuk akses baca/tulis di SQL Managed Instance.

Jika Anda berencana untuk terus menambahkan file cadangan baru saat migrasi sedang berlangsung, gunakan mode berkelanjutan . Kami merekomendasikan mode ini untuk beban kerja aktif yang membutuhkan susulan data. Unggah rantai cadangan yang saat ini tersedia ke akun Blob Storage, mulai migrasi dalam mode berkelanjutan, dan terus tambahkan file cadangan baru dari beban kerja Anda sesuai kebutuhan. Sistem akan secara berkala memindai folder Azure Blob Storage dan memulihkan file cadangan log atau diferensial baru yang ditemukannya.

Saat Anda siap untuk cutover, hentikan beban kerja pada instans SQL Server Anda, buat file cadangan terakhir, lalu unggah. Pastikan bahwa file cadangan terakhir telah dipulihkan dengan memverifikasi bahwa cadangan log-tail akhir terlihat telah dipulihkan pada SQL Managed Instance. Kemudian, mulai peralihan manual. Langkah cutover terakhir membuat database menjadi aktif dan siap untuk akses baca/tulis di SQL Managed Instance.

Setelah LRS dihentikan, baik secara otomatis melalui pelengkapan otomatis, atau secara manual melalui cutover, Anda tidak dapat melanjutkan proses pemulihan untuk database disimpan secara online di SQL Managed Instance. Misalnya, setelah migrasi selesai, Anda tidak lagi dapat memulihkan lebih banyak cadangan diferensial untuk database online. Untuk memulihkan lebih banyak file cadangan setelah migrasi selesai, Anda perlu menghapus database dari instans terkelola dan memulai ulang migrasi dari awal.

Alur kerja migrasi

Alur kerja migrasi umum diperlihatkan dalam gambar berikut, dan langkah-langkahnya diuraikan dalam tabel.

Anda perlu menggunakan mode lengkapi otomatis hanya ketika semua file rantai cadangan tersedia terlebih dahulu. Kami merekomendasikan mode ini untuk beban kerja pasif yang tidak diperlukan penangkapan data.

Gunakan migrasi mode berkelanjutan saat Anda tidak memiliki seluruh rantai cadangan terlebih dahulu, dan ketika Anda berencana untuk menambahkan file cadangan baru setelah migrasi sedang berlangsung. Kami merekomendasikan mode ini untuk beban kerja aktif yang memerlukan penangkapan data.

Diagram yang mengilustrasikan langkah-langkah orkestrasi Layanan Pemutaran Ulang Log untuk SQL Managed Instance.

Operasi	Detail-detail
1. Salin cadangan database dari instans SQL Server ke akun Blob Storage.	Salin cadangan penuh, diferensial, dan log dari instans SQL Server ke kontainer Blob Storage dengan menggunakan AzCopy atau Azure Storage Explorer. Gunakan nama file apa pun. LRS tidak memerlukan konvensi penamaan file tertentu. Gunakan folder terpisah untuk setiap database saat Anda memigrasikan beberapa database.
2. Mulai LRS di cloud.	Anda dapat memulai layanan dengan PowerShell (start-azsqlinstancedatabaselogreplay) atau Azure CLI (az_sql_midb_log_replay_start cmdlets). Pilih antara mode pelengkapan otomatis atau mode migrasi berkelanjutan. Mulai LRS secara terpisah untuk setiap database yang menunjuk ke folder cadangan di akun Blob Storage. Setelah layanan dimulai, layanan tersebut mengambil cadangan dari kontainer Blob Storage dan mulai memulihkan cadangan tersebut ke SQL Managed Instance. Ketika LRS dimulai dalam mode lengkapi otomatis, LRS memulihkan semua cadangan melalui file cadangan terakhir yang ditentukan. Semua file cadangan harus diunggah terlebih dahulu, dan tidak dimungkinkan untuk menambahkan file cadangan baru saat migrasi sedang berlangsung. Mode ini direkomendasikan untuk beban kerja pasif yang tidak memerlukan penangkapan data. Ketika LRS dimulai dalam mode berkelanjutan, LRS memulihkan semua cadangan yang awalnya diunggah dan kemudian mengawasi file baru yang diunggah ke folder. Layanan terus menerapkan log berdasarkan rantai nomor urutan log (LSN) hingga dihentikan secara manual. Kami merekomendasikan mode ini untuk beban kerja aktif yang memerlukan penangkapan data.
2.1. Memantau kemajuan operasi.	Anda dapat memantau kemajuan operasi pemulihan yang sedang berlangsung dengan PowerShell (get-azsqlinstancedatabaselogreplay) atau Azure CLI (az_sql_midb_log_replay_show cmdlets). Untuk melacak detail tambahan pada permintaan yang gagal, gunakan perintah PowerShell Get-AzSqlInstanceOperation atau gunakan perintah Azure CLI az sql mi op show.
2.2. Hentikan operasi jika diperlukan (opsional).	Jika Anda perlu menghentikan proses migrasi, gunakan PowerShell (stop-azsqlinstancedatabaselogreplay) atau Azure CLI (az_sql_midb_log_replay_stop). Menghentikan operasi akan menghapus database yang Anda pulihkan ke SQL Managed Instance. Setelah menghentikan operasi, Anda tidak dapat melanjutkan LRS untuk database. Anda perlu menghidupkan ulang proses migrasi dari awal.
3. Melakukan migrasi ke cloud saat Anda siap.	Jika LRS dimulai dalam mode lengkapi otomatis, migrasi secara otomatis selesai setelah file cadangan terakhir yang ditentukan telah dipulihkan. Jika LRS dimulai dalam mode berkelanjutan, hentikan aplikasi dan juga beban kerjanya. Ambil cadangan log-tail terakhir dan unggah ke Azure Blob Storage untuk penyebaran. Pastikan cadangan log-tail terakhir telah dipulihkan pada instans terkelola. Selesaikan proses pengalihan dengan memulai operasi `complete` LRS menggunakan PowerShell (complete-azsqlinstancedatabaselogreplay) atau Azure CLI az_sql_midb_log_replay_complete. Operasi ini menghentikan LRS dan membawa database online untuk beban kerja baca/tulis di SQL Managed Instance. Arahkan ulang string koneksi aplikasi dari instans SQL Server ke SQL Managed Instance. Anda perlu mengatur langkah ini sendiri, baik melalui perubahan string koneksi manual dalam aplikasi Anda, atau secara otomatis (misalnya, jika aplikasi Anda dapat membaca string koneksi dari properti, atau database).

Penting

Setelah cutover, SQL Managed Instance dengan tingkat layanan Business Critical dapat membutuhkan waktu lebih lama daripada General Purpose untuk dapat tersedia, karena tiga replika sekunder harus disemai untuk grup ketersediaan. Durasi operasi tergantung pada ukuran data. Untuk informasi selengkapnya, lihat Durasi operasi manajemen.

Memigrasikan database besar

Jika Anda memigrasikan database besar berukuran beberapa terabyte, pertimbangkan hal berikut:

Satu pekerjaan LRS dapat berjalan selama maksimal 30 hari. Ketika periode ini kedaluwarsa, pekerjaan akan dibatalkan secara otomatis.
Untuk pekerjaan yang berjalan lama, pembaruan sistem akan mengganggu dan memperpanjang pekerjaan migrasi. Kami sangat menyarankan Anda menggunakan jendela pemeliharaan untuk menjadwalkan pembaruan sistem yang direncanakan. Rencanakan migrasi Anda di sekitar jendela pemeliharaan terjadwal.
Pekerjaan migrasi yang terganggu oleh pembaruan sistem secara otomatis ditangguhkan dan dilanjutkan kembali untuk General Purpose instans terkelola, dan dimulai ulang untuk Business Critical instans terkelola. Pembaruan ini akan memengaruhi jangka waktu migrasi Anda.
Untuk meningkatkan kecepatan pengunggahan file cadangan SQL Server Anda ke akun Blob Storage, jika infrastruktur Anda memiliki bandwidth jaringan yang memadai, pertimbangkan untuk menggunakan paralelisasi dengan beberapa utas.

Memulai migrasi

Anda memulai migrasi dengan memulai LRS. Anda dapat memulai layanan dalam mode pelengkapan otomatis atau berkelanjutan. Untuk detail spesifik, tinjau Migrasi dengan LRS.

Mode lengkapi otomatis. Saat Anda menggunakan mode pelengkapan otomatis, migrasi selesai secara otomatis ketika file cadangan terakhir yang ditentukan telah dipulihkan. Opsi ini:
- Mengharuskan seluruh rantai cadangan tersedia terlebih dahulu dan diunggah ke akun Azure Blob Storage.
- Tidak mengizinkan penambahan file cadangan baru saat migrasi sedang berlangsung.
- Memerlukan perintah mulai untuk menentukan nama file file cadangan terakhir.
Disarankan untuk menggunakan mode pelengkapan otomatis untuk beban kerja pasif yang tidak memerlukan penyesuaian data.
Mode Berkelanjutan. Saat Anda menggunakan mode berkelanjutan, layanan terus memindai folder Azure Blob Storage dan memulihkan file cadangan baru yang ditambahkan saat migrasi sedang berlangsung.

Migrasi selesai hanya setelah pemindahan sistem manual diminta.

Anda perlu menggunakan migrasi mode berkelanjutan saat Anda tidak memiliki seluruh rantai cadangan terlebih dahulu, dan ketika Anda berencana untuk menambahkan file cadangan baru setelah migrasi sedang berlangsung.

Sebaiknya gunakan mode berkelanjutan untuk beban kerja aktif yang memerlukan penangkapan data.

Rencanakan untuk menyelesaikan satu pekerjaan migrasi LRS dalam waktu maksimal 30 hari. Ketika periode ini kedaluwarsa, pekerjaan LRS dibatalkan secara otomatis.

Catatan

Saat Anda memigrasikan beberapa database, setiap database harus berada di foldernya sendiri. LRS harus dimulai secara terpisah untuk setiap database, menunjuk ke jalur URI lengkap kontainer Azure Blob Storage dan folder database individual. Folder berlapis di dalam folder database tidak didukung.

Keterbatasan LRS

Untuk informasi, tinjau batasan saat menggunakan LRS.

Bagikan melalui