Bagikan melalui

Gambaran Umum Layanan Pemutaran Ulang Log dengan Azure SQL Managed Instance

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 didasarkan pada teknologi pengiriman log SQL Server.

Catatan

Anda sekarang dapat memigrasikan instans SQL Server yang diaktifkan oleh Azure Arc ke Azure SQL Managed Instance langsung melalui portal Microsoft Azure. Untuk informasi selengkapnya, lihat Migrasi ke Azure SQL Managed Instance.

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 dari SQL Server 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:

  • Anda memerlukan kontrol lebih untuk proyek migrasi database Anda.
  • Ada sedikit toleransi untuk waktu henti selama peralihan migrasi.
  • Anda tidak dapat menginstal file yang dapat dieksekusi Database Migration Service ke lingkungan Anda.
  • Berkas eksekusi Database Migration Service tidak memiliki akses file ke cadangan database Anda.
  • Anda tidak dapat menginstal ekstensi migrasi Azure SQL ke lingkungan Anda, atau tidak dapat mengakses cadangan database Anda.
  • Anda tidak memiliki akses ke sistem operasi host atau hak istimewa administrator.
  • Anda tidak dapat membuka port jaringan dari lingkungan Anda ke Azure.
  • Masalah pembatasan jaringan atau 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 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
  • Google Compute Engine
  • 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

  • LRS adalah satu-satunya metode untuk memulihkan cadangan diferensial pada instans terkelola SQL. 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. LRS mendukung pencadangan penuh, log, dan diferensial. 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 Anda tambahkan 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. LRS memulihkan database 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 dengan menggunakan Log Replay Service.

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 pelengkapan 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 selesai secara otomatis ketika file cadangan terakhir yang ditentukan dipulihkan. Database yang dimigrasikan 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 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 file cadangan terakhir dipulihkan dengan memverifikasi bahwa cadangan log-tail akhir ditampilkan sebagai 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 yang Anda bawa 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

Gambar di bagian ini memperlihatkan alur kerja migrasi umum saat tabel menguraikan langkah-langkahnya.

Gunakan mode lengkapi otomatis hanya ketika semua file rantai cadangan tersedia terlebih dahulu. Kami merekomendasikan mode ini untuk beban kerja pasif yang tidak memerlukan ketertinggalan 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 membutuhkan susulan 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. Mulai layanan dengan PowerShell (start-azsqlinstancedatabaselogreplay) atau Azure CLI (cmdlet az_sql_midb_log_replay_start). 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.

Saat Anda memulai LRS dalam mode lengkapi otomatis, LRS memulihkan semua cadangan melalui file cadangan terakhir yang ditentukan. Anda harus mengunggah semua file cadangan terlebih dahulu, dan Anda tidak dapat menambahkan file cadangan baru saat migrasi sedang berlangsung. Mode ini direkomendasikan untuk beban kerja pasif yang tidak memerlukan ketertinggalan data.

Saat Anda memulai LRS dalam mode berkelanjutan, LRS memulihkan semua cadangan yang awalnya Anda unggah dan kemudian mengawasi file baru yang Anda unggah 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 membutuhkan susulan data.
2.1. Memantau kemajuan operasi. Pantau kemajuan operasi pemulihan yang sedang berlangsung dengan PowerShell (get-azsqlinstancedatabaselogreplay) atau Azure CLI (cmdlet az_sql_midb_log_replay_show). 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 Anda memulai LRS dalam mode lengkapi otomatis, migrasi secara otomatis selesai setelah file cadangan terakhir yang ditentukan dipulihkan.

Jika Anda memulai LRS dalam mode berkelanjutan, hentikan aplikasi dan beban kerja. Ambil cadangan log-tail terakhir dan unggah ke Azure Blob Storage untuk penyebaran. Pastikan cadangan log-tail terakhir dipulihkan pada instans terkelola SQL. 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 poin-poin 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 dapat 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 SQL General Purpose, dan akan dimulai ulang untuk instans terkelola SQL Business Critical. Pembaruan ini 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

Mulai migrasi dengan memulai LRS. Anda dapat memulai layanan dalam mode pelengkapan otomatis atau berkelanjutan. Untuk detail spesifik, tinjau Memigrasikan database dari SQL Server dengan menggunakan Log Replay Service.

  • Mode lengkapi otomatis. Saat Anda menggunakan mode pelengkapan otomatis, migrasi selesai secara otomatis saat file cadangan terakhir yang ditentukan 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 Anda meminta pemindahan manual.

    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.

    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. Mulai LRS secara terpisah untuk setiap database, arahkan 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.

Konten terkait

  • Last updated on