Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Fase 3: Migrasi
Setelah Anda menyelesaikan perencanaan migrasi dan mengidentifikasi strategi migrasi, migrasi sebenarnya akan terjadi. Pada fase ini, database target dirancang, data sumber dimigrasikan ke target, dan data divalidasi.
![\[Iterative migration process\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-database-migration/images/iterative-migration-process.png)
Ini adalah proses berulang yang mencakup beberapa siklus konversi, migrasi, dan pengujian. Setelah pengujian fungsional dan kinerja selesai, Anda dapat memotong ke database baru.
Fase migrasi terdiri dari langkah-langkah kunci berikut, yang dibahas di bagian berikut:
+ [Mengonversi skema](convert-schema.md)
+ [Migrasi data](migrate-data.md)
+ [Memperbarui aplikasi](update-app.md)
+ [Menguji migrasi](test-migration.md)
+ [Memotong ke database baru](cut-over.md)
# Konversi skema
Salah satu tugas utama selama migrasi database adalah untuk memigrasikan skema Anda dari mesin database sumber ke mesin database target. Jika Anda melakukan rehost atau replatform, mesin database Anda tidak akan berubah. Ini disebut sebagai *migrasi database homogen*, dan Anda dapat menggunakan alat database asli Anda untuk memigrasi skema.
Namun, jika Anda merancang ulang aplikasi Anda, konversi skema mungkin memerlukan lebih banyak usaha. Dalam hal ini, Anda akan melakukan *migrasi database heterogen*, di mana mesin basis data sumber dan target Anda akan berbeda. Skema database Anda saat ini mungkin menggunakan paket dan fitur yang tidak dapat langsung dikonversi ke mesin basis data target. Beberapa fitur mungkin tersedia dengan nama yang berbeda. Oleh karena itu, mengonversi skema membutuhkan pemahaman yang baik tentang mesin basis data sumber dan target Anda. Tugas ini bisa menantang, tergantung pada kompleksitas skema Anda saat ini.
AWS menyediakan dua sumber daya untuk membantu Anda dengan konversi skema: AWS Schema Conversion Tool (AWS SCT) dan buku pedoman migrasi.
## AWS SCT
AWS SCT adalah alat gratis yang dapat membantu Anda mengonversi database yang ada dari satu mesin ke mesin lainnya. AWS SCT mendukung sejumlah database sumber, termasuk Oracle, Microsoft SQL Server, MySQL, Sybase, dan IBM Db2 LUW. Anda dapat memilih dari database target seperti Aurora MySQL dan Aurora PostgreSQL.
AWS SCT menyediakan antarmuka pengguna grafis yang langsung terhubung ke database sumber dan target untuk mengambil objek skema saat ini. Saat terhubung, Anda dapat membuat laporan penilaian migrasi database untuk mendapatkan ringkasan tingkat tinggi dari upaya konversi dan item tindakan. Ilustrasi layar berikut menunjukkan contoh laporan penilaian migrasi database.
![\[Sample database migration assessment report from AWS SCT\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-database-migration/images/sct-assessment-report.png)
Dengan AWS SCT Anda dapat mengonversi skema dan menyebarkannya ke database target secara langsung, atau Anda bisa mendapatkan file SQL untuk skema yang dikonversi. Untuk informasi selengkapnya, lihat [Menggunakan Antarmuka AWS Schema Conversion Tool Pengguna](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_UserInterface.html) dalam AWS dokumentasi.
## Buku pedoman migrasi
Meskipun AWS SCT mengubah banyak objek sumber Anda, beberapa aspek konversi memerlukan intervensi dan penyesuaian manual. Untuk membantu tugas ini, AWS sediakan buku pedoman migrasi yang merinci ketidakcocokan dan kesamaan antara dua database. Untuk informasi lebih lanjut tentang buku pedoman ini, lihat [AWS Database Migration Service sumber daya](https://aws.amazon.com/dms/resources/) di AWS situs web.
# Migrasikan data
Ketika migrasi skema selesai, Anda dapat memindahkan data Anda dari database sumber ke database target. Bergantung pada persyaratan ketersediaan aplikasi Anda, Anda dapat menjalankan pekerjaan ekstraksi sederhana yang melakukan salinan data sumber satu kali ke dalam database baru. Atau, Anda dapat menggunakan alat yang menyalin data saat ini dan terus mereplikasi semua perubahan sampai Anda siap untuk memotong ke database baru. Untuk migrasi rehost dan replatform, sebaiknya gunakan alat khusus database asli untuk memigrasikan data Anda.
Alat yang dapat membantu Anda dengan transfer data termasuk AWS Database Migration Service (AWS DMS) dan alat migrasi offline. Ini dijelaskan di bagian berikut.
## AWS DMS
Setelah Anda menggunakan AWS SCT untuk mengonversi objek skema Anda dari mesin database sumber ke mesin target, Anda dapat menggunakan AWS DMS untuk memigrasikan data. Dengan AWS DMS Anda dapat menjaga database sumber tetap aktif dan berjalan saat data sedang direplikasi. Anda dapat melakukan salinan data satu kali atau menyalin dengan replikasi berkelanjutan. Ketika database sumber dan target disinkronkan, Anda dapat mengambil database Anda offline dan memindahkan operasi Anda ke database target. AWS DMS dapat digunakan untuk migrasi database homogen (misalnya, dari database Oracle lokal ke database Amazon RDS for Oracle) serta migrasi heterogen (misalnya, dari database Oracle lokal ke database Amazon RDS for PostgreSQL). Untuk informasi lebih lanjut tentang bekerja dengan AWS DMS, lihat [AWS DMS dokumentasi](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).
## Opsi migrasi offline
Anda dapat menggunakan opsi lain selain AWS DMS untuk mengekstrak data Anda dari database sumber dan memuatnya ke database target. Opsi ini sebagian besar cocok ketika waktu henti aplikasi diizinkan selama aktivitas migrasi data. Contoh metode ini meliputi:
+ Ekstrak nilai terpisah koma (CSV) dari database sumber yang dimuat ke database target
+ Untuk database sumber Oracle, utilitas **ora2pg** untuk menyalin data ke PostgreSQL
+ Ekstrak kustom, transformasi, muat (ETL) pekerjaan untuk menyalin data dari sumber ke target
# Memperbarui aplikasi
Migrasi database hampir tidak pernah merupakan migrasi database saja. Anda harus melihat aplikasi yang menggunakan database untuk memastikan bahwa itu berfungsi seperti yang diharapkan dengan database baru. Perubahan minimal jika Anda hanya rehosting atau replatforming mesin database yang sama, tetapi bisa lebih signifikan jika Anda memutuskan untuk pindah ke mesin database baru.
Jika aplikasi Anda bergantung pada pemetaan relasional objek (ORM) untuk berinteraksi dengan database, itu tidak akan memerlukan banyak perubahan saat Anda bermigrasi ke mesin database baru. Namun, jika aplikasi Anda memiliki interaksi basis data khusus atau kueri SQL yang dibangun secara dinamis, perubahannya bisa cukup besar. Mungkin ada perbedaan dalam format kueri yang perlu diperbaiki untuk memastikan bahwa aplikasi berfungsi seperti yang diharapkan.
Misalnya, di Oracle, menggabungkan string dengan `NULL` mengembalikan string asli. Namun, di PostgreSQL, menggabungkan string dengan pengembalian. `NULL` `NULL` Contoh lain adalah bagaimana `NULL` dan string kosong diperlakukan. Dalam PostgreSQL`NULL`, dan string kosong adalah dua hal yang berbeda, sedangkan database seperti Oracle memperlakukan mereka dengan cara yang sama. Di Oracle, jika Anda menyisipkan baris dengan nilai kolom yang disetel ke `NULL` atau string kosong, Anda dapat mengambil kedua jenis nilai dengan menggunakan `where` klausa:. `where is NULL` Dalam PostgreSQL, klausa `where` ini akan mengembalikan hanya satu baris di mana nilai kolom sebenarnya NULL; itu tidak akan mengembalikan baris yang memiliki nilai string kosong. Untuk informasi selengkapnya tentang perbedaan ini, lihat buku pedoman migrasi yang tercantum di halaman web [AWS Database Migration Service sumber daya](https://aws.amazon.com/dms/resources/).
# Uji migrasi
Pengujian fungsional dan kinerja adalah bagian penting dari migrasi database. Pengujian fungsional terperinci akan memastikan bahwa aplikasi Anda bekerja dengan database baru tanpa masalah apa pun. Anda harus menginvestasikan waktu untuk mengembangkan pengujian unit untuk menguji alur kerja aplikasi.
Pengujian kinerja memastikan bahwa waktu respons database Anda berada dalam rentang waktu yang dapat diterima. Anda dapat mengidentifikasi kemacetan, mengoptimalkan, dan mengulangi tes kinerja. Anda mengulangi siklus sesuai kebutuhan untuk mendapatkan hasil kinerja yang diinginkan.
Pengujian bisa manual atau otomatis. Kami menyarankan Anda menggunakan kerangka kerja otomatis untuk pengujian. Selama migrasi, Anda perlu menjalankan pengujian beberapa kali, jadi memiliki kerangka pengujian otomatis membantu mempercepat siklus perbaikan dan pengoptimalan bug.
Pengujian ini dapat mengungkapkan masalah yang terlewatkan selama fase pengembangan. Misalnya, kueri yang dikonversi secara tidak benar akan gagal atau mengembalikan hasil yang salah, menyebabkan pengujian fungsional gagal. Pengujian kinerja dapat mengungkapkan masalah seperti indeks yang hilang yang menyebabkan waktu respons kueri lambat. Mereka juga dapat mengungkapkan masalah kinerja yang memerlukan penyetelan mesin database, tergantung pada beban kerja, atau memodifikasi kueri.
# Potong
Strategi cutover database biasanya digabungkan erat dengan persyaratan downtime untuk aplikasi. Strategi yang dapat Anda gunakan untuk cutover database termasuk migrasi offline, migrasi flash-cut, konfigurasi database aktif/aktif, dan migrasi inkremental. Ini dibahas di bagian berikut.
## Migrasi offline
Jika Anda dapat membuat aplikasi offline untuk jangka waktu yang lama selama operasi penulisan, Anda dapat menggunakan AWS DMS setelan tugas beban penuh atau salah satu opsi migrasi offline untuk migrasi data Anda. Lalu lintas baca dapat berlanjut saat migrasi ini sedang berlangsung, tetapi lalu lintas tulis harus dihentikan. Karena semua data perlu disalin dari database sumber, sumber daya database sumber seperti I/O dan CPU digunakan.
Pada tingkat tinggi, migrasi offline melibatkan langkah-langkah berikut:
1. Selesaikan konversi skema.
1. Mulai downtime untuk menulis lalu lintas.
1. Migrasikan data menggunakan salah satu opsi migrasi offline.
1. Verifikasi data Anda.
1. Arahkan aplikasi Anda ke database baru.
1. Akhiri downtime aplikasi.
## Migrasi flash-cut
Dalam migrasi flash-cut, tujuan utamanya adalah menjaga waktu henti seminimal mungkin. Strategi ini bergantung pada replikasi data berkelanjutan (CDC) dari database sumber ke database target. Semua read/write traffic will continue on the current database while the data is being migrated. Because all the data needs to be copied from the source database, source server resources such as I/O dan CPU digunakan. Anda harus menguji untuk memastikan bahwa aktivitas migrasi data ini tidak memengaruhi kinerja aplikasi Anda SLAs.
Pada tingkat tinggi, migrasi flash-cut melibatkan langkah-langkah berikut:
1. Selesaikan konversi skema.
1. Siapkan AWS DMS dalam mode replikasi data berkelanjutan.
1. Ketika database sumber dan target disinkronkan, verifikasi data.
1. Mulai downtime aplikasi.
1. Luncurkan versi baru aplikasi, yang menunjuk ke database baru.
1. Akhiri downtime aplikasi.
## Konfigurasi basis data aktif/aktif
Konfigurasi basis data aktif/aktif melibatkan pengaturan mekanisme untuk menjaga database sumber dan target tetap sinkron sementara kedua database digunakan untuk menulis lalu lintas. Strategi ini melibatkan lebih banyak pekerjaan daripada migrasi offline atau flash-cut, tetapi juga memberikan lebih banyak fleksibilitas selama migrasi. Misalnya, selain mengalami downtime minimal selama migrasi, Anda dapat memindahkan lalu lintas produksi ke database baru dalam batch kecil yang terkontrol alih-alih melakukan cutover satu kali. Anda dapat melakukan operasi penulisan ganda sehingga perubahan dilakukan pada kedua database, atau menggunakan alat replikasi dua arah seperti [HVR](https://www.hvr-software.com/product/) untuk menjaga database tetap sinkron. Strategi ini memiliki kompleksitas yang lebih tinggi dalam hal penyiapan dan pemeliharaan, sehingga diperlukan lebih banyak pengujian untuk menghindari masalah konsistensi data.
Pada tingkat tinggi, konfigurasi basis data aktif/aktif melibatkan langkah-langkah berikut:
1. Selesaikan konversi skema.
1. Salin data yang ada dari database sumber ke database target, dan kemudian jaga agar kedua database tetap sinkron dengan menggunakan alat replikasi dua arah atau penulisan ganda dari aplikasi.
1. Ketika database sumber dan target disinkronkan, verifikasi data.
1. Mulai pindahkan subset lalu lintas Anda ke database baru.
1. Terus pindahkan lalu lintas sampai semua lalu lintas database Anda dipindahkan ke database baru.
## Migrasi inkremental
Dalam migrasi inkremental, Anda memigrasikan aplikasi Anda di bagian yang lebih kecil daripada melakukan pemotongan penuh satu kali. Strategi cutover ini dapat memiliki banyak variasi, berdasarkan arsitektur aplikasi Anda saat ini atau refactoring yang ingin Anda lakukan dalam aplikasi.
Anda dapat menggunakan [pola desain](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/) untuk menambahkan layanan mikro independen baru untuk menggantikan bagian dari aplikasi warisan monolitik yang ada. Layanan mikro independen ini memiliki tabel sendiri yang tidak dibagikan atau diakses oleh bagian lain dari aplikasi. Anda memigrasikan layanan mikro ini ke database baru satu per satu, menggunakan strategi cutover lainnya. Layanan mikro yang dimigrasi mulai menggunakan database baru untuk lalu lintas baca/tulis sementara semua bagian lain dari aplikasi terus menggunakan database lama. Ketika semua layanan mikro telah dimigrasi, Anda menonaktifkan aplikasi lama Anda. Strategi ini memecah migrasi menjadi potongan-potongan yang lebih kecil dan dapat dikelola dan oleh karena itu dapat mengurangi risiko yang terkait dengan satu migrasi besar.
# Ikuti praktik terbaik di AWS
Selain aktivitas migrasi yang dibahas di bagian sebelumnya, Anda harus menginvestasikan waktu untuk memastikan bahwa Anda mengikuti praktik terbaik untuk meng-host database Anda di AWS Cloud. Lihat [AWS dokumentasi](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html) untuk praktik terbaik untuk bekerja dengan database relasional di. AWS