FAQ tentang penggunaan Azure Database Migration Service

Azure Database Migration Service adalah layanan terkelola penuh yang dirancang untuk mengaktifkan migrasi mulus dari beberapa sumber database ke platform Data Azure dengan waktu henti minimal. Layanan ini saat ini dalam Ketersediaan Umum, dengan upaya pengembangan berkelanjutan yang berfokus pada:

• Keandalan dan performa.
• Penambahan iteratif pasangan target sumber.
• Investasi berkelanjutan dalam migrasi bebas gesekan.

Layanan saat ini mendukung berbagai pasangan sumber/target, atau skenario migrasi. Untuk daftar lengkap status setiap skenario migrasi yang tersedia, lihat artikel Status skenario migrasi yang didukung oleh Azure Database Migration Service.

Saat bermigrasi dari SQL Server, sumber yang didukung untuk Azure Database Migration Service adalah SQL Server 2008 dan versi yang lebih baru. Jika Anda menggunakan Azure Data Studio dengan ekstensi Migrasi SQL, sumber yang didukung adalah SQL Server 2008 hingga SQL Server 2022.

Anda bisa menggunakan Azure Database Migration Service untuk melakukan migrasi offline dan online. Dengan migrasi offline, waktu henti aplikasi dimulai saat migrasi dimulai. Dengan migrasi online, waktu henti dibatasi sampai waktu untuk memotong di akhir migrasi. Kami menyarankan agar Anda menguji migrasi luring untuk menentukan apakah waktu henti dapat diterima; jika tidak, lakukan migrasi daring.

Azure Database Migration Service adalah metode yang lebih dipilih untuk migrasi database ke Microsoft Azure dalam skala besar. Untuk informasi selengkapnya tentang bagaimana Azure Database Migration Service dibandingkan dengan alat migrasi database Microsoft lainnya, dan untuk rekomendasi tentang menggunakan layanan untuk berbagai skenario, lihat Membedakan Alat dan Layanan Migrasi Database Microsoft.

Azure Migrate membantu migrasi komputer virtual lokal ke Azure IaaS. Layanan ini menilai kecocokan migrasi komputer lokal, pengukuran berbasis performa, dan memberikan estimasi biaya untuk menjalankan komputer virtual lokal Anda di Azure. Azure Migrate berguna untuk migrasi lift-and-shift beban kerja berbasis VM lokal ke VM Azure IaaS. Namun, tidak seperti Azure Database Migration Service, Azure Migrate bukan penawaran layanan migrasi database khusus untuk platform database relasional Azure PaaS seperti Azure SQL Database atau Azure SQL Managed Instance.

Tidak. Database Migration Service tidak menyimpan data pelanggan.

Untuk target Azure SQL VM dan Azure SQL MI, DMS menggunakan migrasi fisik yaitu, menggunakan pencadangan dan pemulihan. Seperti yang dijelaskan di bawah ini, mode migrasi yang dipilih menentukan bagaimana data tetap konsisten antara sumber dan target.

• Migrasi offline: Selama migrasi offline ke Azure SQL VM dan target Azure SQL MI, waktu henti aplikasi dimulai saat migrasi dimulai. DMS akan memulihkan semua file cadangan ke Target, selama file cadangan terbaru dari sumber telah ditransfer ke penyimpanan jaringan SMB atau ke kontainer blob Azure (sesuai konfigurasi migrasi). Jika cadangan diambil dengan opsi CHECKSUM, operasi pemulihan DMS secara otomatis melakukan validasi. Dengan tidak adanya checksum, integritas cadangan secara eksplisit diperiksa sebelum memulihkan. Ini memastikan bahwa file pemulihan identik dengan file cadangan dan karenanya memiliki data yang sama. Anda dapat memverifikasi semua file cadangan termasuk nama file cadangan terakhir dari sumber dengan file cadangan diterapkan/dipulihkan pada target yang ditampilkan di halaman pemantauan migrasi DMS dan memvalidasi checksum masing-masing.

• Migrasi online: Selama migrasi online ke Azure SQL VM dan target Azure SQL MI, waktu henti dimulai setelah Anda memulai cutover migrasi bersama dengan menghentikan aplikasi. DMS akan memulihkan semua file cadangan ke Target, selama file cadangan terbaru dari sumber telah ditransfer ke penyimpanan jaringan SMB atau ke kontainer blob Azure (sesuai konfigurasi migrasi). Setelah Anda menekan tombol cutover, DMS menunjukkan jumlah untuk file cadangan tertunda (jika ada) yang ada di penyimpanan jaringan SMB atau kontainer blob Azure dan belum diterapkan/dipulihkan pada target. Jika cadangan diambil dengan opsi CHECKSUM, operasi pemulihan DMS secara otomatis melakukan validasi. Dengan tidak adanya checksum, integritas cadangan secara eksplisit diperiksa sebelum memulihkan. Ini memastikan bahwa file pemulihan identik dengan file cadangan dan karenanya memiliki data yang sama. Anda dapat memverifikasi semua file cadangan termasuk nama file cadangan terakhir dari sumber dengan file cadangan diterapkan/dipulihkan pada target yang ditampilkan di halaman pemantauan migrasi DMS dan memvalidasi checksum masing-masing.

Untuk target Azure SQL DB, DMS melakukan migrasi logis dalam kasus Azure SQL DB yaitu, ia menyalin data dari tabel database SQL sumber dan menulisnya ke tabel Target Azure SQL DB. Karena DMS hanya mendukung migrasi offline ke Azure SQL DB, waktu henti aplikasi dimulai saat migrasi dimulai. Anda dapat memantau dan memvalidasi jumlah baris yang dibaca (dari tabel database sumber) dan disalin (ditulis ke tabel Azure SQL DB target) dari halaman pemantauan migrasi. Sebagai konfirmasi tambahan, Anda dapat menjalankan TSQL di bawah ini untuk mendapatkan checksum baik di database sumber maupun tujuan dan memvalidasi sumber dan memulihkan data yang identik.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

Catatan: Asalkan tidak ada aplikasi/s yang menulis ke sumber atau Target DB. Anda juga dapat memanfaatkan alat seperti alat Perbandingan Database untuk perbandingan data.

Daftar berikut berisi sumber daya Azure yang mungkin dibuat di belakang layar untuk melakukan migrasi data. Layanan yang digunakan dapat bervariasi menurut skenario migrasi.

• Azure Monitor
• Azure VM
• Azure Storage
• Azure Service Bus
• Azure Data Factory

Secara internal, DMS mempertahankan penyimpanan metadata yang mencakup informasi tentang lokasi jaringan, kredensial, file cadangan, dan tugas yang selesai. Kredensial dan bidang yang dipilih, seperti kunci akun, dienkripsi. Data, seperti nama tabel yang mungkin disertakan dalam telemetri, di-hash. Nama pengguna mungkin muncul dalam teks biasa dalam log layanan tetapi kata sandi tidak akan pernah. Telemetri dipisahkan berdasarkan wilayah, diatur oleh kebijakan retensi dan hanya tersedia untuk personel yang berwenang dalam Microsoft untuk tujuan pemecahan masalah yang valid. Nama sumber daya Azure, seperti nama server dan database, ikuti aturan untuk sumber daya Azure.

DMS (Klasik) menggunakan topik Azure Bus Layanan untuk memfasilitasi komunikasi antar lapisan komputasi. Topik Azure Bus Layanan unik untuk setiap instans DMS dan semua data pribadi dienkripsi.

Azure SQL Managed Instance dan SQL Server di Azure Virtual Machines

Skema dan data dimigrasikan menggunakan pencadangan dan pemulihan. Pelanggan memiliki pilihan untuk memulihkan dari berbagi jaringan atau langsung dari kontainer penyimpanan. File yang berisi data performa Windows dapat digunakan untuk memberikan rekomendasi ukuran beban kerja opsional (tetapi sangat direkomendasikan).

Database Azure SQL

Migrasi ke Azure SQL Database dilakukan dalam dua langkah. Langkah pertama adalah migrasi skema. DMS (Klasik) menggunakan SQL Management Objects (SMO) untuk migrasi skema. Langkah kedua adalah migrasi data aktual. SqlBulkCopy digunakan untuk melakukan migrasi data. DMS tidak mendukung migrasi skema. Data dimigrasikan menggunakan Azure Data Factory. Secara opsional tetapi sangat disarankan, file yang berisi data performa Windows dapat digunakan untuk memberikan rekomendasi ukuran beban kerja.

Azure Database untuk PostgreSQL

Dalam skenario ini, pengguna akhir mengekstrak metadata, dalam hal ini skema, menggunakan pg_dump utilitas baris perintah dan pg_restore . Saat mengonfigurasi perubahan pengambilan data untuk PostgreSQL, DMS secara internal menggunakan pg_dump dan pg_restore untuk melakukan seeding awal untuk CDC. Data disimpan dalam penyimpanan sementara terenkripsi yang hanya dapat diakses oleh instans DMS Anda. File yang berisi data performa Windows dapat digunakan untuk memberikan rekomendasi ukuran beban kerja opsional (tetapi sangat direkomendasikan).

Azure Database untuk MySQL

Dalam skenario ini, ekstraksi dan migrasi skema dilakukan oleh DMS (Klasik) menggunakan mysql-net/MySql Koneksi or. Jika memungkinkan, replikasi binlog MySQL digunakan untuk mereplikasi perubahan data dan skema. Kode kustom digunakan untuk menyinkronkan perubahan di mana replikasi binlog tidak dapat digunakan.

MongoDB ke Azure Cosmos DB

DMS mengekstrak dan menyisipkan data dari MongoDB ke Cosmos DB. Ini juga menawarkan opsi untuk mengekstrak data dari cadangan BSON atau JSON.

Untuk cadangan BSON, DMS menggunakan data dalam format dalam bsondump folder yang sama dalam kontainer blob. DMS hanya mencari file metadata menggunakan format collection.metadata.json.

Untuk cadangan JSON, DMS akan membaca file di folder kontainer blob bernama sesuai database yang berisi. Dalam setiap folder database, DMS hanya menggunakan file data yang data ditempatkan di subfolder. DMS hanya melihat file yang ditempatkan di metadata subfolder dan diberi nama menggunakan format collection.json untuk metadata.

Oracle ke Azure SQL Database

Dalam skenario ini, laporan AWR atau file Windows perfmon digunakan untuk memberikan rekomendasi ukuran beban kerja opsional (tetapi sangat disarankan). Pengguna yang melakukan migrasi menggunakan Toolkit Konversi Skema Database untuk melakukan migrasi skema untuk menyiapkan database target.

Oracle ke Azure Database for PostgreSQL

Sama seperti Oracle ke Azure SQL Database, dalam skenario ini, laporan AWR atau file Windows perfmon digunakan untuk memberikan rekomendasi ukuran beban kerja opsional (tetapi sangat direkomendasikan). Pustaka ora2pg digunakan untuk mengekstrak skema dan memigrasikan data secara manual oleh pengguna yang melakukan migrasi.

DMS (Klasik) bergantung pada konfigurasi jaringan pelanggan. Jika sumber migrasi menggunakan titik akhir privat, kami menggunakan titik akhir privat, yang merupakan konfigurasi pilihan. Kami menggunakan titik akhir publik jika itu adalah satu-satunya opsi.

DMS menggunakan ADF sangat di belakang layar untuk penjadwalan dan koordinasi pergerakan data. Selain itu, Runtime Integrasi yang Dihost sendiri tidak berbeda dari yang mungkin sudah Anda gunakan untuk alur ADF Anda sendiri. Untuk informasi selengkapnya tentang masalah firewall dan server proksi, lihat Membuat dan mengonfigurasi runtime integrasi yang dihost sendiri.

Semua data pelanggan dienkripsi saat tidak aktif. Beberapa metadata, termasuk tetapi tidak terbatas pada nama server logis dan nama database, serta status migrasi dan kemajuan migrasi muncul di log layanan yang tidak dienkripsi.

Semua data saat transit dilindungi dengan enkripsi TLS 1.2 secara default. Klien warisan yang memerlukan versi TLS yang lebih lama, memerlukan versi yang diperlukan yang diaktifkan di halaman portal DMS (Klasik). Untuk DMS, komputer tempat Runtime Integrasi yang Dihost sendiri diinstal dapat dikonfigurasi untuk memungkinkan pengaturan TLS yang diperlukan untuk mengakomodasi klien warisan. Untuk informasi selengkapnya tentang konfigurasi TLS untuk SQL Server, lihat KB3135244 - dukungan TLS 1.2 untuk Microsoft SQL Server.

Jika memungkinkan, titik akhir privat digunakan. Jika titik akhir privat bukan opsi, titik akhir publik digunakan untuk komunikasi antar lapisan layanan. Terlepas dari jenis titik akhir, semua sumber daya didedikasikan/dilingkupkan ke instans DMS tertentu dan diamankan dengan kredensial unik.

Kami tidak mendukung Kunci yang Dikelola Pelanggan untuk enkripsi data dalam sarana data atau sarana kontrol kami. Namun, semua data pelanggan dienkripsi saat tidak aktif menggunakan kunci yang dikelola oleh layanan. Beberapa metadata, termasuk tetapi tidak terbatas pada nama server logis dan nama database, serta status migrasi dan kemajuan muncul di log layanan dalam bentuk yang tidak terenkripsi.

Semua data saat transit dienkripsi dengan enkripsi TLS 1.2 secara default. Halaman portal DMS (Klasik) memungkinkan versi TLS yang lebih lama digunakan untuk klien warisan. Untuk DMS, mesin tempat Integration Runtime yang Dihost sendiri diinstal, dapat dikonfigurasi untuk memungkinkan manajemen pengaturan TLS mengakomodasi klien warisan. Untuk informasi selengkapnya tentang konfigurasi TLS untuk SQL Server, lihat KB3135244 - dukungan TLS 1.2 untuk Microsoft SQL Server.

Kami tidak mengekspos kemampuan untuk mengenkripsi data pada kontrol atau bidang data kami dengan Kunci yang Dikelola Pelanggan. Semua data pelanggan dihapus saat instans DMS dihapus kecuali log layanan. Log layanan DMS disimpan hanya selama 30 hari.

TDE

DMS mendukung migrasi Customer Managed Keys (CMK) ke Azure SQL for Transparent Database Encryption (TDE). Untuk instruksi langkah demi langkah untuk memigrasikan kunci TDE Anda, lihat Tutorial: Memigrasikan database yang didukung TDE (pratinjau) ke Azure SQL di Azure Data Studio.

Enkripsi sel

Enkripsi tingkat sel ditangani pada tingkat skema. Alat migrasi skema memigrasikan semua objek skema termasuk fungsi dan prosedur tersimpan yang diperlukan untuk menerapkan enkripsi tingkat sel.

Always Encrypted

DMS saat ini tidak mendukung migrasi Always Encrypted melalui skenario di mana baris data individual dimigrasikan antara sumber dan target. Kolom yang dienkripsi melalui Always Encrypted dimigrasikan seperti yang diharapkan dalam skenario yang menggunakan pencadangan/pemulihan, seperti pindah ke Azure SQL VM atau Instans Terkelola Azure SQL dari instans SQL Server yang ada.

Kami tidak menerapkan kontrol akses sadar lokasi apa pun di luar apa yang sudah tersedia di Azure. Semua data yang terkait dengan instans DMS berada di wilayah yang sama dengan sumber daya DMS.

Layanan kami digunakan di berbagai lingkungan dengan kontrol internal dan proses bisnis yang berbeda. DMS memindahkan data dari dan ke mana saja akun yang digunakannya memiliki akses. Pengguna bertanggung jawab untuk memahami izin dan kontrol internal lingkungan tempat mereka bekerja. Sangat penting untuk memastikan bahwa akun yang digunakan DMS untuk terhubung ke sumber memiliki akses untuk melihat semua data yang dimaksudkan untuk dimigrasikan dari sumbernya.

Injeksi VNET adalah tindakan menambahkan sumber daya Azure yang berada dalam penyewa Microsoft, ke subnet di VNet di bawah penyewa pelanggan. Pendekatan ini diambil dengan DMS untuk memungkinkan kami mengelola komputasi atas nama pelanggan, sambil tetap mempertahankan akses ke sumber daya pelanggan. Karena jaringan berada dalam langganan pelanggan, Microsoft tidak dapat mengelola VM di luar mengeluarkan perintah Mulai, Hentikan, Hapus, atau Sebarkan. Semua tindakan manajemen lainnya yang memerlukan akses ke VM memerlukan permintaan dan persetujuan dukungan yang dimulai pelanggan.

Ada beberapa prasyarat yang diperlukan untuk memastikan bahwa Azure Database Migration Service berjalan lancar saat melakukan migrasi database. Beberapa prasyarat berlaku di semua skenario (pasangan target sumber) yang didukung oleh layanan, sementara prasyarat lain khusus untuk skenario tertentu.

Prasyarat Azure Database Migration Service yang umum di semua skenario migrasi yang didukung, mencakup kebutuhan untuk:

• Buat Microsoft Azure Virtual Network untuk Azure Database Migration Service dengan menggunakan model penyebaran Azure Resource Manager, yang menyediakan konektivitas site-to-site ke server sumber lokal Anda dengan menggunakan ExpressRoute atau VPN.
• Memastikan bahawa aturan Kelompok Keamanan Jaringan dari jaringan virtual Anda, tidak memblokir port 443 untuk ServiceTags dari ServiceBus, Storage, dan AzureMonitor. Untuk mengetahui detail selengkapnya tentang pemfilteran lalu lintas NSG jaringan virtual, lihat artikel Memfilter lalu lintas jaringan dengan kelompok keamanan jaringan.
• Saat menggunakan appliance firewall di depan database sumber, Anda mungkin perlu menambahkan aturan firewall untuk mengizinkan Azure Database Migration Service mengakses database sumber untuk migrasi.

Untuk daftar semua prasyarat yang diperlukan untuk mempersaingkan skenario migrasi tertentu menggunakan Azure Database Migration Service, lihat tutorial terkait dalam dokumentasi Azure Database Migration Service.

Anda mungkin perlu menambahkan aturan firewall yang mengizinkan Azure Database Migration Service mengakses database sumber Anda untuk migrasi. Alamat IP untuk layanan ini bersifat dinamis, tetapi jika Anda menggunakan ExpressRoute, alamat ini secara privat ditetapkan oleh jaringan perusahaan Anda. Cara termudah untuk mengidentifikasi alamat IP yang sesuai adalah dengan melihat ke dalam grup sumber daya yang sama dengan sumber daya Azure Database Migration Service yang tersedia untuk menemukan Antarmuka Jaringan terkait. Biasanya nama sumber daya Antarmuka Jaringan dimulai dengan awalan NIC dan diikuti oleh karakter unik dan urutan angka, misalnya, 'NIC-jj6tnztnmarpsskr82rbndyp''. Dengan memilih sumber daya antarmuka jaringan ini, Anda dapat melihat alamat IP yang perlu disertakan dalam daftar yang diizinkan pada halaman portal Azure gambaran umum sumber daya.

Anda mungkin juga perlu menyertakan sumber port yang didengarkan SQL Server pada daftar yang diizinkan. Secara default, ini adalah port 1433, tetapi SQL Server sumber dapat dikonfigurasi untuk mendengarkan pada port lain juga. Dalam hal ini, Anda perlu menyertakan port tersebut pada daftar yang diizinkan juga. Anda dapat menentukan port yang didengarkan SQL Server dengan menggunakan kueri DMV:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Anda juga dapat menentukan port yang didengar SQL Server dengan mengkueri log galat SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Sementara beberapa tutorial Microsoft yang dapat memandu Anda melalui proses pengaturan jaringan virtual, dokumentasi resmi muncul dalam artikel Azure Virtual Network.

Selama migrasi database yang khas dan sederhana, Anda:

1. Membuat database target.
2. Menilai database sumber Anda.
   • Untuk migrasi homogen, menilai database Anda yang telah ada dengan menggunakan DMA.
   • Untuk migrasi heterogen (dari sumber yang bersaing), menilai database Anda yang ada dengan SSMA. Anda juga menggunakan SSMA untuk mengonversi objek database dan memigrasikan skema ke platform target Anda.
3. Buat instans Azure Database Migration Service.
4. Membuat proyek migrasi yang menentukan database sumber, database target, dan tabel untuk dimigrasikan.
5. Memulai beban penuh.
6. Memilih validasi berikutnya.
7. Melakukan peralihan manual lingkungan produksi Anda ke database baru berbasis cloud.

Jika Anda mengalami masalah saat menyambungkan ke sistem database sumber saat mengerjakan migrasi, buat komputer virtual di subnet jaringan virtual yang sama yang Anda pakai untuk menyiapkan instans DMS Anda. Di komputer virtual, Anda harus dapat menjalankan pengujian koneksi, seperti menggunakan file UDL untuk menguji koneksi ke SQL Server atau mengunduh Robo 3T untuk menguji koneksi MongoDB. Jika pengujian koneksi berhasil, Anda seharusnya tidak mengalami masalah dengan menyambungkan ke database sumber Anda. Jika pengujian koneksi tidak berhasil, hubungi admin jaringan Anda.

Jika pengguna secara eksplisit menghentikan Azure Database Migration Service (DMS) atau jika layanan tidak aktif selama 24 jam, layanan dalam status dihentikan atau dijeda otomatis. Dalam setiap kasus, layanan tidak tersedia dan dalam status berhenti. Untuk melanjutkan migrasi aktif, hidupkan ulang layanan.

Anda bisa melakukan beberapa hal untuk mempercepat migrasi database Anda menggunakan layanan:

• Gunakan Tingkat Harga Tujuan Umum multi CPU saat Anda membuat instans layanan untuk memungkinkan layanan memanfaatkan beberapa vCPU untuk paralelisasi dan transfer data yang lebih cepat.
• Tingkatkan sementara instans target Azure SQL Database Anda ke SKU tingkat Premium selama operasi migrasi data untuk meminimalkan pembatasan Azure SQL Database yang dapat memengaruhi aktivitas transfer data saat menggunakan SKU tingkat bawah.

Langkah berikutnya

• Apa itu Azure Database Migration Service.