Memigrasikan database dari SQL Server dengan menggunakan Layanan Pemutaran Ulang Log - Azure SQL Managed Instance

Berlaku untuk:Azure SQL Managed Instance

Artikel ini menjelaskan cara memigrasikan database SQL Server ke Azure SQL Managed Instance menggunakan Log Replay Service (LRS). LRS adalah layanan cloud gratis untuk migrasi Azure SQL Managed Instance, yang dibangun di atas teknologi pengiriman log SQL Server. Pelajari proses lengkap dari prasyarat hingga cutover, termasuk praktik terbaik untuk migrasi database yang sukses.

Catatan

Sekarang dimungkinkan untuk memigrasikan instans SQL Server Anda yang diaktifkan oleh Azure Arc ke Azure SQL Managed Instance langsung melalui portal Microsoft Azure. Untuk mempelajari lebih lanjut, tinjau Migrasi ke Azure SQL Managed Instance.

Sumber berikut ini didukung:

• SQL Server pada 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)

Prasyarat

Penting

• Sebelum Anda memigrasikan database ke tingkat layanan Business Critical , pertimbangkan batasan ini, yang tidak berlaku untuk tingkat layanan Tujuan Umum.
• Anda tidak dapat menggunakan database yang sedang dipulihkan melalui LRS hingga proses migrasi selesai.
• LRS tidak mendukung akses baca-saja ke database selama migrasi.
• Setelah migrasi selesai, proses migrasi bersifat final dan tidak dapat dilanjutkan dengan cadangan diferensial tambahan.

Sebelum memulai, pertimbangkan persyaratan di bagian ini untuk instans SQL Server dan Azure Anda. Tinjau bagian batasan dan praktik terbaik dengan cermat untuk memastikan keberhasilan migrasi.

SQL Server

Pastikan Anda memenuhi persyaratan berikut untuk SQL Server:

• SQL Server versi 2008 hingga 2022.
• Database SQL Server Anda menggunakan model pemulihan penuh (wajib).
• Pencadangan penuh database (satu atau beberapa file).
• Cadangan diferensial (satu atau beberapa file).
• Pencadangan log (tidak dibagi untuk file log transaksi).
• Untuk SQL Server versi 2008 hingga 2016, ambil cadangan secara lokal dan unggah secara manual ke akun Azure Blob Storage Anda.
• Untuk SQL Server 2016 dan yang lebih baru, Anda dapat mengambil cadangan langsung ke akun Azure Blob Storage Anda.
• Meskipun mengaktifkan CHECKSUM untuk pencadangan tidak diwajibkan, sangat disarankan untuk mencegah migrasi database yang rusak secara tidak sengaja dan untuk mempercepat operasi pemulihan.
• Versi Windows Server apa pun didukung berdasarkan dukungan versi SQL Server.

Azure

Pastikan Anda memenuhi persyaratan berikut untuk Azure:

• PowerShell Az.SQL modul versi 4.0.0 atau yang lebih baru (diinstal atau diakses melalui Azure Cloud Shell).
• Azure CLI versi 2.42.0 atau yang lebih baru (terinstal).
• Kontainer penyimpanan Azure Blob yang disediakan.
• Token keamanan tanda tangan akses bersama (SAS) dengan izin Read dan List yang dihasilkan untuk kontainer Blob Storage, atau identitas terkelola yang memiliki akses ke kontainer. Memberikan lebih banyak izin daripada Read dan List akan menyebabkan LRS gagal.
• Tempatkan file cadangan untuk database individual di dalam folder terpisah di akun penyimpanan dengan menggunakan struktur file datar (wajib). Folder yang bersarang di dalam folder database tidak didukung.

Hak Akses Azure RBAC

Menjalankan LRS melalui klien yang disediakan memerlukan salah satu peran kontrol akses berbasis peran (RBAC) Azure berikut:

• Peran Kontributor SQL Managed Instance
• Peran dengan izin berikut: Microsoft.Sql/managedInstances/databases/*

Praktik terbaik

Saat Anda menggunakan LRS, pertimbangkan praktik terbaik berikut:

• Memisahkan cadangan lengkap dan diferensial menjadi beberapa file, alih-alih menggunakan satu file.
• Aktifkan kompresi cadangan untuk membantu kecepatan transfer jaringan.
• Gunakan Cloud Shell untuk menjalankan skrip PowerShell atau CLI, karena akan selalu diperbarui untuk menggunakan cmdlet terbaru yang dirilis.
• Konfigurasikan jendela pemeliharaan sehingga pembaruan sistem dijadwalkan pada hari dan waktu tertentu di luar jendela migrasi untuk mencegah penundaan atau gangguan migrasi.
• Rencanakan untuk menyelesaikan satu pekerjaan migrasi LRS dalam waktu maksimal 30 hari. Pada kedaluwarsa jangka waktu ini, pekerjaan LRS dibatalkan secara otomatis.
• Untuk mencegah migrasi database yang rusak secara tidak sengaja, dan untuk pemulihan database yang lebih cepat, aktifkan CHECKSUM saat Anda mengambil cadangan Anda. Meskipun SQL Managed Instance melakukan pemeriksaan integritas dasar pada cadangan tanpa CHECKSUM, tidak menjamin untuk menangkap semua bentuk kerusakan. Mengambil cadangan dengan CHECKSUM adalah satu-satunya cara untuk memastikan cadangan yang dipulihkan ke SQL Managed Instance tidak rusak. Pemeriksaan integritas dasar pada cadangan tanpa CHECKSUM meningkatkan waktu pemulihan database.
• Saat bermigrasi ke tingkat layanan Business Critical, perhitungkan adanya keterlambatan yang berkepanjangan dalam ketersediaan database setelah proses cutover, sementara database disemai ke replika sekunder. Untuk database besar khususnya dengan persyaratan waktu henti minimal, pertimbangkan untuk bermigrasi ke tingkat layanan Tujuan Umum terlebih dahulu dan kemudian meningkatkan ke tingkat layanan Business Critical , atau menggunakan tautan Instans Terkelola untuk memigrasikan data Anda.
• Mengunggah ribuan file database untuk dipulihkan dapat menyebabkan waktu migrasi yang berlebihan dan bahkan kegagalan. Mengonsolidasikan database ke dalam lebih sedikit file untuk mempercepat proses migrasi, dan memastikan keberhasilannya.
• Untuk meminimalkan waktu cutover dan mengurangi risiko kegagalan, pastikan cadangan terakhir Anda sekecil mungkin.

Mengonfigurasi jendela pemeliharaan

Pembaruan sistem untuk SQL Managed Instance lebih diutamakan daripada migrasi database yang sedang berlangsung.

Migrasi dipengaruhi secara berbeda berdasarkan tingkat layanan:

• Di tingkat layanan Tujuan Umum, semua migrasi LRS yang tertunda ditangguhkan dan dilanjutkan hanya setelah pembaruan diterapkan. Perilaku sistem ini mungkin memperpanjang waktu migrasi, terutama untuk database besar.
• Di tingkat layanan Business Critical, semua migrasi LRS yang tertunda dibatalkan dan dimulai ulang secara otomatis setelah pembaruan diterapkan. Perilaku sistem ini mungkin memperpanjang waktu migrasi, terutama untuk database besar.

Untuk mencapai waktu yang dapat diprediksi untuk migrasi database, pertimbangkan untuk mengonfigurasi jendela pemeliharaan untuk menjadwalkan pembaruan sistem untuk hari dan waktu tertentu, serta menjalankan dan menyelesaikan pekerjaan migrasi di luar jangka waktu jendela pemeliharaan yang ditunjuk. Misalnya, untuk migrasi yang dimulai pada hari Senin, konfigurasikan jendela pemeliharaan kustom Anda pada hari Minggu untuk memungkinkan waktu paling lama untuk menyelesaikan migrasi.

Mengonfigurasi jendela pemeliharaan tidak diperlukan tetapi sangat disarankan untuk database besar.

Catatan

Meskipun jendela pemeliharaan mengontrol prediktabilitas pembaruan yang direncanakan , jendela tersebut tidak menjamin bahwa failover yang tidak direncanakan, atau pembaruan patch keamanan tidak akan terjadi. Failover yang tidak direncanakan atau patch keamanan (yang lebih diutamakan daripada semua pembaruan lainnya) masih dapat mengganggu migrasi Anda.

Memigrasikan beberapa database

Jika Anda memigrasikan beberapa database dengan menggunakan kontainer Azure Blob Storage yang sama, Anda harus menempatkan file cadangan untuk database yang berbeda di folder terpisah di dalam kontainer. Semua file cadangan untuk database tunggal harus ditempatkan dalam struktur file datar di dalam folder database, dan folder tidak dapat ditumpuk. Folder yang bersarang di dalam folder database tidak didukung.

Berikut adalah contoh struktur folder di dalam kontainer Azure Blob Storage, struktur yang diperlukan untuk memigrasikan beberapa database dengan menggunakan LRS.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Buat akun penyimpanan

Anda menggunakan akun Azure Blob Storage sebagai penyimpanan perantara untuk file cadangan antara instans SQL Server dan penyebaran SQL Managed Instance Anda. Untuk membuat akun penyimpanan baru dan kontainer blob di dalam akun penyimpanan:

1. Membuat akun penyimpanan.
2. Buat kontainer-blob di dalam akun penyimpanan.

Mengonfigurasi penyimpanan Azure di belakang firewall

Menggunakan penyimpanan Azure Blob yang dilindungi di belakang firewall didukung, tetapi memerlukan konfigurasi tambahan. Untuk mengaktifkan akses baca/tulis ke Azure Storage dengan Azure Firewall yang diaktifkan, Anda harus menambahkan subnet dari instans terkelola SQL ke aturan firewall jaringan virtual untuk akun penyimpanan dengan menggunakan delegasi subnet Instans Terkelola (MI) dan titik akhir layanan Penyimpanan. Akun penyimpanan dan instans terkelola harus berada di wilayah yang sama, atau dua wilayah yang dipasangkan.

Jika penyimpanan Azure Anda berada di belakang firewall, Anda mungkin melihat pesan berikut di log kesalahan instans terkelola SQL:

Audit: Storage access denied user fault. Creating an email notification:

Ini menghasilkan email yang memberi tahu Anda bahwa audit untuk instans terkelola SQL gagal menulis log audit ke akun penyimpanan. Jika Anda melihat kesalahan ini, atau menerima email ini, ikuti langkah-langkah di bagian ini untuk mengonfigurasi firewall Anda.

Untuk mengonfigurasi firewall, ikuti langkah-langkah berikut:

1. Buka instans terkelola SQL Anda di portal Microsoft Azure dan pilih subnet untuk membuka halaman Subnet .

   

2. Pada halaman Subnet , pilih nama subnet untuk membuka halaman konfigurasi subnet.

   

3. Di bawah Delegasi subnet, pilih Microsoft.Sql/managedInstances dari daftar dropdown Delegasikan subnet ke layanan . Tunggu sekitar satu jam agar izin disebarluaskan, lalu, di bawah Titik akhir layanan, pilih Microsoft.Storage dari daftar dropdown Layanan .

   

4. Selanjutnya, buka akun penyimpanan Anda di portal Azure, pilih Jaringan di bawah Keamanan + jaringan lalu pilih tab Firewall dan jaringan virtual.

5. Pada tab Firewall dan jaringan virtual untuk akun penyimpanan Anda, pilih +Tambahkan jaringan virtual yang ada untuk membuka halaman Tambahkan jaringan .

   

6. Pilih langganan, jaringan virtual, dan subnet instans terkelola yang sesuai dari menu daftar dropdown lalu pilih Tambahkan untuk menambahkan jaringan virtual instans terkelola SQL ke akun penyimpanan.

Mengautentikasi ke akun Blob Storage Anda

Gunakan token SAS atau identitas terkelola untuk mengakses akun Azure Blob Storage Anda.

Peringatan

Anda tidak dapat menggunakan token SAS dan identitas terkelola secara paralel pada akun penyimpanan yang sama. Anda dapat menggunakan token SAS atau identitas terkelola, tetapi tidak keduanya.

Token SAS

Menghasilkan token autentikasi SAS Blob Storage untuk LRS

Akses akun Azure Blob Storage Anda dengan menggunakan token SAS.

Anda dapat menggunakan akun Azure Blob Storage sebagai penyimpanan perantara untuk file cadangan antara instans SQL Server dan penyebaran SQL Managed Instance Anda. Buat token autentikasi SAS untuk LRS hanya dengan izin Baca dan Daftar. Token memungkinkan LRS mengakses akun Blob Storage Anda, dan menggunakan file cadangan untuk memulihkannya ke instans terkelola Anda.

Ikuti langkah berikut untuk menghasilkan token:

1. Di portal Azure, buka Storage Explorer.

2. Perluas Kontainer Blob.

3. Klik kanan kontainer blob dan pilih Dapatkan Tanda Tangan Akses Bersama.

   

4. Pilih jangka waktu untuk kedaluwarsa token. Pastikan token valid selama migrasi Anda.

5. Pilih zona waktu untuk token: UTC atau waktu setempat Anda.

   Penting

   Zona waktu token dan instans terkelola Anda mungkin tidak cocok. Pastikan bahwa token SAS memiliki validitas waktu yang sesuai, dengan mempertimbangkan zona waktu. Untuk memperhitungkan perbedaan zona waktu, atur validitas Dari nilai dengan baik sebelum jendela migrasi Anda dimulai, dan nilai Kepada dengan baik setelah Anda mengharapkan migrasi Anda selesai.

6. Pilih izin Baca dan Daftar saja.

   Penting

   Jangan pilih izin lainnya. Jika Anda melakukannya, LRS tidak akan dapat dimulai. Persyaratan keamanan ini adalah berdasarkan desain.

7. Pilih Buat.

   

Autentikasi SAS dihasilkan dengan validitas waktu yang Anda tentukan. Anda memerlukan versi URI token, seperti yang ditunjukkan pada cuplikan layar berikut:

Catatan

Menggunakan token SAS yang dibuat dengan izin yang ditetapkan dengan menentukan kebijakan akses tersimpan tidak didukung saat ini. Ikuti instruksi dalam prosedur ini untuk menentukan izin Baca dan Daftar secara manual untuk token SAS.

Menyalin parameter dari token SAS

Akses akun Azure Blob Storage Anda dengan menggunakan token SAS atau identitas terkelola.

Sebelum Anda menggunakan token SAS untuk memulai LRS, Anda perlu memahami strukturnya. URI token SAS yang dihasilkan terdiri dari dua bagian, dipisahkan dengan tanda tanya (?), seperti yang ditunjukkan dalam contoh ini:

Bagian pertama, dimulai dengan https:// sampai tanda tanya (?), digunakan untuk parameter StorageContainerURI yang dimasukkan sebagai input ke LRS. Ini memberikan informasi LRS tentang folder tempat file cadangan database disimpan.

Bagian kedua, dari setelah tanda tanya (?) hingga akhir string, adalah StorageContainerSasToken parameter . Bagian ini adalah token autentikasi yang ditandatangani aktual, yang valid selama waktu yang ditentukan. Bagian ini tidak perlu dimulai dengan sp= seperti yang ditunjukkan dalam contoh. Skenario Anda mungkin berbeda.

Salin parameter sebagai berikut:

1. Salin bagian pertama token, dari https:// hingga tetapi tidak menyertakan tanda tanya (?). Gunakan sebagai StorageContainerUri parameter di PowerShell atau Azure CLI saat Anda memulai LRS.

   

2. Salin bagian kedua token, dari setelah tanda tanya (?) hingga akhir string. Gunakan sebagai StorageContainerSasToken parameter di PowerShell atau Azure CLI saat Anda memulai LRS.

   

Catatan

Jangan sertakan tanda tanya (?) saat Anda menyalin salah satu bagian dari token.

Identitas yang Dikelola

Untuk menggunakan identitas terkelola, tetapkan identitas yang dikelola sistem atau dikelola pengguna untuk mengakses kontainer Azure Blob Storage.

Untuk melakukannya, ikuti langkah-langkah berikut:

1. Di portal Azure, buka akun Blob Storage yang ingin Anda otorisasi akses instans terkelola.
2. Pilih Kontrol Akses (IAM).
3. Pilih Tambahkan, lalu pilih Tambahkan penetapan peran.
4. Cari dan pilih peran yang ada, Data Blob Penyimpanan Reader. Peran khusus didukung dengan syarat memiliki izin Baca dan Daftar setidaknya.
5. Pilih Managed Identity.
6. Gunakan opsi Pilih anggota untuk mengidentifikasi langganan Anda.
7. Di daftar dropdown Managed Identity, pilih SQL Managed Instance, lalu pilih instance terkelola yang akan Anda migrasikan.
8. Pilih Pilih untuk menyimpan pengaturan Anda dan mengotorisasi akses.
9. Selesaikan proses dengan memilih Tinjau + tetapkan.

Memvalidasi akses penyimpanan instans terkelola Anda

Validasi bahwa instans terkelola Anda dapat mengakses akun Blob Storage Anda.

Pertama, unggah cadangan database apa pun, seperti full_0_0.bak, ke kontainer Azure Blob Storage Anda.

Selanjutnya, sambungkan ke instans terkelola Anda, dan jalankan kueri pengujian sampel untuk menentukan apakah instans terkelola Anda dapat mengakses cadangan dalam kontainer.

Token SAS

Jika Anda menggunakan token SAS untuk mengautentikasi ke akun penyimpanan Anda, ganti <sastoken> dengan token SAS Anda dan jalankan kueri berikut pada instans Anda:

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<sastoken>';

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Identitas yang Dikelola

Jika Anda menggunakan identitas terkelola untuk mengautentikasi ke akun penyimpanan Anda, perbarui CREATE CREDENTIAL dengan URL akun penyimpanan Anda, dan jalankan kueri sampel berikut pada instans Anda:

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'MANAGED IDENTITY';

Mengunggah cadangan ke akun Blob Storage Anda

Saat kontainer blob Anda siap dan Anda telah mengonfirmasi bahwa instans terkelola Anda dapat mengakses kontainer, Anda dapat mulai mengunggah cadangan ke akun Blob Storage Anda. Anda dapat:

• Salin cadangan Anda ke akun Blob Storage Anda.
• Ambil cadangan dari SQL Server langsung ke akun Blob Storage Anda dengan menggunakan perintah BACKUP TO URL , jika lingkungan Anda mengizinkannya (dimulai dengan SQL Server versi 2012 SP1 CU2 dan SQL Server 2014).

Menyalin cadangan yang ada ke akun Blob Storage Anda

Jika Anda menggunakan versi SQL Server yang lebih lama, atau jika lingkungan Anda tidak mendukung pencadangan langsung ke URL, ambil cadangan Anda di instans SQL Server seperti biasa, lalu salin ke akun Blob Storage Anda.

Mengambil cadangan pada instans SQL Server

Tetapkan database yang ingin Anda migrasikan ke model pemulihan penuh untuk mengizinkan pencadangan log.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Untuk secara manual membuat cadangan log, diferensial, dan penuh dari database Anda ke penyimpanan lokal, gunakan skrip T-SQL sampel berikut. CHECKSUM tidak diperlukan, tetapi disarankan untuk mencegah migrasi database yang rusak, dan untuk waktu pemulihan yang lebih cepat.

Contoh berikut mengambil cadangan database lengkap ke disk lokal:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

Contoh berikut mengambil cadangan diferensial ke disk lokal:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

Contoh berikut mengambil cadangan log transaksi ke disk lokal:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Menyalin cadangan ke akun Blob Storage Anda

Setelah cadangan Anda siap, dan Anda ingin mulai memigrasikan database ke instans terkelola dengan menggunakan LRS, Anda dapat menggunakan pendekatan berikut untuk menyalin cadangan yang ada ke akun Blob Storage Anda:

• Unduh dan instal AzCopy.
• Unduh dan pasang Azure Storage Explorer.
• Gunakan Storage Explorer di portal Azure.

Catatan

Untuk memigrasikan beberapa database dengan menggunakan kontainer Azure Blob Storage yang sama, tempatkan semua file cadangan untuk database individual ke folder terpisah di dalam kontainer. Gunakan struktur file datar untuk setiap folder database. Folder yang bersarang di dalam folder database tidak didukung.

Mengambil cadangan langsung ke akun Blob Storage Anda

Jika Anda menggunakan versi SQL Server yang didukung (dimulai dengan SQL Server 2012 SP1 CU2 dan SQL Server 2014), dan kebijakan perusahaan serta jaringan Anda mengizinkan, Anda dapat melakukan backup dari SQL Server langsung ke akun Blob Storage Anda dengan menggunakan opsi BACKUP TO URL yang tersedia. Jika Anda dapat menggunakan BACKUP TO URL, Anda tidak perlu mengambil cadangan ke penyimpanan lokal dan mengunggahnya ke akun Blob Storage Anda.

Saat Anda mengambil cadangan asli langsung ke akun Blob Storage, Anda harus mengautentikasi ke akun penyimpanan.

Gunakan perintah berikut untuk membuat kredensial yang mengimpor token SAS ke instans SQL Server Anda:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<SAS_TOKEN>';

Untuk instruksi terperinci yang bekerja dengan token SAS, tinjau tutorial Menggunakan Azure Blob Storage dengan SQL Server.

Setelah membuat kredensial untuk mengautentikasi instans SQL Server Anda dengan Blob Storage, Anda dapat menggunakan perintah BACKUP TO URL untuk mengambil cadangan langsung ke akun penyimpanan. CHECKSUM disarankan, tetapi tidak diperlukan.

Contoh berikut mengambil cadangan database penuh ke URL:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

Contoh berikut mengambil cadangan database diferensial ke sebuah URL:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

Contoh berikut mengambil cadangan log transaksi ke URL:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;

Masuk ke Azure dan pilih langganan

Gunakan cmdlet PowerShell berikut untuk masuk ke Azure:

Login-AzAccount

Pilih langganan tempat instans terkelola Anda berada dengan menggunakan cmdlet PowerShell berikut:

Select-AzSubscription -SubscriptionId <subscription ID>

Memulai migrasi

Mulai migrasi dengan memulai LRS. Anda dapat memulai layanan dalam mode pelengkapan otomatis atau berkelanjutan.

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 Blob Storage Anda. Ini tidak memungkinkan penambahan file cadangan baru saat migrasi sedang berlangsung. Opsi ini memerlukan start perintah untuk menentukan nama file file cadangan terakhir. Kami merekomendasikan mode ini untuk beban kerja pasif di mana penangkapan data tidak diperlukan.

Saat Anda menggunakan mode berkelanjutan, layanan terus memindai folder Azure Blob Storage dan memulihkan file cadangan baru yang ditambahkan saat migrasi sedang berlangsung. Migrasi baru selesai setelah cutover manual diajukan. 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. Kami merekomendasikan mode ini untuk beban kerja aktif yang memerlukan penangkapan data.

Rencanakan untuk menyelesaikan satu pekerjaan migrasi LRS dalam waktu maksimal 30 hari. Ketika waktu 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.

Mulai LRS dalam mode pelengkapan otomatis

Pastikan bahwa seluruh rantai cadangan telah diunggah ke akun Azure Blob Storage Anda. Opsi ini tidak mengizinkan file cadangan baru ditambahkan saat migrasi sedang berlangsung.

Untuk memulai LRS dalam mode pelengkapan otomatis, gunakan perintah PowerShell atau Azure CLI. Tentukan nama file cadangan terakhir dengan menggunakan parameter -LastBackupName. Setelah pemulihan file cadangan terakhir yang ditentukan selesai, layanan secara otomatis memulai cutover.

Pulihkan database Anda dari akun penyimpanan dengan menggunakan token SAS atau identitas terkelola.

Penting

• Pastikan bahwa seluruh rantai cadangan telah diunggah ke akun Azure Blob Storage Anda sebelum Anda memulai migrasi dalam mode lengkapi otomatis. Mode ini tidak mengizinkan file cadangan baru ditambahkan saat migrasi sedang berlangsung.

• Pastikan Anda telah menentukan file cadangan terakhir dengan benar, dan Anda belum mengunggah lebih banyak file setelahnya. Jika sistem mendeteksi lebih banyak file cadangan di luar file cadangan terakhir yang ditentukan, migrasi akan gagal.

Token SAS

Contoh PowerShell berikut memulai LRS dalam mode lengkapi otomatis dengan menggunakan token SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Contoh Azure CLI berikut memulai LRS dalam mode lengkapi otomatis dengan menggunakan token SAS:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Identitas yang Dikelola

Contoh PowerShell berikut memulai LRS dalam mode lengkapi otomatis dengan menggunakan identitas terkelola:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Memulai LRS dalam mode kontinu

Pastikan Anda telah mengunggah rantai cadangan awal ke akun Azure Blob Storage Anda.

Penting

Setelah Anda menjalankan LRS dalam mode kontinu, Anda akan dapat menambahkan backup log dan diferensial baru ke akun penyimpanan Anda hingga pemindahan manual. Setelah cutover manual dimulai, tidak ada file diferensial tambahan yang dapat ditambahkan atau dipulihkan.

Token SAS

Contoh PowerShell berikut memulai LRS dalam mode berkelanjutan dengan menggunakan token SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Contoh Azure CLI berikut memulai LRS dalam mode berkelanjutan:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Identitas yang Dikelola

Contoh PowerShell berikut memulai LRS dalam mode berkelanjutan dengan menggunakan identitas terkelola:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Membuat skrip pekerjaan migrasi

Klien PowerShell dan Azure CLI yang memulai LRS dalam mode kontinyu adalah sinkron. Dalam mode ini, PowerShell dan Azure CLI menunggu respons API melaporkan keberhasilan atau kegagalan sebelum memulai pekerjaan.

Selama waktu menunggu ini, perintah tidak akan mengembalikan kontrol ke prompt perintah. Jika Anda membuat skrip pengalaman migrasi, dan Anda memerlukan perintah 'start' LRS untuk mengembalikan kontrol segera agar dapat melanjutkan skrip yang lain, Anda dapat menjalankan PowerShell sebagai pekerjaan latar belakang dengan sakelar -AsJob. Contohnya:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Ketika Anda memulai pekerjaan latar belakang, objek pekerjaan segera kembali, meskipun pekerjaan membutuhkan waktu lama untuk diselesaikan. Anda dapat terus bekerja dalam sesi tanpa gangguan saat pekerjaan berjalan. Untuk detail tentang menjalankan PowerShell sebagai pekerjaan latar belakang, lihat dokumentasi PowerShell Start-Job.

Demikian pula, untuk memulai perintah Azure CLI di Linux sebagai proses latar belakang, gunakan ampersand (&) di akhir perintah mulai LRS:

az sql midb log-replay start <required parameters> &

Memantau kemajuan migrasi

Az.SQL 4.0.0 dan yang lebih baru memberikan laporan kemajuan terperinci. Tinjau Detail Pemulihan Database Terkelola untuk contoh hasil keluaran.

Untuk memantau kemajuan migrasi yang sedang berlangsung melalui PowerShell, gunakan perintah berikut:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Untuk memantau kemajuan migrasi yang sedang berlangsung melalui Azure CLI, gunakan perintah berikut:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Untuk melacak detail tambahan pada permintaan yang gagal, gunakan perintah PowerShell Get-AzSqlInstanceOperation atau gunakan perintah Azure CLI az sql mi op show.

Menghentikan migrasi (opsional)

Jika Anda perlu menghentikan migrasi, gunakan PowerShell atau Azure CLI. Menghentikan migrasi akan menghapus database pemulihan pada instans terkelola Anda, sehingga memulai kembali migrasi tidak akan mungkin dilakukan.

Untuk menghentikan proses migrasi melalui PowerShell, gunakan perintah berikut:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Untuk menghentikan proses migrasi melalui Azure CLI, gunakan perintah berikut:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Menyelesaikan migrasi (mode berkelanjutan)

Jika Anda memulai LRS dalam mode berkelanjutan, pastikan bahwa aplikasi dan beban kerja SQL Server Anda telah dihentikan untuk mencegah file cadangan baru dibuat. Pastikan cadangan terakhir dari instans SQL Server Anda telah diunggah ke akun Azure Blob Storage Anda. Pantau kemajuan pemulihan pada instans terkelola Anda, dan pastikan cadangan log-tail terakhir telah dipulihkan.

Ketika cadangan log-tail terakhir telah dipulihkan pada instans terkelola Anda, lakukan alih operasi manual untuk menyelesaikan migrasi. Setelah cutover selesai, database menjadi tersedia untuk akses baca dan tulis pada instans terkelola.

Untuk menyelesaikan proses migrasi dalam mode berkelanjutan LRS melalui PowerShell, gunakan perintah berikut:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Untuk menyelesaikan proses migrasi dalam mode berkelanjutan LRS melalui Azure CLI, gunakan perintah berikut:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Batasan

Pertimbangkan batasan berikut saat bermigrasi dengan LRS:

• Anda tidak dapat menggunakan database yang sedang dipulihkan melalui LRS hingga proses migrasi selesai.
• Selama proses migrasi, database yang sedang dimigrasikan tidak dapat digunakan untuk akses baca-saja pada SQL Managed Instance.
• Setelah migrasi selesai, proses migrasi bersifat final dan tidak dapat dilanjutkan dengan cadangan diferensial tambahan.
• Hanya database .bak, .log, dan .diff file yang didukung oleh LRS. File Dacpac dan bacpac tidak didukung.
• Anda harus mengonfigurasi jendela pemeliharaan untuk menjadwalkan pembaruan sistem pada hari dan waktu tertentu. Rencanakan untuk menjalankan dan menyelesaikan migrasi di luar jendela pemeliharaan terjadwal.
• Pencadangan database yang diambil tanpa CHECKSUM:
  • dapat berpotensi memigrasikan database yang rusak.
  • membutuhkan waktu lebih lama untuk pemulihannya daripada pencadangan database dengan CHECKSUM diaktifkan.
• Token tanda tangan akses bersama (token SAS) yang digunakan LRS harus dihasilkan untuk seluruh kontainer Azure Blob Storage, dan harus hanya memiliki izin Read dan List. Misalnya, jika Anda memberikan izin kepada Read, List, dan Write, LRS gagal dimulai karena izin tambahan Write.
• Menggunakan token SAS yang dibuat dengan izin yang diatur melalui kebijakan akses tersimpan yang ditentukan 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 yang bersarang 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 dapat berisi backup atau Backup karena ini adalah kata kunci yang dicadangkan.
• Saat memulai beberapa pemulihan Log Replay secara paralel dengan menargetkan kontainer penyimpanan yang sama, pastikan token SAS yang valid dan sama disediakan untuk setiap operasi pemulihan.
• LRS mendukung migrasi jumlah total database ke satu instans hingga batas sumber daya tingkat layanan. Misalnya, Anda dapat memulihkan hingga 100 total database di tingkat layanan Tujuan Umum , dan hingga 500 total database di tingkat layanan Tujuan Umum Next-Gen .
• LRS mendukung 100 pemulihan database simultan ke satu instans, dan 150 pemulihan database simultan untuk semua instans dalam satu langganan. Misalnya, Anda dapat memulihkan 100 database secara paralel ke dua instans dalam langganan yang sama pada saat yang sama, atau 50 database dalam tiga batch simultan secara paralel dengan empat instans terpisah dalam langganan yang sama.
• 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 150 per satu langganan. Dalam beberapa kasus, dimungkinkan untuk meningkatkan batas ini dengan membuka tiket dukungan.
• Mengunggah ribuan file database untuk dipulihkan dapat menyebabkan waktu migrasi yang berlebihan dan bahkan kegagalan. Mengonsolidasikan database ke dalam lebih sedikit file untuk mempercepat proses migrasi, dan memastikan keberhasilannya.
• Ada dua skenario, di awal dan akhir proses migrasi, di mana migrasi dibatalkan jika kegagalan terjadi, dan pekerjaan migrasi harus dimulai ulang secara manual dari awal saat database dihilangkan dari SQL Managed Instance:
  • Jika failover terjadi ketika pencadangan database lengkap pertama sedang dalam proses dipulihkan ke SQL Managed Instance ketika pekerjaan migrasi pertama kali dimulai, maka pekerjaan migrasi harus dimulai ulang secara manual dari awal.
  • Jika failover terjadi setelah cutover migrasi dimulai, pekerjaan migrasi harus dimulai ulang secara manual dari awal. Pastikan file cadangan terakhir sekecil mungkin untuk meminimalkan waktu cutover dan mengurangi risiko failover selama proses cutover.

Catatan

Jika Anda mengharuskan database dapat diakses baca-saja selama migrasi, dengan jangka waktu yang jauh lebih lama untuk melakukan migrasi dan dengan waktu henti minimal, pertimbangkan untuk menggunakan Gambaran Umum fitur tautan Instans Terkelola sebagai solusi migrasi yang direkomendasikan.

Batasan saat bermigrasi ke tingkat layanan Business Critical

Saat bermigrasi ke SQL Managed Instance di tingkat layanan Business Critical , pertimbangkan batasan berikut:

• Saat memigrasikan database besar, mungkin ada downtime yang signifikan karena database tidak tersedia setelah transisi akhir sementara database disemai ke replika sekunder dari tingkat layanan Business Critical. Penanganan masalah tercantum di bagian cutover yang lebih panjang.
• Migrasi secara otomatis dimulai ulang dari awal jika migrasi terganggu oleh failover, pembaruan sistem, atau patch keamanan yang tidak direncanakan, sehingga sulit untuk merencanakan migrasi yang dapat diprediksi tanpa kejutan menit terakhir.

Penting

Batasan ini hanya berlaku saat bermigrasi ke tingkat layanan Business Critical , dan bukan ke tingkat layanan Tujuan Umum.

Perpindahan yang lebih lama di tingkat layanan Business Critical

Jika Anda bermigrasi ke SQL Managed Instance di tingkat layanan Business Critical, perhitungkan keterlambatan dalam mengaktifkan database di replika utama saat sedang diproses untuk replika sekunder. Ini terutama berlaku untuk database yang lebih besar.

Migrasi ke SQL Managed Instance di tingkat layanan Business Critical membutuhkan waktu lebih lama untuk diselesaikan daripada di tingkat layanan Tujuan Umum. Setelah proses cutover ke Azure selesai, database tidak tersedia sampai disinkronkan dari replika utama ke tiga replika sekunder, yang dapat memakan waktu yang cukup lama tergantung pada besar kecilnya database Anda. Semakin besar database, semakin lama penyemaian ke replika sekunder membutuhkan waktu - hingga beberapa jam, berpotensi.

Jika penting bahwa database tersedia segera setelah cutover selesai, maka pertimbangkan solusi berikut:

• Migrasikan ke tingkat layanan Tujuan Umum terlebih dahulu, lalu tingkatkan ke tingkat layanan Business Critical. Meningkatkan tingkat layanan Anda adalah operasi online yang menjaga agar database Anda tetap online hingga terjadi failover singkat sebagai langkah akhir dari operasi peningkatan tersebut.
• Gunakan tautan Instans Terkelola untuk migrasi online ke instans Bisnis Kritis tanpa harus menunggu database tersedia setelah peralihan.

Memecahkan masalah LRS

Setelah Anda memulai LRS, gunakan salah satu cmdlet pemantauan berikut untuk melihat status operasi yang sedang berlangsung:

• Untuk PowerShell: get-azsqlinstancedatabaselogreplay
• Untuk Azure CLI: az_sql_midb_log_replay_show

Untuk meninjau detail tentang operasi yang gagal:

• Untuk PowerShell: Get-AzSqlInstanceOperation
• Untuk Azure CLI: az sql mi op show

Jika LRS gagal memulai setelah beberapa waktu dan Anda mendapatkan kesalahan, periksa masalah yang paling umum:

• Apakah database yang ada pada instans terkelola Anda memiliki nama yang sama dengan database yang coba Anda migrasikan dari instans SQL Server Anda? Selesaikan konflik ini dengan mengganti nama salah satu database.
• Apakah izin yang diberikan pada token SAS hanya untuk Baca dan Daftar saja? Memberikan lebih banyak izin daripada Read dan List akan menyebabkan LRS gagal.
• Apakah Anda menyalin token SAS untuk LRS setelah tanda tanya (?), dengan konten yang terlihat seperti sv=2020-02-10...?
• Apakah waktu validitas token SAS sesuai untuk jendela waktu memulai dan menyelesaikan migrasi? Mungkin ada ketidakcocokan karena berbagai zona waktu yang digunakan untuk penyebaran SQL Managed Instance dan token SAS Anda. Coba menghasilkan ulang token SAS dan memperpanjang validitas token untuk periode sebelum dan sesudah tanggal saat ini.
• Saat memulai beberapa pemulihan ulang log secara paralel yang menargetkan kontainer penyimpanan yang sama, pastikan token SAS yang valid yang sama disediakan untuk setiap pemulihan operasi.
• Apakah nama database, nama grup sumber daya, dan nama instans terkelola dieja dengan benar?
• Jika Anda memulai LRS dalam mode lengkapi otomatis, apakah ditentukan nama file yang valid untuk cadangan terakhir?
• Apakah jalur URI cadangan berisi kata kunci backup atau backups? Ganti nama kontainer atau folder yang menggunakan backup atau backups karena ini adalah kata kunci yang dicadangkan.

Konten terkait

• Ikhtisar Log Replay Service dengan Azure SQL Managed Instance
• Gambaran umum tautan Instans Terkelola
• Migrasi dari SQL Server ke Azure SQL Managed Instance
• Perbedaan T-SQL antara SQL Server dan Azure SQL Managed Instance
• Praktik terbaik untuk biaya dan ukuran beban kerja yang dimigrasikan ke Azure
• Membandingkan LRS dengan tautan Instans Terkelola