Gambaran Umum Log Replay Service dengan Azure SQL Managed Instance

  • Artikel

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.

Untuk memulai, tinjau Memigrasikan database dari SQL Server ke Azure SQL Managed Instance dengan menggunakan Layanan Pemutaran Ulang Log.

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 cutover migrasi.
  • File yang dapat dijalankan Database Migration Service tidak dapat diinstal ke lingkungan Anda.
  • File yang dapat dijalankan 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.

Sumber berikut ini didukung:

  • SQL Server on Virtual Machines
  • 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)

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 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 agar tidak membaca header file saja. 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 telah CHECKSUM diaktifkan untuk pencadangan tidak diperlukan, 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 berkelanjutan

Anda dapat memulai LRS dalam mode pelengkapan otomatis atau berkelanjutan.

Gunakan mode lengkapi otomatis saat Anda memiliki seluruh rantai cadangan yang 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 ditampilkan sebagai dipulihkan pada SQL Managed Instance. Kemudian, mulai cutover manual. Langkah cutover akhir membuat database online dan tersedia 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
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 migrasi otomatis atau berkelanjutan.

Mulai LRS secara terpisah untuk setiap database yang menunjuk ke folder cadangan di akun Blob Storage.

Setelah layanan dimulai, dibutuhkan cadangan dari kontainer Blob Storage dan mulai memulihkannya 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 dengan PowerShell (get-azsqlinstancedatabaselogreplay) atau Azure CLI (cmdlet az_sql_midb_log_replay_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 cutover ke clous 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 beban kerja. Ambil cadangan log-tail terakhir dan unggah ke penyebaran Azure Blob Storage. Pastikan cadangan log-tail terakhir telah dipulihkan pada instans terkelola. Selesaikan peralihan dengan memulai operasi complete LRS dengan 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.

Repoint aplikasi string koneksi 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).

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 untuk instans terkelola Tujuan Umum, dan dihidupkan ulang untuk instans terkelola Business Critical. 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.

    Sebaiknya gunakan mode pelengkapan otomatis untuk beban kerja pasif di mana penangkapan data tidak diperlukan.

  • 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 cutover 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, LRS harus dimulai secara terpisah untuk setiap database yang menunjuk ke jalur URI lengkap kontainer penyimpanan Azure Blob dan folder database individual.

Batasan LRS

Pertimbangkan batasan LRS berikut:

  • Hanya database .bak, .log, dan .diff file yang didukung oleh LRS. File Dacpac dan bacpac tidak didukung.
  • Selama proses migrasi, database yang sedang dimigrasikan tidak dapat digunakan untuk akses baca-saja pada SQL Managed Instance.
  • Anda harus mengonfigurasi jendela pemeliharaan untuk memungkinkan penjadwalan pembaruan sistem pada hari dan waktu tertentu. Rencanakan untuk menjalankan dan menyelesaikan migrasi di luar jendela pemeliharaan terjadwal.
  • Pencadangan database yang diambil tanpa CHECKSUM membutuhkan waktu lebih lama untuk dipulihkan daripada melakukan pencadangan database dengan CHECKSUM diaktifkan.
  • Token tanda tangan akses bersama (SAS) yang digunakan LRS harus dibuat untuk seluruh kontainer Azure Blob Storage, dan harus memiliki izin Baca dan Daftar saja. Misalnya, jika Anda memberikan izin Baca, Daftar, dan Tulis, LRS tidak akan dapat memulai karena izin Tulis tambahan.
  • Menggunakan token SAS yang dibuat dengan izin yang diatur melalui menentukan kebijakan akses tersimpan tidak didukung. Ikuti petunjuk dalam artikel ini untuk menentukan izin Baca dan Daftar secara manual untuk token SAS.
  • Anda harus menempatkan file cadangan untuk database yang berbeda di folder terpisah pada akun Blob Storage dalam struktur file datar. Folder berlapis di dalam folder database tidak didukung.
  • Jika Anda menggunakan mode pelengkapan otomatis, seluruh rantai cadangan harus tersedia terlebih dahulu di akun Blob Storage. Tidak dimungkinkan untuk menambahkan file cadangan baru dalam mode lengkapi otomatis. Gunakan mode berkelanjutan jika Anda perlu menambahkan file cadangan baru saat migrasi sedang berlangsung.
  • Anda harus memulai LRS secara terpisah untuk setiap database yang menunjuk ke jalur URI lengkap yang berisi folder database individual.
  • Jalur URI cadangan, nama kontainer, atau nama folder tidak boleh berisi backup atau backups karena ini adalah kata kunci yang dicadangkan.
  • Saat memulai beberapa pemulihan Pemutaran Ulang Log secara paralel, menargetkan kontainer penyimpanan yang sama, pastikan bahwa token SAS yang valid yang sama disediakan untuk setiap operasi pemulihan.
  • LRS dapat mendukung hingga 100 proses pemulihan simultan per instans terkelola tunggal.
  • Satu pekerjaan LRS dapat berjalan selama maksimal 30 hari, setelah itu akan dibatalkan secara otomatis.
  • Meskipun dimungkinkan untuk menggunakan akun Azure Storage di belakang firewall, konfigurasi tambahan diperlukan, dan akun penyimpanan dan instans terkelola harus berada di wilayah yang sama, atau dua wilayah berpasangan. Tinjau Mengonfigurasi firewall untuk mempelajari lebih lanjut.
  • Jumlah maksimum database yang dapat Anda pulihkan secara paralel adalah 200 per satu langganan. Dalam beberapa kasus, dimungkinkan untuk meningkatkan batas ini dengan membuka tiket dukungan.

Tip

Jika Anda mengharuskan database dapat diakses baca-saja selama migrasi, dengan jangka waktu yang lebih lama untuk melakukan migrasi dan dengan waktu henti minimal, pertimbangkan untuk menggunakan fitur tautan Azure SQL Managed Instance sebagai solusi migrasi yang direkomendasikan.

Langkah berikutnya