Potong

Strategi cutover database biasanya erat ditambah dengan persyaratan downtime untuk aplikasi. Strategi yang dapat Anda gunakan untuk cutover database meliputi migrasi offline, migrasi flash-cut, konfigurasi database aktif/aktif, dan migrasi tambahan. Ini dibahas di bagian berikut.

Migrasi offline

Jika Anda dapat mengambil aplikasi Anda secara offline untuk jangka waktu lama selama operasi tulis, Anda dapat menggunakanAWS DMSsetelan tugas beban penuh atau salah satu opsi migrasi offline untuk migrasi data Anda. Lalu lintas baca dapat berlanjut saat migrasi ini sedang berlangsung, namun lalu lintas tulis harus dihentikan. Karena semua data perlu disalin dari database sumber, sumber sumber database seperti I/O dan CPU dimanfaatkan.

Pada tingkat tinggi, migrasi offline melibatkan langkah-langkah berikut:

1. Lengkapi konversi skema.

2. Mulai downtime untuk lalu lintas tulis.

3. Migrasikan data menggunakan salah satu opsi migrasi offline.

4. Verifikasi data Anda.

5. Arahkan aplikasi Anda ke basis data baru.

6. Akhiri downtime aplikasi.

Migrasi Flash-cut

Dalam migrasi flash-cut, tujuan utamanya adalah menjaga downtime seminimal mungkin. Strategi ini bergantung pada replikasi data (CDC) dari basis data sumber ke basis data target. Semua lalu lintas baca/tulis akan berlanjut pada database saat ini saat data sedang dimigrasi. Karena semua data perlu disalin dari database sumber, sumber sumber server seperti I/O dan CPU dimanfaatkan. Anda harus menguji untuk memastikan bahwa aktivitas migrasi data ini tidak memengaruhi SLA kinerja aplikasi Anda.

Pada tingkat tinggi, migrasi flash-cut melibatkan langkah-langkah berikut:

1. Lengkapi konversi skema.

2. MengaturAWS DMSdalam mode replikasi data terus menerus.

3. Saat database sumber dan target disinkronkan, verifikasi data.

4. Mulai downtime aplikasi.

5. Menggelar versi baru dari aplikasi, yang menunjuk ke database baru.

6. Akhiri downtime aplikasi.

Konfigurasi database aktif/aktif

Konfigurasi database aktif/aktif melibatkan pengaturan mekanisme untuk menjaga sumber dan target database sinkron sementara kedua database sedang digunakan untuk lalu lintas tulis. Strategi ini melibatkan lebih banyak pekerjaan daripada migrasi offline atau flash-cut, tetapi juga memberikan fleksibilitas lebih 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 bi-directional sepertiHVRuntuk menjaga database tetap sinkron. Strategi ini memiliki kompleksitas yang lebih tinggi dalam hal pengaturan dan pemeliharaan, sehingga pengujian lebih diperlukan untuk menghindari masalah konsistensi data.

Pada tingkat tinggi, konfigurasi database aktif/aktif melibatkan langkah-langkah berikut:

1. Lengkapi konversi skema.

2. Salin data yang ada dari database sumber ke database target, dan kemudian menjaga dua database sinkron dengan menggunakan alat replikasi bi-directional atau ganda menulis dari aplikasi.

3. Saat database sumber dan target disinkronkan, verifikasi data.

4. Mulai memindahkan bagian dari lalu lintas Anda ke database baru.

5. Terus bergerak lalu lintas sampai semua lalu lintas database Anda telah dipindahkan ke database baru.

Migrasi tambahan

Dalam migrasi tambahan, Anda memigrasikan aplikasi Anda di bagian yang lebih kecil daripada melakukan satu kali, cutover penuh. Strategi cutover ini bisa memiliki banyak variasi, berdasarkan arsitektur aplikasi Anda saat ini atau refactoring yang ingin Anda lakukan dalam aplikasi.

Anda dapat menggunakanpola desainuntuk menambahkan layanan mikro independen baru untuk mengganti bagian dari aplikasi warisan monolitik yang ada. Layanan mikro independen ini memiliki tabel mereka sendiri yang tidak dibagi atau diakses oleh bagian lain dari aplikasi. Anda memigrasikan microservices ini ke database baru satu per satu, menggunakan salah satu 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 mendekomisi aplikasi warisan Anda. Strategi ini memecah migrasi menjadi potongan-potongan yang lebih kecil dan dapat dikelola dan dapat, oleh karena itu, mengurangi risiko yang terkait dengan satu migrasi besar.