Bagikan melalui


Memigrasikan sumber daya database ke Azure global

Penting

Sejak Agustus 2018, kami belum menerima pelanggan baru atau menyebarkan fitur dan layanan baru apa pun ke lokasi Asli Microsoft Cloud Jerman.

Berdasarkan evolusi kebutuhan pelanggan, baru-baru ini kami meluncurkan dua wilayah pusat data baru di Jerman, menawarkan residensi data pelanggan, konektivitas penuh ke jaringan cloud global Microsoft, serta harga kompetitif pasar.

Selain itu, pada 30 Sep 2020, kami mengumumkan bahwa Microsoft Cloud Jerman akan ditutup pada 29 Oktober 2021. Detail selengkapnya tersedia di sini: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Manfaatkan luasnya fungsionalitas, keamanan tingkat perusahaan, dan fitur komprehensif yang tersedia di wilayah pusat data Jerman baru kami dengan bermigrasi saat ini.

Artikel ini memiliki informasi yang dapat membantu Anda memigrasikan sumber daya database Azure dari Azure Jerman ke Azure global.

SQL Database

Untuk memigrasikan beban kerja Azure SQL Database yang lebih kecil, tanpa menjaga database yang dimigrasikan tetap online, gunakan fungsi ekspor untuk membuat file BACPAC. File BACPAC adalah file terkompresi (zip) yang berisi metadata dan data dari database SQL Server. Setelah membuat file BACPAC, Anda dapat menyalin file ke lingkungan target (misalnya, dengan menggunakan AzCopy) dan menggunakan fungsi impor untuk membangun kembali database. Perhatikan pertimbangan berikut:

  • Agar ekspor konsisten secara transaksional, pastikan bahwa salah satu kondisi berikut ini benar:
    • Tidak ada aktivitas penulisan yang terjadi selama ekspor.
    • Anda mengekspor dari salinan database SQL Anda yang konsisten secara transaksional.
  • Untuk mengekspor ke penyimpanan Azure Blob, ukuran file BACPAC dibatasi hingga 200 GB. Untuk file BACPAC yang lebih besar, ekspor ke penyimpanan lokal.
  • Jika operasi ekspor dari SQL Database memakan waktu lebih dari 20 jam, operasi mungkin dibatalkan. Periksa artikel berikut untuk tips tentang cara meningkatkan performa.

Nota

String koneksi berubah setelah operasi ekspor karena nama DNS server berubah selama ekspor.

Untuk informasi selengkapnya:

Nota

Kami menyarankan agar Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Lihat Menginstal Azure PowerShell untuk memulai. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Memigrasikan SQL Database menggunakan replikasi geografis aktif

Untuk database yang terlalu besar untuk file BACPAC, atau untuk bermigrasi dari satu cloud ke cloud lainnya dan tetap online dengan waktu henti minimum, Anda dapat mengonfigurasi replikasi geografis aktif dari Azure Jerman ke Azure global.

Penting

Mengonfigurasi replikasi geografis aktif untuk memigrasikan database ke Azure global hanya didukung menggunakan Transact-SQL (T-SQL), dan sebelum bermigrasi, Anda harus meminta pengaktifan langganan Anda untuk mendukung migrasi ke Azure global. Untuk mengirimkan permintaan, Anda harus menggunakan tautan permintaan dukungan ini.

Nota

Wilayah cloud global Azure, Jerman Barat Tengah dan Jerman Utara, adalah wilayah yang didukung untuk replikasi geografis aktif dengan cloud Azure Jerman. Jika wilayah Azure global alternatif diinginkan sebagai tujuan database akhir, rekomendasi setelah menyelesaikan migrasi ke Azure global adalah mengonfigurasi tautan replikasi geografis tambahan dari Jerman Barat Tengah atau Jerman Utara ke wilayah cloud global Azure yang diperlukan.

Untuk detail tentang biaya replikasi geografis aktif, lihat bagian berjudul Replikasi geografis aktif di harga Azure SQL Database.

Migrasi database dengan replikasi geografis aktif memerlukan server logis Azure SQL di Azure global. Anda dapat membuat server menggunakan portal, Azure PowerShell, Azure CLI, dll., tetapi mengonfigurasi replikasi geografis aktif untuk bermigrasi dari Azure Jerman ke Azure global hanya didukung menggunakan Transact-SQL (T-SQL).

Penting

Saat bermigrasi antara cloud, awalan nama server primer (Azure Jerman) dan sekunder (Azure global) harus berbeda. Jika nama server sama, menjalankan pernyataan ALTER DATABASE akan berhasil, tetapi migrasi akan gagal. Misalnya, jika awalan nama server utama adalah myserver (myserver.database.cloudapi.de), awalan nama server sekunder di Azure global tidak boleh myserver.

Perintah ALTER DATABASE ini memungkinkan Anda menentukan server target di Azure global dengan menggunakan nama server DNS yang sepenuhnya memenuhi syarat di sisi target.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedb mewakili nama database di server Azure SQL di Azure Jerman.
  • public-server.database.windows.net mewakili nama server Azure SQL yang ada di Azure global, tempat database harus dimigrasikan. Namespace "database.windows.net" diperlukan, ganti server publik dengan nama server SQL logis Anda di Azure global. Server di Azure global harus memiliki nama yang berbeda dari server utama di Azure Jerman.

Perintah dijalankan pada database master di server Azure Jerman yang menghosting database lokal yang akan dimigrasikan.

  • API mulai-salin T-SQL mengautentikasi pengguna yang masuk di server cloud publik dengan menemukan pengguna dengan login/nama pengguna SQL yang sama dalam database master server tersebut. Pendekatan ini bersifat cloud-agnostik; dengan demikian, T-SQL API digunakan untuk memulai salinan lintas cloud. Untuk izin dan informasi selengkapnya tentang topik ini lihat Membuat dan menggunakan replikasi geografis aktif dan MENGUBAH DATABASE (Transact-SQL).

  • Kecuali untuk ekstensi perintah T-SQL awal yang menunjukkan server logis Azure SQL di Azure global, sisa proses replikasi geografis aktif identik dengan eksekusi yang ada di cloud lokal. Untuk langkah-langkah terperinci untuk membuat replikasi geografis aktif, lihat Membuat dan menggunakan replikasi geografis aktif dengan pengecualian database sekunder dibuat di server logis sekunder yang dibuat di Azure global.

  • Setelah database sekunder ada di Azure global (sebagai salinan online database Azure Jerman), pelanggan dapat memulai failover database dari Azure Jerman ke Azure global untuk database ini menggunakan perintah ALTER DATABASE T-SQL (lihat tabel di bawah).

  • Setelah failover, setelah sekunder menjadi database utama di Azure global, Anda dapat menghentikan replikasi geografis aktif dan menghapus database sekunder di sisi Azure Jerman kapan saja (lihat tabel di bawah ini dan langkah-langkah yang ada dalam diagram).

  • Setelah failover, database sekunder di Azure Jerman akan terus dikenakan biaya hingga dihapus.

  • Menggunakan perintah ALTER DATABASE adalah satu-satunya cara untuk menyiapkan replikasi geografis aktif guna memigrasikan database Azure Jerman ke Azure global.

  • Tidak ada portal Microsoft Azure, Azure Resource Manager, PowerShell, atau CLI yang tersedia untuk mengonfigurasi replikasi geografis aktif untuk migrasi ini.

Untuk memigrasikan database dari Azure Jerman ke Azure global:

  1. Pilih database pengguna di Azure Jerman, misalnya, azuregermanydb

  2. Buat server logis di Azure global (cloud publik), misalnya, globalazureserver. Nama domain yang sepenuhnya memenuhi syarat (FQDN) adalah globalazureserver.database.windows.net.

  3. Mulai replikasi geografis aktif dari Azure Jerman ke Azure global dengan menjalankan perintah T-SQL ini di server di Azure Jerman. Perhatikan bahwa nama dns yang sepenuhnya memenuhi syarat digunakan untuk server globalazureserver.database.windows.netpublik . Ini untuk menunjukkan bahwa server target berada di Azure global, dan bukan Azure Jerman.

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];
    
  4. Ketika replikasi siap untuk memindahkan beban kerja baca-tulis ke server Azure global, mulai failover yang direncanakan ke Azure global dengan menjalankan perintah T-SQL ini di server Azure global.

    ALTER DATABASE [azuregermanydb] FAILOVER;
    
  5. Tautan replikasi geografis aktif dapat dihentikan sebelum atau sesudah proses failover. Eksekusi perintah T-SQL berikut setelah failover yang direncanakan menghapus tautan geo-replikasi dengan database di Azure di seluruh dunia sebagai salinan baca-tulis. Ini harus dijalankan di server logis database geo-primer saat ini (yaitu di server Azure global). Ini akan menyelesaikan proses migrasi.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];
    

    Perintah T-SQL berikut saat dijalankan sebelum failover yang direncanakan juga menghentikan proses migrasi, tetapi dalam situasi ini database di Azure Jerman akan tetap menjadi salinan baca-tulis. Perintah T-SQL ini juga harus dijalankan di server logis database geo-primer saat ini, dalam hal ini di server Azure Jerman.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];
    

Langkah-langkah untuk memigrasikan database Azure SQL dari Azure Jerman ke Azure global juga dapat diikuti menggunakan replikasi geografis aktif.

Untuk informasi selengkapnya, tabel berikut ini menunjukkan perintah T-SQL untuk mengelola failover. Perintah berikut didukung untuk replikasi geografis aktif lintas cloud antara Azure Jerman dan Azure global:

Perintah Deskripsi
UBAH DATABASE Gunakan argumen ADD SECONDARY ON SERVER untuk membuat database sekunder untuk database yang sudah ada dan memulai replikasi data
UBAH DATABASE Gunakan FAILOVER atau FORCE_FAILOVER_ALLOW_DATA_LOSS untuk mengalihkan database sekunder menjadi primer untuk memulai failover
UBAH DATABASE Gunakan REMOVE SECONDARY ON SERVER untuk mengakhiri replikasi data antara SQL Database dan database sekunder yang ditentukan.

Tampilan sistem pemantauan geo-replikasi aktif

Perintah Deskripsi
sys.geo_replication_links Mengembalikan informasi tentang semua tautan replikasi yang ada untuk setiap database di server Azure SQL Database.
sys.dm_geo_replication_link_status Mendapatkan waktu replikasi terakhir, jeda replikasi terakhir, dan informasi lain tentang tautan replikasi untuk database SQL tertentu.
sys.dm_operation_status Memperlihatkan status untuk semua operasi database termasuk status tautan replikasi.
sp_tunggu_sinkronisasi_salinan_database Menyebabkan aplikasi menunggu hingga semua transaksi yang dilakukan direplikasi dan diakui oleh database sekunder aktif.

Migrasi cadangan retensi jangka panjang untuk SQL Database

Memigrasikan database dengan replikasi geografis atau file BACPAC tidak menyalin cadangan retensi jangka panjang, yang mungkin dimiliki database di Azure Jerman. Untuk memigrasikan cadangan retensi jangka panjang yang ada ke wilayah Azure global target, Anda dapat menggunakan prosedur pencadangan retensi jangka panjang COPY.

Nota

Metode salinan cadangan LTR yang didokumenkan di sini hanya dapat menyalin cadangan LTR dari Azure Jerman ke Azure global. Menyalin cadangan PITR menggunakan metode ini tidak didukung.

Prasyarat

  1. Database sasaran tempat Anda menyalin cadangan LTR di Azure global harus sudah ada sebelum Anda memulai penyalinannya. Disarankan agar Anda terlebih dahulu memigrasikan database sumber menggunakan replikasi geografis aktif lalu memulai salinan cadangan LTR. Ini akan memastikan bahwa cadangan database disalin ke database tujuan yang benar. Langkah ini tidak diperlukan, jika Anda menyalin cadangan LTR dari database yang dihilangkan. Saat menyalin cadangan LTR dari database yang dihapus, DatabaseID dummy akan dibuat di wilayah target.
  2. Instal Modul PowerShell Az ini
  3. Sebelum memulai, pastikan bahwa peran Azure RBAC yang diperlukan diberikan pada cakupan langganan atau grup sumber daya. Catatan: Untuk mengakses cadangan LTR milik server yang dihilangkan, izin harus diberikan dalam cakupan langganan server tersebut. .

Keterbatasan

  • Grup Failover tidak didukung. Ini berarti bahwa pelanggan yang memigrasikan database Azure Jerman perlu mengelola string koneksi sendiri selama failover.
  • Tidak ada dukungan untuk portal Microsoft Azure, API Azure Resource Manager, PowerShell, atau CLI. Ini berarti bahwa setiap migrasi Azure Jerman perlu mengelola penyiapan dan failover replikasi geografis aktif melalui T-SQL.
  • Pelanggan tidak dapat membuat lebih dari satu instans geo-sekunder di Azure secara global untuk database di Azure Jerman.
  • Pembuatan geo sekunder harus dimulai dari wilayah Azure Jerman.
  • Pelanggan dapat memigrasikan database dari Azure Jerman hanya ke Azure global. Saat ini tidak ada migrasi lintas cloud lain yang didukung.
  • Pengguna Azure AD di database pengguna Azure Jerman dimigrasikan tetapi tidak tersedia di penyewa Azure AD baru tempat database yang dimigrasikan berada. Untuk mengaktifkan pengguna ini, mereka harus dihapus dan dibuat ulang secara manual menggunakan pengguna Azure AD saat ini yang tersedia di penyewa Azure AD baru, tempat database yang baru dimigrasikan berlokasi.

Menyalin cadangan retensi jangka panjang menggunakan PowerShell

Perintah PowerShell baru Copy-AzSqlDatabaseLongTermRetentionBackup telah diperkenalkan, yang dapat digunakan untuk menyalin cadangan retensi jangka panjang dari Azure Jerman ke wilayah global Azure.

  1. Salin cadangan LTR menggunakan nama cadangan Contoh berikut menunjukkan bagaimana Anda dapat menyalin cadangan LTR dari Azure Jerman ke wilayah global Azure, menggunakan nama cadangan.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN 
  1. Salin cadangan LTR menggunakan resourceID cadangan Contoh berikut menunjukkan bagaimana Anda dapat menyalin cadangan LTR dari Azure Jerman ke wilayah global Azure, menggunakan resourceID cadangan. Contoh ini juga dapat digunakan untuk menyalin cadangan database yang dihapus.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Keterbatasan

  • Pemulihan point-in-time (PITR) hanya dilakukan pada database utama, hal ini sesuai dengan desain. Saat memigrasikan database dari Azure Jerman menggunakan Geo-DR, pencadangan PITR akan dimulai pada server utama yang baru setelah terjadinya failover. Namun, cadangan PITR yang ada (pada primer sebelumnya di Azure Jerman) tidak akan dimigrasikan. Jika Anda memerlukan cadangan PITR untuk mendukung skenario pemulihan point-in-time, Anda perlu memulihkan database dari cadangan PITR di Azure Jerman lalu memigrasikan database yang dipulihkan ke Azure global.
  • Kebijakan penyimpanan jangka panjang tidak dimigrasikan dengan database. Jika Anda memiliki kebijakan retensi jangka panjang (LTR) pada database Anda di Azure Jerman, Anda perlu menyalin dan membuat ulang kebijakan LTR secara manual pada database baru setelah bermigrasi.

Meminta akses

Untuk memigrasikan database dari Azure Jerman ke Azure global menggunakan replikasi geografis, langganan Anda di Azure Jerman perlu diaktifkan agar berhasil mengonfigurasi migrasi lintas cloud.

Untuk mengaktifkan langganan Azure Jerman, Anda harus menggunakan tautan berikut untuk membuat permintaan dukungan migrasi:

  1. Telusuri permintaan dukungan migrasi berikut.

  2. Pada tab Dasar, masukkan Geo-DR migrasi sebagai Ringkasan, lalu pilih Berikutnya: Solusi

    formulir permintaan dukungan baru

  3. Tinjau Langkah yang Direkomendasikan, lalu pilih Berikutnya: Detail.

    informasi permintaan dukungan yang diperlukan

  4. Pada halaman detail, berikan hal berikut:

    1. Dalam kotak Deskripsi, masukkan ID langganan Azure global untuk dimigrasikan. Untuk memigrasikan database ke lebih dari satu langganan, tambahkan daftar ID Azure global yang ingin Anda migrasikan databasenya.
    2. Berikan informasi kontak: nama, nama perusahaan, email, atau nomor telepon.
    3. Lengkapi formulir, lalu pilih Berikutnya: Tinjau + buat.

    detail permintaan dukungan

  5. Tinjau permintaan dukungan, lalu pilih Buat.

Anda akan dihubungi setelah permintaan diproses.

Azure Cosmos DB

Anda dapat menggunakan Alat Migrasi Data Azure Cosmos DB untuk memigrasikan data ke Azure Cosmos DB. Azure Cosmos DB Data Migration Tool adalah solusi sumber terbuka yang mengimpor data ke Azure Cosmos DB dari berbagai sumber termasuk: file JSON, MongoDB, SQL Server, file CSV, penyimpanan Azure Table, Amazon DynamoDB, HBase, dan kontainer Azure Cosmos.

Alat Migrasi Data Azure Cosmos DB tersedia sebagai alat antarmuka grafis atau sebagai alat baris perintah. Kode sumber tersedia di Azure Cosmos DB Data Migration Tool repositori GitHub. Versi alat yang dikompilasi tersedia di Pusat Unduhan Microsoft.

Untuk memigrasikan sumber daya Azure Cosmos DB, kami sarankan Anda menyelesaikan langkah-langkah berikut:

  1. Tinjau persyaratan waktu aktif aplikasi dan konfigurasi akun untuk menentukan rencana tindakan terbaik.
  2. Kloning konfigurasi akun dari Azure Jerman ke wilayah baru dengan menjalankan alat migrasi data.
  3. Jika menggunakan jendela pemeliharaan dimungkinkan, salin data dari sumber ke tujuan dengan menjalankan alat migrasi data.
  4. Jika menggunakan jendela pemeliharaan bukan opsi, salin data dari sumber ke tujuan dengan menjalankan alat, lalu selesaikan langkah-langkah berikut:
    1. Gunakan pendekatan berbasis konfigurasi untuk membuat perubahan pada baca/tulis dalam aplikasi.
    2. Selesaikan sinkronisasi pertama kali.
    3. Siapkan sinkronisasi tambahan dan ikuti pembaruan dari umpan perubahan.
    4. Arahkan pengaturan ke akun baru dan validasi aplikasi.
    5. Hentikan penulisan ke akun lama, validasi bahwa umpan perubahan telah tertangkap, lalu arahkan penulisan ke akun baru.
    6. Hentikan alat dan hapus akun lama.
  5. Jalankan alat untuk memvalidasi bahwa data konsisten di seluruh akun lama dan baru.

Untuk informasi selengkapnya:

Cache Azure untuk Redis (Azure Cache for Redis)

Anda memiliki beberapa opsi jika Anda ingin memigrasikan instans Azure Cache for Redis dari Azure Jerman ke Azure global. Opsi yang Anda pilih tergantung pada kebutuhan Anda.

Opsi 1: Terima kehilangan data, buat instans baru

Pendekatan ini paling masuk akal ketika kedua kondisi berikut ini benar:

  • Anda menggunakan Azure Cache for Redis sebagai cache data sementara.
  • Aplikasi Anda akan mengisi ulang data cache secara otomatis di wilayah baru.

Untuk bermigrasi dengan kehilangan data dan membuat instans baru:

  1. Buat instans Azure Cache for Redis baru di wilayah target baru.
  2. Perbarui aplikasi Anda untuk menggunakan instans baru di wilayah baru.
  3. Hapus instans Azure Cache for Redis lama di wilayah sumber.

Opsi 2: Menyalin data dari instans sumber ke instans target

Anggota tim Azure Cache for Redis menulis alat sumber terbuka yang menyalin data dari satu instans Azure Cache for Redis ke instans lain tanpa memerlukan fungsionalitas impor atau ekspor. Lihat langkah 4 dalam langkah-langkah berikut untuk informasi tentang alat ini.

Untuk menyalin data dari instans sumber ke instans target:

  1. Buat VM di wilayah sumber. Jika himpunan data Anda di Azure Cache for Redis besar, pastikan Anda memilih ukuran VM yang relatif kuat untuk meminimalkan waktu penyalinan.
  2. Buat instans Azure Cache for Redis baru di wilayah target.
  3. Bersihkan data dari instans target . Pastikan tidak melakukan flush dari instans sumber. Penghapusan diperlukan karena alat salin tidak menimpa kunci yang ada di lokasi target.
  4. Gunakan alat berikut untuk menyalin data secara otomatis dari instans Azure Cache for Redis sumber ke instans Azure Cache for Redis target: Sumber alat dan unduhan alat.

Nota

Proses ini dapat memakan waktu lama tergantung pada ukuran himpunan data Anda.

Opsi 3: Ekspor dari instans sumber, impor ke instans tujuan

Pendekatan ini memanfaatkan fitur yang hanya tersedia di tingkat Premium.

Untuk mengekspor dari instans sumber dan mengimpor ke instans tujuan:

  1. Buat instans Azure Cache for Redis tingkat Premium baru di wilayah target. Gunakan ukuran yang sama dengan sumber instans Azure Cache for Redis.

  2. Ekspor data dari cache sumber atau gunakan cmdlet PowerShellExport-AzRedisCache.

    Nota

    Akun Azure Storage ekspor harus berada di wilayah yang sama dengan instans cache.

  3. Salin blob yang diekspor ke akun penyimpanan di wilayah tujuan (misalnya, dengan menggunakan AzCopy).

  4. Impor data ke cache tujuan atau gunakan cmdlet PowerShellImport-AzRedisCAche.

  5. Konfigurasi ulang aplikasi Anda untuk menggunakan instans target Azure Cache for Redis.

Opsi 4: Tulis data ke dua instans Azure Cache for Redis, baca dari satu instans

Untuk pendekatan ini, Anda harus memodifikasi aplikasi Anda. Aplikasi perlu menulis data ke lebih dari satu instans cache saat membaca dari salah satu instans cache. Pendekatan ini masuk akal jika data yang disimpan di Azure Cache for Redis memenuhi kriteria berikut:

  • Data disegarkan secara teratur.
  • Semua data ditulis ke Azure Cache for Redis yang dituju.
  • Anda memiliki cukup waktu untuk semua data diperbarui.

Untuk informasi selengkapnya:

PostgreSQL dan MySQL

Untuk informasi selengkapnya, lihat artikel di bagian "Mencadangkan dan memigrasikan data" di PostgreSQL dan MySQL.

PostgreSQL dan MySQL

Langkah berikutnya

Pelajari tentang alat, teknik, dan rekomendasi untuk memigrasikan sumber daya dalam kategori layanan berikut: