Praktik terbaik AWS Database Migration Service

Untuk menggunakan AWS Database Migration Service (AWS DMS) paling efektif, lihat rekomendasi bagian ini tentang cara paling efisien untuk melakukan migrasi data Anda.

Perencanaan migrasi untuk AWS Database Migration Service

Ketika merencanakan migrasi basis data menggunakan AWS Database Migration Service, pertimbangkan hal berikut:

• Untuk Connect pada sumber dan target basis data Anda ke instans replikasi AWS DMS, lakukan konfigurasi jaringan. Melakukan hal ini bisa sesederhana menghubungkan dua sumber daya AWS virtual private cloud (VPC) sebagai instans replikasi Anda. Ini dapat berkisar hingga konfigurasi yang lebih kompleks seperti menghubungkan basis data On-Premise ke instans DB Amazon RDS melalui Jaringan Pribadi Virtual (VPN). Untuk informasi selengkapnya, lihat Konfigurasi jaringan untuk migrasi basis data.

• Titik akhir sumber dan target — Pastikan bahwa Anda mengetahui informasi apa dan tabel dalam sumber basis data yang perlu dilakukan migrasi ke basis data target. Migrasi skema Support Basic AWS DMS, termasuk penciptaan tabel dan kunci primer. Namun, AWS DMS tidak secara otomatis membuat indeks sekunder, kunci asing, akun pengguna, dan sebagainya, dalam basis data target. Tergantung pada mesin basis data sumber dan target Anda, Anda mungkin perlu pengaturan catatan tambahan atau memodifikasi pengaturan lain untuk basis data sumber atau target. Untuk informasi selengkapnya, lihat Sumber untuk migrasi data dan Target migrasi data.

• Skema dan migrasi kode — AWS DMS tidak melakukan konversi skema atau kode. Anda dapat menggunakan perangkat seperti Oracle SQL Developer, MySQL Workbench, dan pgAdmin III untuk mengkonversi skema Anda. Untuk mengkonversi skema yang ada untuk mesin basis data yang berbeda, Anda dapat menggunakan AWS Schema Conversion Tool (AWS SCT). Cara ini dapat membuat skema target dan dapat menghasilkan dan membuat seluruh skema: tabel, indeks, tampilan, dan sebagainya. Anda juga dapat menggunakan perangkat untuk dapat mengubah PL/SQL atau TSQL ke PgSQL dan beberapa format lainnya. Untuk informasi selengkapnya tentang AWS SCT, lihat Panduan Pengguna AWS SCT.

• Jenis data yang tidak didukung — Pastikan bahwa Anda dapat mengubah tipe data sumber ke tipe data yang setara untuk basis data target. Untuk informasi selengkapnya tentang jenis data yang didukung, lihat bagian sumber atau target untuk menyimpan data Anda.

• Hasil penulisan Support diagnostik — Saat merencanakan migrasi, sebaiknya jalankan penulisan dukungan diagnostik. Dengan hasil dari penulisan ini, Anda dapat menemukan informasi lanjutan tentang kemungkinan kegagalan migrasi.

  Jika penulisan Support tersedia untuk basis data Anda, untuk mengunduh dapat menggunakan tautan dalam topik penulisan yang sesuai di bagian berikut. Setelah memeriksa dan meninjau penulisan ini, Anda dapat menjalankannya sesuai dengan prosedur yang dijelaskan dalam topik penulisan di lingkungan setempat Anda. Ketika selesai menjalankan penulisan, Anda dapat meninjau hasilnya. Kami menyarankan agar menjalankan penulisan ini sebagai langkah pertama dari setiap upaya pemecahan masalah. Hasilnya dapat berguna saat bekerja dengan Tim AWS Support. Untuk informasi selengkapnya, lihat Bekerja dengan skrip dukungan diagnostik di AWS DMS.

• Penilaian Pra-migrasi — Penilaian pra-migrasimengevaluasi komponen tertentu dari tugas migrasi basis data untuk membantu mengidentifikasi setiap masalah yang mungkin mencegah tugas migrasi berjalan seperti yang diharapkan. Dengan menggunakan penilaian ini, Anda dapat mengidentifikasi berbagai potensi masalah sebelum Anda menjalankan tugas baru atau yang dimodifikasi. Untuk informasi lebih lanjut tentang bekerja dengan penilaian pra-migrasi, lihat Mengaktifkan dan bekerja dengan penilaian perdana untuk tugas.

Mengubah skema

AWS DMS tidak melakukan konversi skema atau kode. Jika Anda ingin mengubah skema yang ada untuk mesin basis data yang berbeda, Anda dapat menggunakan AWS SCT. AWS SCTmengubah objek sumber, tabel, indeks, tampilan, pemicu, dan berbagai objek sistem lainnya ke dalam format bahasa definisi data target (DDL). Anda juga dapat menggunakan AWS SCT untuk mengubah sebagian besar kode aplikasi Anda, seperti PL/SQL atau TSQL, untuk bahasa target yang setara.

Anda bisa mendapatkan AWS SCT dengan mengunduh secara gratis dari AWS. Untuk informasi lebih lanjut tentang AWS SCT, lihat Panduan Pengguna AWS SCT.

Jika titik akhir sumber dan target Anda berada di mesin database yang sama, Anda dapat menggunakan alat seperti Oracle SQL Developer, MySQL Workbench, atau 4 untuk memindahkan skema Anda. PgAdmin

Meninjau dokumentasi publik AWS DMS

Kami sangat menyarankan agar Anda pergi ke halaman dokumentasi publik AWS DMS untuk sumber dan titik akhir target sebelum migrasi pertama Anda. Dokumentasi ini dapat membantu Anda mengidentifikasi prasyarat untuk migrasi dan memahami keterbatasan saat ini sebelum memulai. Untuk informasi lebih lanjut, lihat Bekerja dengan Titik akhir DMS AWS.

Selama migrasi, dokumentasi publik dapat membantu Anda memecahkan masalah apa pun dengan AWS DMS. Halaman pemecahan masalah dalam dokumentasi dapat membantu Anda menyelesaikan berbagai masalah umum menggunakan AWS DMS dan basis data titik akhir yang dipilih. Untuk informasi lebih lanjut, lihat Pemecahan masalah tugas migrasi di AWS Database Migration Service.

Menjalankan bukti konsep

Untuk membantu menemukan masalah dengan lingkungan Anda pada fase awal migrasi basis data Anda, sebaiknya jalankan migrasi uji singkat. Melakukan hal ini juga dapat membantu Anda mengatur ketepatan waktu migrasi yang lebih realistis. Selain itu, Anda mungkin perlu menjalankan migrasi uji menskalakan penuh untuk mengukur apakah AWS DMS dapat menangani throughput basis data pada jaringan Anda. Selama waktu ini, kami merekomendasikan untuk menetapkan tolok ukur dan mengoptimalkan awal beban penuh Anda dan replikasi yang sedang berlangsung. Melakukan hal ini dapat membantu memahami latensi jaringan Anda dan mengukur performa secara keseluruhan.

Pada saat ini, Anda juga memiliki kesempatan untuk memahami profil data Anda dan seberapa basis data large Anda, termasuk berikut ini:

• Berapa banyak tabel yang berukuran Large, Medium, dan kecil.

• Bagaimana AWS DMS menangani tipe data dan konversi kumpulan karakter.

• Berapa banyak tabel yang memiliki kolom Large Object (LOB).

• Berapa lama waktu yang diperlukan untuk menjalankan migrasi pengujian.

Meningkatkan performa suatu migrasi AWS DMS

Sejumlah faktor memengaruhi performa Migrasi AWS DMS Anda:

• Ketersediaan sumber daya pada sumber.

• Throughput jaringan yang tersedia.

• Kapasitas sumber daya dari server replikasi.

• Kemampuan target untuk menyerap perubahan.

• Tipe dan distribusi data sumber.

• Jumlah objek yang akan dimigrasi.

Anda dapat meningkatkan performa dengan menggunakan beberapa atau semua praktik terbaik yang disebutkan berikut. Apakah Anda dapat menggunakan salah satu praktik ini tergantung pada kasus penggunaan spesifik Anda. Anda dapat menemukan beberapa keterbatasan berikut:

Penyediaan server replikasi yang tepat

AWS DMS adalah layanan terkelola yang berjalan di instans Amazon EC2. Layanan ini menghubungkan ke basis data sumber, membaca data sumber, melakukan format data untuk digunakan oleh basis data target, dan memuat data ke dalam basis data target.

Sebagian besar pemrosesan ini terjadi di memori. Namun, transaksi Large mungkin memerlukan beberapa buffering pada disk. Transaksi cache dan mencatat file juga ditulis pada disk. Pada beberapa bagian berikut, Anda dapat menemukan apa yang harus dipertimbangkan ketika memilih server replikasi Anda.

CPU

AWS DMS dirancang untuk migrasi heterogen, tetapi juga mendukung migrasi homogen. Untuk melakukan migrasi homogen, pertama mengubah setiap tipe sumber data untuk tipe data AWS DMS yang setara. Kemudian mengubah setiap jenis data AWS DMS ke jenis data target. Anda dapat menemukan beberapa referensi untuk konversi ini untuk setiap mesin basis data dalam Panduan Pengguna AWS DMS.

Untuk AWS DMS melakukan konversi ini secara optimal, CPU harus tersedia ketika konversi terjadi. Kelebihan beban CPU dan tidak memiliki sumber daya CPU yang cukup dapat mengakibatkan migrasi lambat, yang juga dapat menyebabkan efek samping lainnya.

Tipe instans replikasi

Beberapa kelas instans yang lebih kecil cukup untuk menguji layanan atau untuk migrasi kecil. Jika migrasi Anda melibatkan sejumlah tabel large, atau jika Anda berniat menjalankan beberapa tugas replikasi secara bersamaan, pertimbangkan untuk menggunakan salah satu instans yang lebih besar. Satu instans yang lebih besar dapat menjadi ide yang bagus karena layanan ini menghabiskan cukup banyak memori dan CPU.

Instans jenis T2 dirancang untuk memberikan performa dasar sedang dan kemampuan untuk meningkatkan performa yang secara signifikan lebih tinggi sesuai dengan yang dibutuhkan beban kerja Anda. Tujuannya adalah untuk beban kerja yang tidak menggunakan CPU penuh secara sering atau konsisten, tetapi kadang-kadang perlu secara berturut-turut. Instans T2 sangat cocok untuk beban kerja tujuan umum, seperti server web, lingkungan developer, dan basis data kecil. Jika Anda memecahkan masalah migrasi lambat dan menggunakan tipe instans T2, Anda dapat memeriksa metrik host Utilisasi CPU. Ini dapat menunjukkan kepada Anda jika Anda melampaui patokan dasar untuk Tipe instans itu.

Kelas instans C4 dirancang untuk memberikan tingkat performa prosesor tertinggi untuk beban kerja komputer intensif. Beban kerja tersebut mencapai performa paket per detik (PPS) yang jauh lebih tinggi, gangguan jaringan yang lebih rendah, dan latensi jaringan yang lebih rendah. AWS DMS dapat berupa CPU-intensif, terutama ketika melakukan migrasi heterogen dan replikasi seperti migrasi dari Oracle ke PostgreSQL. Instans C4 dapat menjadi pilihan yang bagus untuk situasi ini.

Kelas instans R4 adalah memori yang dioptimalkan untuk beban kerja memori-intensif. Migrasi yang sedang berlangsung atau replikasi dari sistem transaksi throughput tinggi menggunakan AWS DMS kadang dapat menghabiskan jumlah CPU dan memori large. Instans R4 mencakup lebih banyak memori per vCPU.

Support AWS DMS untuk kelas instans R5 dan C5

Kelas instans R5 adalah instans memori yang dioptimalkan yang dirancang untuk memberikan performa cepat untuk beban kerja yang memproses pengaturan data large dalam memori. Migrasi yang sedang berlangsung atau replikasi dari sistem transaksi throughput tinggi yang menggunakan AWS DMS kadang dapat menghabiskan jumlah CPU dan memori large. Instans R5 memberikan 5 persen memori tambahan per vCPU daripada R4 dan ukuran terbesar menyediakan memori 768 GiB. Selain itu, instans R5 memberikan harga 10 persen per peningkatan GiB dan ~20% peningkatan performa CPU pada R4.

Kelas instans C5 dioptimalkan untuk beban kerja intensif komputasi dan memberikan kinerja tinggi yang hemat biaya dengan harga rendah per rasio komputasi. Instans tersebut mencapai performa jaringan yang lebih tinggi. Adaptor Jaringan Elastis (ENA) menyediakan instans C5 dengan bandwidth jaringan hingga 25 Gbps dan hingga bandwidth khusus hingga 14 Gbps untuk Amazon EBS. AWS DMS dapat berupa CPU-intensif, terutama dalam performa migrasi dan replikasi heterogen seperti migrasi dari Oracle ke PostgreSQL. Instans C5 dapat menjadi pilihan yang bagus untuk situasi ini.

Penyimpanan

Tergantung pada kelas instans, server replikasi Anda dilengkapi dengan 50 GB ataupun 100 GB penyimpanan data. Penyimpanan ini digunakan untuk mencatat file dan setiap perubahan cache yang dikumpulkan selama beban itu. Jika sistem sumber sibuk atau melakukan transaksi large, Anda mungkin perlu meningkatkan penyimpanan. Jika Anda menjalankan beberapa tugas di server replikasi, Anda mungkin juga memerlukan peningkatan penyimpanan. Namun, jumlah default biasanya cukup.

Semua volume penyimpanan di AWS DMS adalah GP2 atau tujuan umum solid-state drives (SSD). Volume GP2 dilengkapi dengan performa dasar dari tiga operasi I/O per detik (IOPS), dengan kemampuan melonjak hingga 3.000 IOPS secara berangsur-angsur. Sebagai aturan praktis, sebaiknya memeriksa metrik ReadIOPS dan WriteIOPS untuk instans replikasi. Pastikan bahwa jumlah nilai ini tidak melampaui performa dasar untuk volume tersebut.

Multi-AZ

Memilih instans multi-AZ dapat melindungi migrasi Anda dari kegagalan penyimpanan. Sebagian besar migrasi bersifat sementara dan tidak dimaksudkan untuk dijalankan untuk jangka waktu yang lama. Jika Anda menggunakan AWS DMS untuk tujuan replikasi yang sedang berlangsung, memilih instans multi-AZ dapat meningkatkan ketersediaan Anda jika terjadi masalah penyimpanan.

Saat menggunakan instans replikasi AZ atau Multi-AZ tunggal selama FULL LOAD dan failover atau penggantian host terjadi, tugas pemuatan penuh diharapkan gagal. Anda dapat memulai ulang tugas dari titik kegagalan untuk tabel yang tersisa yang tidak selesai, atau berada dalam keadaan kesalahan.

Memuat beberapa tabel secara paralel

Secara default, AWS DMS memuat delapan tabel pada suatu waktu. Anda mungkin melihat beberapa peningkatan performa dengan meningkatkan hal ini sedikit ketika menggunakan server replikasi large, seperti dms.c4.xlarge atau instans yang lebih besar. Namun, pada titik tertentu, meningkatkan paralelisme ini akan mengurangi performa. Jika server replikasi Anda relatif kecil, seperti dms.t2.medium, kami menyarankan agar Anda mengurangi jumlah tabel yang dimuat secara paralel.

Untuk mengubah nomor ini di AWS Management Console, bukalah konsol tersebut, pilih Tugas, memilih untuk membuat atau mengubah tugas, dan kemudian memilih Pengaturan lanjutan. Dalam Pengaturan Penyetelan, mengubah pilihan Jumlah maksimum tabel pada beban dalam paralel.

Untuk mengubah nomor ini menggunakan AWS CLI, ubahlah parameter MaxFullLoadSubTasks dalam TaskSettings.

Menggunakan beban penuh paralel

Anda dapat menggunakan beban paralel dari sumber Oracle, Microsoft SQL Server, MySQL, Sybase, dan IBM Db2 LUW berdasarkan partisi dan subpartisi. Melakukan hal ini dapat meningkatkan durasi beban penuh secara keseluruhan. Selain itu, saat menjalankan tugas migrasi AWS DMS, Anda dapat mempercepat migrasi tabel large atau yang dipartisi. Untuk melakukan ini, bagilah tabel ke dalam beberapa segmen dan memuat beban segmen tersebut secara paralel dalam tugas migrasi yang sama.

Untuk menggunakan beban paralel, buatlah aturan pemetaan tabel tipe table-settings dengan pilihan parallel-load. Dalam aturan table-settings, tentukan kriteria pilihan untuk satu tabel atau beberapa tabel dengan beban yang ingin Anda muat secara paralel. Untuk menentukan kriteria pilihan, perlu pengaturan elemen type untuk parallel-load pada salah satu pengaturan berikut:

• partitions-auto

• subpartitions-auto

• partitions-list

• ranges

• none

Untuk informasi selengkapnya tentang pengaturan, lihat Tabel dan koleksi pengaturan aturan dan operasi.

Bekerja dengan indeks, pemicu, dan kendala integritas referensial

Kendala indeks, pemicu, dan integritas referensial dapat memengaruhi performa migrasi Anda dan menyebabkan migrasi gagal. Bagaimana hal ini memengaruhi migrasi tergantung pada apakah tugas replikasi Anda merupakan beban tugas penuh atau tugas replikasi yang sedang berlangsung (tangkapan data perubahan, atau CDC).

Untuk tugas beban penuh, kami menyarankan agar Anda mengabaikan indeks kunci primer, indeks sekunder, kendala integritas referensial, dan pemicu bahasa manipulasi data (DLL). Atau Anda dapat menunda penyusunan semua itu sampai setelah tugas beban penuh selesai. Anda tidak memerlukan indeks selama tugas beban penuh, dan indeks dikenakan biaya pemeliharaan jika ada. Karena tugas beban penuh memuat beberapa kelompok tabel pada satu waktu, kendala integritas referensial dilanggar. Demikian pula, menyisipkan, memperbarui, dan menghapus pemicu dapat menyebabkan kesalahan, misalnya jika menyisipkan satu baris terpicu untuk tabel yang sebelumnya dimuat dalam jumlah banyak. Jenis pemicu lainnya juga memengaruhi performa karena pemrosesan tambahan.

Jika volume data relatif kecil dan waktu migrasi tambahan tidak menjadi pertimbangan, Anda dapat membangun indeks kunci primer dan sekunder sebelum tugas beban penuh. Selalu matikan batasan integritas referensial dan pemicu.

Untuk beban penuh ditambah tugas CDC, kami menyarankan agar Anda menambahkan indeks sekunder sebelum fase CDC. Karena AWS DMS menggunakan replikasi logis, pastikan bahwa indeks sekunder dalam support operasi DLL berada pada tempatnya untuk mencegah pemindaian tabel penuh. Anda dapat menjeda tugas replikasi sebelum fase CDC untuk membangun indeks dan membuat batasan integritas referensial sebelum memulai ulang tugas.

Anda harus mengaktifkan pemicu tepat sebelum cutover.

Matikan cadangan dan pendataan log transaksi

Saat bermigrasi ke basis data Amazon RDS, sebaiknya matikan cadangan dan Multi-AZ pada target sampai Anda siap untuk melakukan cutover. Demikian pula, ketika bermigrasi ke sistem selain Amazon RDS, mematikan setiap pendataan log pada target sampai setelah cutover biasanya merupakan ide bagus.

Menggunakan beberapa tugas

Kadang-kadang menggunakan beberapa tugas untuk satu migrasi dapat meningkatkan performa. Jika Anda memiliki kumpulan tabel yang tidak turut serta dalam transaksi umum, Anda mungkin dapat membagi migrasi menjadi beberapa tugas. Konsistensi transaksional dipertahankan dalam suatu tugas, jadi penting bila beberapa tabel dalam tugas terpisah tidak turut serta dalam transaksi umum. Selain itu, setiap tugas secara bebas membaca pengaliran transaksi, jadi berhati-hatilah agar tidak memberikan terlalu banyak tekanan pada basis data sumber.

Anda dapat menggunakan beberapa tugas untuk membuat streaming replikasi terpisah. Dengan melakukan ini, Anda dapat memparalelkan bacaan pada sumber, proses pada instans replikasi, dan penulisan pada basis data target.

Mengoptimalkan pemrosesan perubahan

Secara default, proses AWS DMS berubah dalam mode transaksional, yang mempertahankan integritas transaksional. Jika Anda mampu penyimpangan sementara dalam integritas transaksional, Anda dapat menggunakan batch dioptimalkan menerapkan pilihan sebagai gantinya. Opsi ini secara efisien mengelompokkan transaksi dan menerapkannya dalam batch untuk tujuan efisiensi. Menggunakan batch dioptimalkan menerapkan opsi hampir selalu melanggar referensial integritas kendala. Jadi kami menyarankan agar Anda menonaktifkan kendala ini selama proses migrasi dan mengaktifkannya lagi sebagai bagian dari proses cutover.

Menggunakan server nama on-premise Anda sendiri

Biasanya, instans replikasi AWS DMS menggunakan resolver Sistem Nama Domain (DNS) dalam instans Amazon EC2 untuk menyelesaikan titik akhir domain. Namun, Anda dapat menggunakan server nama on-premise Anda sendiri untuk menyelesaikan titik-titik akhir tertentu jika Anda menggunakan Amazon Route 53 Resolver. Dengan perangkat ini, Anda dapat melakukan kueri antara on-premise dan AWS menggunakan titik akhir masuk (inbound) dan keluar (outbound), aturan penerusan, dan koneksi privat. Manfaat menggunakan server nama on-premise mencakup peningkatan keamanan dan kemudahan penggunaan di balik firewall.

Jika Anda memiliki titik akhir masuk (inbound), Anda dapat menggunakan kueri DNS yang berasal dari on-premise untuk menyelesaikan domain host AWS. Untuk mengkonfigurasi titik akhir, tetapkan alamat IP di setiap subnet yang ingin Anda berikan resolver. Untuk membangun konektivitas antara infrastruktur DNS on-premise dan AWS, gunakan AWS Direct Connect atau jaringan pribadi virtual (VPN).

Connect titik akhir keluar ke server nama on-premise Anda. Server nama hanya memberi kemudahan untuk mengakses ke alamat IP yang disertakan dalam daftar yang mengizinkan maksud tersebut dan diatur dalam titik akhir keluar. Alamat IP server nama Anda adalah alamat IP target. Ketika Anda memilih grup keamanan untuk titik akhir keluar, pilihlah grup keamanan sama yang digunakan oleh instans replikasi.

Untuk meneruskan domain pilihan ke server nama, gunakan aturan penerusan. Titik akhir keluar dapat menangani beberapa aturan penerusan. Lingkup aturan penerusan adalah virtual private cloud (VPC) Anda. Dengan menggunakan aturan penerusan yang terkait dengan VPC, Anda dapat memiliki persediaan bagian Cloud AWS yang terisolasi secara logis. Dari bagian yang terisolasi secara logis ini, Anda dapat meluncurkan sumber daya AWS dalam jaringan virtual.

Anda dapat melakukan konfigurasi domain yang dihosting dalam infrastruktur DNS on-premise sebagai aturan penerusan bersyarat yang mengatur kueri DNS keluar. Ketika suatu kueri dibuat untuk salah satu domain tersebut, beberapa aturan menjadikan pemicu sebagai upaya untuk meneruskan permintaan DNS ke server yang dikonfigurasi dengan aturan tersebut. Sekali lagi, diperlukan koneksi privat melalui AWS Direct Connect atau VPN.

Diagram berikut menunjukkan arsitektur Route 53 Resolver.

Untuk informasi selengkapnya tentang penggunaan Route 53 DNS Resolver, lihat Memulai dengan Route 53 Resolver dalam Panduan Developer Amazon Route 53.

Menggunakan Amazon Route 53 Resolver dengan AWS DMS

Anda dapat membuat server nama on premise untuk AWS DMS untuk menyelesaikan titik akhir menggunakan Amazon Route 53 Resolver.

Untuk membuat server nama on premise untuk AWS DMS berdasarkan Route 53

1. Masuk ke AWS Management Console dan bukalah konsol Route 53 di https://console.aws.amazon.com/route53/.

2. Pada konsol Route 53, sebaiknya memilih Wilayah AWS tempat Anda ingin melakukan konfigurasi Route 53 Resolver. Route 53 Resolver adalah khusus untuk suatu Wilayah.

3. Memilih arah kueri—masuk, keluar, atau keduanya.

4. Menyediakan konfigurasi kueri masuk:

   1. Memasukkan nama titik akhir dan memilih VPC.

   2. Menetapkan satu atau lebih subnet dari dalam VPC (misalnya, memilih dua untuk ketersediaan).

   3. Menetapkan alamat IP tertentu untuk digunakan sebagai titik-titik akhir, atau memiliki Route 53 Resolver yang menetapkannya secara otomatis.

5. Membuat aturan untuk domain on premise Anda sehingga beban kerja di dalam VPC dapat memberikan rute kueri DNS ke infrastruktur DNS Anda.

6. Memasukkan satu atau beberapa alamat IP untuk server DNS on-premise Anda.

7. Kirim aturan Anda.

Ketika semuanya dibuat, VPC Anda dikaitkan dengan aturan masuk dan keluar Anda dan lalu lintas perutean dapat mulai.

Untuk informasi selengkapnya tentang Route 53 Resolver, lihat Memulai dengan Route 53 Resolver dalam Panduan Developer Amazon Route 53.

Melakukan migrasi objek biner large (LOB)

Secara umum, AWS DMS melakukan migrasi data LOB dalam dua tahap:

1. AWS DMS menciptakan baris baru dalam tabel target dan mengisi baris tersebut dengan semua data kecuali nilai LOB terkait.

2. AWS DMS memperbarui baris dalam tabel target dengan LOB data.

Proses migrasi untuk LOB mensyaratkan bahwa, selama migrasi, semua kolom LOB pada tabel target harus tidak dapat dibatalkan. Hal ini sedemikian rupa sehingga bahkan jika kolom LOB bukan tidak dapat dibatalkan pada tabel sumber. Jika AWS DMS menciptakan tabel target, maka menetapkan kolom LOB supaya tidak dapat dibatalkan secara default. Dalam beberapa kasus, Anda mungkin membuat tabel target menggunakan beberapa mekanisme lain, seperti impor atau ekspor. Dalam kasus tersebut, pastikan bahwa kolom LOB tidak dapat dibatalkan sebelum Anda mulai tugas migrasi.

Persyaratan ini memiliki satu pengecualian. Misalkan Anda melakukan migrasi homogen dari sumber Oracle ke target Oracle, dan Anda memilih Mode Lob terbatas. Dalam hal ini, seluruh baris diisi sekaligus, termasuk nilai-nilai LOB. Untuk kasus seperti itu, AWS DMS dapat membuat kolom LOB tabel target dengan kendala bukan tidak dapat dibatalkan, jika diperlukan.

Menggunakan mode LOB terbatas

AWS DMS menggunakan dua metode yang menyeimbangkan performa dan kemudahan ketika migrasi Anda berisi nilai-nilai LOB:

1. Mode LOB terbatas melakukan migrasi semua nilai LOB hingga batas pengukuran yang ditentukan oleh pengguna (default adalah 32 KB). Nilai LOB yang lebih besar dari batas pengukuran harus dimigrasi secara manual. Mode LOB terbatas, default untuk semua tugas migrasi, biasanya memberikan performa terbaik. Namun, pastikan bahwa pengaturan parameter Pengukuran LOB maksimal itu benar. Mengatur parameter ini pada pengukuran LOB terbesar untuk semua tabel Anda.

2. Mode LOB penuh melakukan migrasi semua data LOB dalam tabel Anda, terlepas dari ukurannya. Mode LOB penuh memberikan kemudahan memindahkan semua data LOB dalam tabel Anda, tetapi proses ini dapat memiliki dampak yang signifikan pada performa.

Untuk beberapa mesin basis data, seperti PostgreSQL, AWS DMS memperlakukan tipe data JSON seperti LOBs. Pastikan bahwa jika Anda memilih Mode LOB terbatas, pengukuran LOB maksimal diatur pada nilai yang tidak menyebabkan data JSON dipotong.

AWS DMS menyediakan support penuh untuk menggunakan tipe data objek large (BLOB, CLOB, dan NCLOB). Titik akhir sumber berikut memiliki support LOB penuh:

• Oracle

• Microsoft SQL Server

• ODBC

Titik akhir target berikut memiliki support LOB penuh:

• Oracle

• Microsoft SQL Server

Titik akhir target berikut memiliki support LOB terbatas. Anda tidak dapat menggunakan pengukuran LOB tak terbatas untuk titik akhir target ini.

• Amazon Redshift

• Amazon S3

Untuk titik akhir yang memiliki support LOB penuh, Anda juga dapat menetapkan batas pengukuran untuk LOB tipe data.

Peningkatan performa LOB

Sementara melakukan migrasi data LOB, Anda dapat menentukan pengaturan optimasi LOB yang berbeda berikut.

Pengaturan LOB per tabel

Menggunakan pengaturan LOB per tabel, Anda dapat mengganti pengaturan LOB tingkat tugas untuk beberapa atau semua tabel Anda. Untuk melakukannya, tentukan lob-settings di aturan table-settings. Berikut ini adalah contoh tabel yang mencakup beberapa nilai LOB large.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

Berikutnya, membuat tugas migrasi dan memodifikasi penanganan LOB untuk tabel Anda dengan menggunakan aturan baru lob-settings. Nilai bulk-max-siz menentukan pengukuran LOB maksimum (KB). Ini terpotong jika lebih besar dari pengukuran yang ditentukan.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Bahkan jika tugas ini AWS DMS dibuat dengan FullLobMode : true, beberapa pengaturan LOB per tabel mengarahkan AWS DMS untuk memotong data LOB dalam tabel khusus ini pada 16.000. Anda dapat memeriksa catatan tugas untuk mengonfirmasi ini.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Pengaturan LOB sebaris

Saat Anda membuat suatu tugas AWS DMS, mode LOB menentukan bagaimana LOB ditangani.

Dengan mode LOB penuh dan mode LOB terbatas, masing-masing memiliki manfaat dan kekurangan tersendiri. Mode LOB sebaris menggabungkan keuntungan dari kedua mode LOB penuh dan mode LOB terbatas.

Anda dapat menggunakan mode LOB sebaris ketika Anda perlu mereplikasi baik LOB kecil maupun large, dan sebagian besar LOB kecil. Ketika Anda memilih opsi ini, selama beban penuh, tugas AWS DMS mentransfer baris LOB kecil, yang lebih efisien. Tugas AWS DMS mentransfer LOB large dengan performa pencarian dari tabel sumber.

Selama pemrosesan perubahan, LOB kecil dan large direplikasi dengan performa pencarian dari tabel sumber.

Bila Anda menggunakan modus LOB sebaris, tugas AWS DMS memeriksa semua pengukuran LOB untuk menentukan mana yang ditransfer sebaris. LOB yang lebih besar dari pengukuran yang ditentukan direplikasi dengan menggunakan mode LOB penuh. Oleh karena itu, jika Anda tahu bahwa sebagian besar LOB lebih besar dari pengaturan yang ditentukan, lebih baik tidak menggunakan opsi ini. Sebaliknya, mengizinkan pengukuran LOB yang tak terbatas.

Anda mengkonfigurasi opsi ini menggunakan atribut dalam pengaturan tugas, InlineLobMaxSize, yang hanya tersedia saat FullLobMode dilakukan pengaturan ke true. Nilai default untuk InlineLobMaxSize adalah 0 dan kisarannya adalah 1 —102400 kilobyte (100 MB).

Misalnya, Anda dapat menggunakan perintah berikut: pengaturan tugas AWS DMS. Di sini, pengaturan InlineLobMaxSize ke nilai 5 menghasilkan semua LOB yang lebih kecil dari atau sama dengan 5 KiB (5.120 byte) ditransfer sebaris.

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Meningkatkan performa ketika melakukan migrasi tabel-tabel large menggunakan filter baris

Untuk meningkatkan kinerja saat memigrasikan tabel besar, pisahkan migrasi menjadi lebih dari satu tugas. Untuk membagi migrasi menjadi beberapa tugas menggunakan filter baris, gunakan satu kunci atau kunci partisi. Misalnya, jika Anda memiliki ID kunci primer integer dari 1 hingga 8.000.000, Anda dapat membuat delapan tugas menggunakan filter baris untuk melakukan migrasi masing-masing 1 juta catatan.

Untuk menerapkan pemfilteran baris di konsol:

1. Buka AWS Management Console.

2. Pilih Tugas, dan buat tugas baru.

3. Memilih tab Pemetaan tabel, dan memperluas Aturan Pilihan.

4. Memilih Menambahkan aturan pilihan baru. Anda sekarang dapat menambahkan filter kolom dengan kurang dari atau sama dengan, lebih besar dari atau sama dengan, sama dengan, atau kondisi rentang antara dua nilai. Untuk informasi selengkapnya tentang pemfilteran kolom, lihat Menentukan pemilihan tabel dan transformasi aturan dari konsol.

Jika Anda memiliki tabel partisi besar yang dipartisi berdasarkan tanggal, Anda dapat memigrasikan data berdasarkan tanggal. Misalnya, anggap bahwa Anda memiliki tabel yang dipartisi berdasarkan bulan, dan hanya data bulan saat ini yang diperbarui. Dalam hal ini, Anda dapat membuat tugas beban penuh untuk setiap partisi bulanan statis dan membuat beban penuh ditambah tugas CDC untuk partisi yang sedang diperbarui.

Jika tabel Anda memiliki kunci primer satu kolom atau indeks unik, Anda dapat membuat AWS DMS tugas Anda mengelompokkan tabel menggunakan beban paralel dari jenis rentang untuk memuat data secara paralel. Untuk informasi selengkapnya, lihat Tabel dan koleksi pengaturan aturan dan operasi.

Replikasi yang sedang berlangsung

AWS DMS menyediakan replikasi data yang sedang berlangsung, menjaga sumber dan target basis data tetap sinkron. Ini mereplikasi hanya jumlah terbatas bahasa definisi data (DDL). AWS DMS tidak mengembangkan item seperti indeks, pengguna, hak istimewa, prosedur yang disimpan, dan perubahan basis data lainnya yang tidak terkait langsung dengan data tabel.

Jika Anda berencana untuk menggunakan replikasi yang sedang berlangsung, aturlah opsi Multi-AZ saat membuat instans replikasi Anda. Dengan memilih Multi-AZ, Anda mendapatkan ketersediaan yang tinggi dan failover support untuk instans replikasi. Namun, opsi ini dapat berdampak pada performa dan dapat memperlambat replikasi sementara menerapkan perubahan sistem target.

Sebelum Anda memutakhirkan sumber atau target basis data, kami menyarankan agar Anda menghentikan setiap tugas AWS DMS yang berjalan di basis data ini. Lanjutkan tugas setelah pemutakhiran sistem selesai.

Selama replikasi yang sedang berlangsung, sangat penting untuk mengidentifikasi bandwidth jaringan antara sistem basis data sumber dan instans replikasi AWS DMS. Pastikan bahwa jaringan tidak menyebabkan kemacetan selama replikasi berlangsung.

Penting juga untuk mengidentifikasi tingkat perubahan dan hasil dari mencatat arsip per jam pada sistem basis data sumber Anda. Melakukan hal ini dapat membantu Anda untuk memahami throughput yang mungkin Anda dapatkan selama replikasi yang sedang berlangsung.

Mengurangi beban pada basis data sumber Anda

AWS DMS menggunakan beberapa sumber daya pada basis data sumber Anda. Selama tugas beban penuh, AWS DMS melakukan pemindaian tabel lengkap dari tabel sumber untuk setiap tabel yang diproses secara paralel. Dan juga, setiap tugas yang Anda buat sebagai bagian dari migrasi kueri sumber untuk perubahan sebagai bagian dari proses CDC. Supaya AWS DMS melakukan CDC untuk beberapa sumber, seperti Oracle, Anda mungkin perlu meningkatkan jumlah data yang ditulis dengan mencatat perubahan basis data Anda.

Jika mengetahui bahwa Anda membebani basis data sumber Anda, kurangi jumlah tugas atau tabel untuk setiap tugas migrasi Anda. Setiap tugas mendapat perubahan sumber secara terpisah, sehingga menggabbungkan beberapa tugas dapat mengurangi perubahan yang menangkap beban kerja.

Mengurangi kemacetan pada basis data target Anda

Selama migrasi, cobalah menghapus proses yang bersaing untuk sumber daya tulis pada basis data target Anda:

• Matikan pemicu yang tidak perlu.

• Matikan indeks sekunder selama beban awal dan mengubahnya kembali kemudian selama replikasi yang sedang berlangsung.

• Dengan basis data Amazon RDS, ide yang baik bila mematikan backup dan multi-AZ sampai cutover.

• Ketika melakukan migrasi ke sistem non-RDS, ide yang baik bila menonaktifkan setiap catatan pada target sampai cutover.

Menggunakan validasi data selama migrasi

Untuk memastikan bahwa data Anda dimigrasi secara akurat dari sumber ke target, kami sangat menyarankan agar Anda menggunakan validasi data. Jika Anda mengaktifkan validasi data untuk suatu tugas, AWS DMS mulai membandingkan sumber dan target data segera setelah beban penuh dilakukan untuk tabel.

Validasi data bekerja dengan basis data berikut di mana pun AWS DMS mendukungnya sebagai sumber dan target titik akhir:

• Oracle

• PostgreSQL

• MySQL

• MariaDB

• Microsoft SQL Server

• Amazon Aurora Edisi Kompatibel MySQL

• Amazon Aurora Edisi Kompatibel PostgreSQL

• IBM Db2 LUW

• Amazon Redshift

Untuk informasi selengkapnya, lihat Validasi data AWS DMS.

Pemantauan tugas AWS DMS menggunakan metrik

Anda memiliki beberapa opsi pemantauan metrik untuk tugas Anda dengan menggunakan konsol AWS DMS tersebut:

Metrik host

Anda dapat menemukan metrik host di tab CloudWatch metrik untuk setiap instance replikasi tertentu. Di sini, Anda dapat memantau apakah instans replikasi Anda diukur secara tepat.

Metrik tugas replikasi

Metrik untuk tugas replikasi, termasuk perubahan masuk dan komit, dan latensi antara host replikasi dan basis data sumber/target dapat ditemukan di tab metrik untuk setiap tugas tertentu. CloudWatch

Metrik tabel

Anda dapat menemukan metrik tabel individual pada tab Statistik tabel untuk setiap tugas individu. Metrik ini mencakup angka-angka berikut:

• Baris-baris dimuat selama beban penuh.

• Menyisipkan, memperbarui, dan menghapus sejak tugas dimulai.

• Operasi DDL sejak tugas dimulai.

Untuk informasi selengkapnya tentang pemantauan metrik, lihat Pemantauan Tugas AWS DMS.

Tindakan dan notifikasi

AWS DMS menggunakan Amazon SNS untuk memberikan notifikasi ketika tindakan AWS DMS terjadi, misalnya penciptaan atau penghapusan instans replikasi. Anda dapat bekerja dengan notifikasi ini dalam bentuk apa pun yang didukung oleh Amazon SNS untuk Wilayah AWS. Ini dapat mencakup pesan email, pesan teks, atau panggilan pada titik akhir HTTP.

Untuk informasi lebih lanjut, lihat Bekerja dengan acara Amazon SNS dan pemberitahuan diAWS Database Migration Service.

Menggunakan cara dengan mencatat tugas untuk memecahkan masalah migrasi

Dalam beberapa kasus, AWS DMS dapat mengalami berbagai masalah yang memunculkan peringatan atau pesan kesalahan hanya dengan mencatat tugas. Secara khusus, masalah pemotongan data atau penolakan baris karena pelanggaran kunci asing hanya ditulis dengan mencatat tugas. Oleh karena itu, pastikan untuk meninjau setelah mencatat tugas ketika melakukan migrasi basis data. Untuk melihat log tugas, konfigurasikan Amazon CloudWatch sebagai bagian dari pembuatan tugas.

Untuk informasi selengkapnya, lihat Memantau tugas replikasi menggunakan Amazon CloudWatch.

Memecahkan masalah tugas replikasi dengan Time Travel

Untuk memecahkan masalah AWS DMS migrasi, Anda dapat bekerja dengan Time Travel. Untuk informasi lebih lanjut tentang Perjalanan Waktu, lihatPengaturan tugas Perjalanan Waktu.

Saat Anda bekerja dengan Time Travel, perhatikan pertimbangan berikut:

• Untuk menghindari overhead pada instance replikasi DMS, aktifkan Time Travel hanya untuk tugas yang memerlukan debugging.

• Saat Anda menggunakan Time Travel untuk memecahkan masalah tugas replikasi yang mungkin berjalan selama beberapa hari, pantau metrik instance replikasi untuk overhead sumber daya. Pendekatan ini berlaku terutama dalam kasus di mana beban transaksi tinggi berjalan pada database sumber untuk jangka waktu yang lama. Untuk detail selengkapnya, lihat Pemantauan Tugas AWS DMS.

• Saat pengaturan tugas Perjalanan Waktu EnableRawData disetel ketrue, penggunaan memori tugas selama replikasi DMS mungkin lebih tinggi daripada saat Perjalanan Waktu tidak diaktifkan. Jika Anda mengaktifkan Perjalanan Waktu untuk waktu yang lama, pantau tugas Anda.

• Saat ini, Anda dapat mengaktifkan Perjalanan Waktu hanya di tingkat tugas. Perubahan pada semua tabel dicatat di log Perjalanan Waktu. Jika Anda memecahkan masalah untuk tabel tertentu dalam database dengan volume transaksi tinggi, buat tugas terpisah.

Mengubah pengguna dan skema untuk target Oracle

Bila Anda adalah pengguna Oracle sebagai target, AWS DMS melakukan migrasi data ke skema yang dimiliki oleh pengguna titik akhir target.

Misalnya, anggaplah Anda melakukan migrasi skema bernama PERFDATA pada titik akhir target Oracle, dan bahwa nama pengguna titik akhir target adalah MASTER. AWS DMS menghubungkan ke target Oracle sebagai MASTER dan mengisi skema MASTER dengan objek basis data dari PERFDATA.

Untuk membatalkan perilaku ini, berikan perubahan skema. Misalnya, untuk melakukan migrasi objek skema PERFDATA ke skema PERFDATA pada titik akhir target, gunakan perubahan berikut.

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Untuk informasi lebih lanjut tentang perubahan, lihat Menentukan pemilihan tabel dan transformasi aturan menggunakan JSON.

Mengubah tempat penyimpanan tabel dan indeks untuk target Oracle

Bila menggunakan Oracle sebagai target, AWS DMS melakukan migrasi semua tabel dan indeks ke ruang penyimpanan default dalam target. Misalnya, anggap bahwa sumber Anda adalah mesin basis data selain Oracle. Semua tabel dan indeks target dimigrasi ke tempat penyimpanan default yang sama.

Untuk membatalkan perilaku ini, berikan perubahan tempat penyimpanan yang sesuai. Sebagai contoh, misalkan Anda ingin melakukan migrasi tabel dan indeks ke tempat penyimpanan tabel dan indeks di target Oracle yang diberi nama sesuai skema dalam sumber. Dalam hal ini, Anda dapat menggunakan perubahan serupa dengan yang berikut. Di sini, skema dalam sumber diberi nama INVENTORY dan tempat penyimpanan tabel dan indeks yang sesuai dalam target diberi nama INVENTORYTBL dan INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Untuk informasi lebih lanjut tentang perubahan, lihat Menentukan pemilihan tabel dan transformasi aturan menggunakan JSON.

Apabila Oracle adalah sumber dan target, Anda dapat mempertahankan tugas tempat penyimpanan tabel atau indeks yang ada dengan menetapkan atribut koneksi tambahan sumber Oracle enableHomogenousTablespace=true. Untuk informasi lebih lanjut, lihat Pengaturan titik akhir saat menggunakan Oracle sebagai sumber AWS DMS.

Pemutakhiran versi instans replikasi

AWS secara berkala merilis versi baru dari perangkat lunak mesin replikasi AWS DMS, dengan fitur baru dan peningkatan performa. Setiap versi perangkat lunak mesin replikasi memiliki nomor versi sendiri. Sangat penting untuk menguji versi AWS DMS instans replikasi Anda yang menjalankan beban kerja produksi sebelum Anda memutakhirkan instans replikasi Anda ke versi yang lebih baru. Untuk informasi lebih lanjut tentang pemutakhiran versi, lihat AWS Catatan rilis DMS.

Memahami biaya migrasi Anda

AWS Database Migration Service membantu Anda melakukan migrasi basis data ke AWS secara mudah dan aman dengan biaya rendah. Anda hanya membayar untuk instans replikasi Anda dan penyimpanan setelah mencatat informasi tambahan. Setiap instans migrasi basis data termasuk penyimpanan yang cukup untuk ruang tukar, catatan replikasi, dan cache data untuk sebagian besar replikasi dan transfer data masuk adalah gratis.

Anda mungkin memerlukan lebih banyak sumber daya selama beban awal atau selama waktu unggah puncak. Anda dapat memantau penggunaan sumber daya instans replikasi menggunakan metrik cloud watch. Anda kemudian dapat menaikkan skala dan menurunkan skala ukuran instans replikasi berdasarkan penggunaan.

Untuk informasi lebih lanjut tentang memperkirakan biaya migrasi Anda, lihat:

• AWS Database Migration Serviceharga

• AWSKalkulator Harga