Bagikan melalui


Memindahkan sumber daya ke wilayah baru - Azure SQL Database

Berlaku untuk:Azure SQL Database

Artikel ini mengajarkan alur kerja generik tentang cara memindahkan database atau kumpulan elastis Anda ke wilayah baru.

Catatan

  • Untuk memindahkan database dan kumpulan elastis ke wilayah Azure yang berbeda, Anda juga dapat menggunakan Azure Resource Mover yang direkomendasikan.
  • Artikel ini berlaku untuk migrasi dalam cloud publik Azure atau dalam sovereign cloud.

Gambaran Umum

Ada berbagai skenario di mana Anda ingin memindahkan database atau kumpulan yang sudah ada dari satu wilayah ke wilayah lain. Misalnya, Anda memperluas bisnis ke wilayah baru dan ingin mengoptimalkannya untuk basis pelanggan baru. Atau Anda perlu memindahkan operasi ke wilayah yang berbeda karena alasan kepatuhan. Atau Azure merilis wilayah baru yang memberikan kedekatan yang lebih baik dan meningkatkan pengalaman pelanggan.

Alur kerja umum untuk memindahkan sumber daya ke wilayah yang berbeda terdiri dari langkah-langkah berikut:

  1. Memverifikasi prasyarat untuk pemindahan.
  2. Menyiapkan proses memindahkan sumber daya dalam cakupan.
  3. Memantau proses persiapan.
  4. Menguji proses pemindahan.
  5. Memulai langkah yang sebenarnya.

Memverifikasi prasyarat untuk memindahkan database

  1. Membuat server target untuk setiap server sumber.
  2. Mengonfigurasikan firewall dengan pengecualian yang tepat menggunakan PowerShell.
  3. Konfigurasikan kedua server dengan login yang benar. Jika Anda bukan administrator langganan atau administrator server SQL, bekerjalah dengan administrator untuk menetapkan izin yang Anda butuhkan. Untuk informasi selengkapnya, lihat Cara mengelola keamanan Azure SQL Database setelah pemulihan dari bencana.
  4. Jika database Anda dienkripsi dengan enkripsi data transparan (TDE) dan menggunakan kunci enkripsi Anda sendiri (BYOK atau Customer Managed Key) di Azure Key Vault, pastikan bahwa materi enkripsi yang benar disediakan di wilayah target.
    • Cara paling sederhana untuk melakukan ini adalah dengan menambahkan kunci enkripsi dari brankas kunci yang ada (yang digunakan sebagai Pelindung TDE pada server sumber) ke server target dan kemudian mengatur kunci sebagai Pelindung TDE di server target karena server di satu wilayah sekarang dapat dihubungkan ke brankas kunci di wilayah lain.
    • Sebagai praktik terbaik untuk memastikan server target memiliki akses ke kunci enkripsi yang lebih lama (diperlukan untuk memulihkan cadangan database), jalankan cmdlet Get-AzSqlServerKeyVaultKey di server sumber untuk mengembalikan daftar kunci yang tersedia dan menambahkan kunci tersebut ke server target.
    • Untuk informasi lebih lanjut dan praktik terbaik tentang mengonfigurasi TDE yang dikelola pelanggan di server target, lihat Azure SQL enkripsi data transparan dengan kunci yang dikelola pelanggan di Azure Key Vault.
    • Untuk memindahkan brankas kunci ke wilayah baru, lihat Memindahkan brankas kunci Azure di seluruh wilayah.
  5. Jika audit tingkat database diaktifkan, nonaktifkan dan aktifkan audit tingkat server. Setelah failover, audit tingkat database memerlukan lalu lintas wilayah, yang tidak diinginkan atau dimungkinkan setelah pemindahan.
  6. Untuk audit tingkat server, pastikan bahwa:
    • Kontainer penyimpanan, Analitik Log, atau hub peristiwa dengan log audit yang ada dipindahkan ke wilayah target.
    • Audit dikonfigurasi pada server target. Untuk informasi selengkapnya, lihat Memulai audit SQL Database.
  7. Jika server Anda memiliki kebijakan penyimpanan jangka panjang (LTR), cadangan LTR yang ada tetap terkait dengan server saat ini. Karena server target berbeda, Anda dapat mengakses cadangan LTR yang lebih lama di wilayah sumber dengan menggunakan server sumber, bahkan jika server dihapus.

Catatan

Memigrasikan database dengan cadangan LTR yang ada antara wilayah berdaulat dan publik tidak didukung karena ini mengharuskan pemindahan cadangan LTR ke server target, yang saat ini tidak dimungkinkan.

Menyiapkan sumber daya

  1. Buat grup kegagalan antara server sumber dan server target.
  2. Tambahkan database yang ingin Anda pindahkan ke grup kegagalan. Replikasi semua database yang ditambahkan dimulai secara otomatis. Untuk informasi selengkapnya, lihat Menggunakan grup failover dengan SQL Database.

Memantau proses persiapan

Anda dapat secara berkala memanggil Get-AzSqlDatabaseFailoverGroup untuk memantau replikasi database Anda dari sumber ke server target. Output objek Get-AzSqlDatabaseFailoverGroup mencakup properti untuk ReplicationState:

  • ReplicationState = 2 (CATCH_UP) menunjukkan bahwa database disinkronkan dan dapat digagalkan dengan aman.
  • ReplicationState = 0 (SEEDING) menunjukkan bahwa database belum ditambahkan dan upaya untuk melakukan kegagalan akan gagal.

Menguji sinkronisasi

Setelah ReplicationState menjadi 2, sambungkan ke setiap database atau subset database menggunakan titik akhir sekunder<fog-name>.secondary.database.windows.net dan lakuka kueri apa pun terhadap database untuk memastikan konektivitas, konfigurasi keamanan yang tepat, dan replikasi data.

Memulai proses pemindahan

  1. Sambungkan ke server target menggunakan titik akhir sekunder<fog-name>.secondary.database.windows.net.
  2. Gunakan Switch-AzSqlDatabaseFailoverGroup untuk mengalihkan server sekunder menjadi yang utama dengan sinkronisasi penuh. Operasi ini berhasil atau digulung balik.
  3. Verifikasi bahwa perintah telah berhasil diselesaikan dengan menggunakan nslook up <fog-name>.secondary.database.windows.net untuk memastikan bahwa entri DNS CNAME menunjuk ke alamat IP wilayah target. Jika perintah beralih gagal, CNAME tidak akan diperbarui.

Menghapus database sumber

Setelah pemindahan selesai, hapus sumber daya di wilayah sumber untuk menghindari biaya yang tidak perlu.

  1. Hapus grup kegagalan menggunakan Remove-AzSqlDatabaseFailoverGroup.
  2. Hapus setiap database sumber menggunakan Remove-AzSqlDatabase untuk setiap database di server sumber. Ini secara otomatis mengakhiri tautan replikasi geografis.
  3. Hapus server sumber menggunakan Remove-AzSqlServer.
  4. Hapus brankas kunci, kontainer penyimpanan audit, hub peristiwa, penyewa Microsoft Entra, dan sumber daya dependen lainnya untuk berhenti ditagih untuk mereka.

Memverifikasi prasyarat untuk memindahkan kumpulan

  1. Membuat server target untuk setiap server sumber.
  2. Mengonfigurasikan firewall dengan pengecualian yang tepat menggunakan PowerShell.
  3. Mengonfigurasikan server dengan info masuk yang benar. Jika Anda bukan administrator langganan atau administrator server, bekerjalah dengan administrator untuk menetapkan izin akses yang Anda butuhkan. Untuk informasi selengkapnya, lihat Cara mengelola keamanan Azure SQL Database setelah pemulihan dari bencana.
  4. Jika database Anda dienkripsi dengan enkripsi data transparan dan menggunakan kunci enkripsi Anda sendiri di Azure Key Vault, pastikan bahwa materi enkripsi yang benar disediakan di wilayah target.
  5. Buat kumpulan elastis target untuk setiap kumpulan elastis sumber, pastikan kumpulan dibuat dalam tingkat layanan yang sama, dengan nama yang sama dan ukuran yang sama.
  6. Jika audit tingkat database diaktifkan, nonaktifkan dan aktifkan audit tingkat server. Setelah failover, audit tingkat database akan memerlukan lalu lintas wilayah, yang tidak diinginkan, atau dimungkinkan setelah pemindahan.
  7. Untuk audit tingkat server, pastikan bahwa:
    • Kontainer penyimpanan, Analitik Log, atau hub peristiwa dengan log audit yang ada dipindahkan ke wilayah target.
    • Konfigurasi audit dikonfigurasi di server target. Untuk informasi selengkapnya, lihat Audit Database SQL.
  8. Jika server Anda memiliki kebijakan penyimpanan jangka panjang (LTR), cadangan LTR yang ada tetap terkait dengan server saat ini. Karena server target berbeda, Anda dapat mengakses cadangan LTR yang lebih lama di wilayah sumber menggunakan server sumber, bahkan jika server dihapus.

Catatan

Memigrasikan database dengan cadangan LTR yang ada antara wilayah berdaulat dan publik tidak didukung karena ini mengharuskan pemindahan cadangan LTR ke server target, yang saat ini tidak dimungkinkan.

Mempersiapkan proses pemindahan

  1. Buat grup kegagalan terpisah antara setiap kumpulan elastis di server sumber dan kumpulan elastis mitranya di server target.

  2. Tambahkan semua database dalam kumpulan ke grup kegagalan. Replikasi database yang ditambahkan dimulai secara otomatis. Untuk informasi selengkapnya, lihat Menggunakan grup failover dengan SQL Database.

    Catatan

    Meskipun dimungkinkan untuk membuat grup kegagalan yang mencakup beberapa kumpulan elastis, sebaiknya Anda membuat grup kegagalan terpisah untuk setiap kumpulan. Jika Anda memiliki sejumlah besar database di beberapa kumpulan elastis yang perlu Anda pindahkan, Anda dapat menjalankan langkah-langkah persiapan secara paralel lalu memulai langkah perpindahan secara paralel. Proses ini menskalakan lebih baik dan membutuhkan lebih sedikit waktu dibandingkan dengan memiliki beberapa kumpulan elastis dalam grup failover yang sama.

Memantau proses persiapan

Anda dapat memanggil Get-AzSqlDatabaseFailoverGroup secara berkala untuk memantau replikasi database Anda dari sumber ke target. Output objek Get-AzSqlDatabaseFailoverGroup mencakup properti untuk ReplicationState:

  • ReplicationState = 2 (CATCH_UP) menunjukkan bahwa database disinkronkan dan dapat digagalkan dengan aman.
  • ReplicationState = 0 (SEEDING) menunjukkan bahwa database belum ditambahkan dan upaya untuk melakukan kegagalan akan gagal.

Menguji sinkronisasi

Setelah ReplicationState menjadi 2, sambungkan ke setiap database atau subkumpulan database menggunakan titik akhir sekunder<fog-name>.secondary.database.windows.net dan lakukan kueri terhadap database untuk memastikan konektivitas, konfigurasi keamanan yang tepat, dan replikasi data.

Memulai proses pemindahan

  1. Sambungkan ke server target menggunakan titik akhir sekunder<fog-name>.secondary.database.windows.net.
  2. Gunakan Switch-AzSqlDatabaseFailoverGroup untuk mengalihkan server sekunder menjadi yang utama dengan sinkronisasi penuh. Operasi ini berhasil, atau digulung balik.
  3. Verifikasi bahwa perintah telah berhasil diselesaikan dengan menggunakan nslook up <fog-name>.secondary.database.windows.net untuk memastikan bahwa entri DNS CNAME menunjuk ke alamat IP wilayah target. Jika perintah pengalihan gagal, CNAME tidak diperbarui.

Menghapus kumpulan elastis sumber

Setelah pemindahan selesai, hapus sumber daya di wilayah sumber untuk menghindari biaya yang tidak perlu.

  1. Hapus grup kegagalan menggunakan Remove-AzSqlDatabaseFailoverGroup.
  2. Hapus setiap kumpulan elastis sumber pada server sumber menggunakan Remove-AzSqlElasticPool.
  3. Hapus server sumber menggunakan Remove-AzSqlServer.
  4. Hapus brankas kunci, kontainer penyimpanan audit, hub peristiwa, penyewa Microsoft Entra, dan sumber daya dependen lainnya untuk berhenti ditagih untuk mereka.

Langkah berikutnya

Kelola database Anda setelah dimigrasikan.