Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik
Jika Anda perlu menjaga ketersediaan aplikasi selama migrasi dari Apache Cassandra ke Amazon Keyspaces, Anda dapat menyiapkan strategi migrasi online khusus dengan menerapkan komponen utama yang dibahas dalam topik ini. Dengan mengikuti praktik terbaik untuk migrasi online ini, Anda dapat memastikan bahwa ketersediaan dan read-after-write konsistensi aplikasi dipertahankan selama seluruh proses migrasi, meminimalkan dampak pada pengguna Anda.
Saat merancang strategi migrasi online dari Apache Cassandra ke Amazon Keyspaces, Anda perlu mempertimbangkan langkah-langkah kunci berikut.
1. **Menulis data baru**
+ **ZDM Dual Write Proxy untuk Migrasi Keyspaces Amazon — Gunakan ZDM Dual Write Proxy yang tersedia di [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) untuk melakukan migrasi** zero-downtime dari Apache Cassandra ke Amazon Keyspaces. Proxy ZDM melakukan penulisan ganda tanpa perlu memfaktorkan ulang aplikasi yang ada dan melakukan pembacaan ganda untuk validasi kueri.
+ Application dual-write: Anda dapat menerapkan penulisan ganda dalam aplikasi Anda menggunakan pustaka dan driver klien Cassandra yang ada. Tentukan satu database sebagai pemimpin dan yang lainnya sebagai pengikut. Kegagalan menulis ke database pengikut dicatat dalam [antrian huruf mati (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) untuk analisis.
+ Tulis ganda tingkat pesan: Atau, Anda dapat mengonfigurasi platform perpesanan yang ada untuk mengirim tulisan ke Cassandra dan Amazon Keyspaces menggunakan konsumen tambahan. Ini pada akhirnya menciptakan tampilan yang konsisten di kedua database.
1. **Migrasi data historis**
+ Salin data historis: Anda dapat memigrasikan data historis dari Cassandra ke Amazon Keyspaces menggunakan AWS Glue atau kustom ekstrak, transformasi, dan muat (ETL) skrip. Menangani resolusi konflik antara penulisan ganda dan beban massal menggunakan teknik seperti transaksi ringan atau stempel waktu.
+ Gunakan Time-To-Live (TTL): Untuk periode retensi data yang lebih pendek, Anda dapat menggunakan TTL di Cassandra dan Amazon Keyspaces untuk menghindari mengunggah data historis yang tidak perlu. Karena data lama kedaluwarsa di Cassandra dan data baru ditulis melalui penulisan ganda, Amazon Keyspaces akhirnya menyusul.
1. **Memvalidasi data**
+ Pembacaan ganda: Menerapkan pembacaan ganda dari database Cassandra (primer) dan Amazon Keyspaces (sekunder), membandingkan hasil secara asinkron. Perbedaan dicatat atau dikirim ke DLQ.
+ Sampel dibaca: Gunakan fungsi Λ untuk mengambil sampel dan membandingkan data secara berkala di kedua sistem, mencatat perbedaan apa pun ke DLQ.
1. **Migrasi aplikasi**
+ Strategi biru-hijau: Alihkan aplikasi Anda untuk memperlakukan Amazon Keyspaces sebagai primer dan Cassandra sebagai penyimpanan data sekunder dalam satu langkah. Pantau kinerja dan putar kembali jika masalah muncul.
+ Penerapan Canary: Secara bertahap meluncurkan migrasi ke subset pengguna terlebih dahulu, secara bertahap meningkatkan lalu lintas ke Amazon Keyspaces sebagai primer hingga sepenuhnya dimigrasikan.
1. **Penonaktifan Cassandra**
Setelah aplikasi Anda sepenuhnya dimigrasikan ke Amazon Keyspaces dan konsistensi data divalidasi, Anda dapat merencanakan untuk menonaktifkan klaster Cassandra Anda berdasarkan kebijakan penyimpanan data.
Dengan merencanakan strategi migrasi online dengan komponen-komponen ini, Anda dapat bertransisi dengan lancar ke layanan Amazon Keyspaces yang dikelola sepenuhnya dengan waktu henti atau gangguan minimal. Bagian berikut masuk ke setiap komponen secara lebih rinci.
**Topics**
+ [Menulis data baru selama migrasi online](migration-online-dw.md)
+ [Mengunggah data historis selama migrasi online](migration-online-historical.md)
+ [Memvalidasi konsistensi data selama migrasi online](migration-online-validation.md)
+ [Migrasi aplikasi selama migrasi online](migration-online-app-migration.md)
+ [Menonaktifkan Cassandra setelah migrasi online](migration-online-decommission.md)
# Menulis data baru selama migrasi online
Langkah pertama dalam rencana migrasi online adalah memastikan bahwa setiap data baru yang ditulis oleh aplikasi disimpan di kedua database, cluster Cassandra yang ada, dan Amazon Keyspaces. Tujuannya adalah untuk memberikan pandangan yang konsisten di kedua penyimpanan data. Anda dapat melakukan ini dengan menerapkan semua penulisan baru ke kedua database. Untuk menerapkan penulisan ganda, pertimbangkan salah satu dari tiga opsi berikut.
+ **ZDM Dual Write Proxy untuk Migrasi Keyspaces Amazon** — Menggunakan Proxy ZDM untuk Amazon Keyspaces yang tersedia [di](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, Anda dapat memigrasikan beban kerja Apache Cassandra ke Amazon Keyspaces tanpa downtime aplikasi. Solusi yang disempurnakan ini menerapkan praktik AWS terbaik dan memperluas kemampuan Proxy ZDM resmi.
+ Lakukan migrasi online antara Apache Cassandra dan Amazon Keyspaces.
+ Tulis data ke tabel sumber dan target secara bersamaan tanpa aplikasi refactoring.
+ Validasi kueri melalui operasi dual-read.
Solusinya menawarkan penyempurnaan berikut untuk bekerja dengan dan AWS Amazon Keyspaces.
+ **Penyebaran kontainer** — Gunakan image Docker yang telah dikonfigurasi sebelumnya dari Amazon Elastic Container Registry (Amazon ECR) Registry (Amazon ECR) untuk penerapan yang dapat diakses VPC.
+ **Infrastruktur sebagai kode** - Terapkan menggunakan AWS CloudFormation templat untuk penyiapan otomatis aktif. AWS Fargate
+ **Kompatibilitas Amazon Keyspaces** — Akses tabel sistem dengan adaptasi khusus untuk Amazon Keyspaces.
Solusinya berjalan di Amazon ECS dengan Fargate, menyediakan skalabilitas tanpa server berdasarkan tuntutan beban kerja Anda. Penyeimbang beban jaringan mendistribusikan lalu lintas aplikasi yang masuk di beberapa tugas Amazon ECS untuk ketersediaan tinggi.
![\[Menerapkan proxy penulisan ganda ZDM untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Application dual write** — Anda dapat menerapkan penulisan ganda dengan perubahan minimal pada kode aplikasi Anda dengan memanfaatkan pustaka dan driver klien Cassandra yang ada. Anda dapat menerapkan penulisan ganda dalam aplikasi yang ada, atau membuat layer baru dalam arsitektur untuk menangani penulisan ganda. Untuk informasi lebih lanjut dan studi kasus pelanggan yang menunjukkan bagaimana penulisan ganda diimplementasikan dalam aplikasi yang ada, lihat Studi [kasus migrasi Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Saat menerapkan penulisan ganda, Anda dapat menunjuk satu database sebagai pemimpin dan database lainnya sebagai pengikut. Ini memungkinkan Anda untuk terus menulis ke sumber asli Anda, atau database pemimpin tanpa membiarkan kegagalan menulis ke pengikut, atau database tujuan mengganggu jalur kritis aplikasi Anda.
Alih-alih mencoba menulis ulang gagal ke pengikut, Anda dapat menggunakan Amazon Simple Queue Service untuk merekam penulisan gagal dalam [antrian surat mati](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) (DLQ). DLQ memungkinkan Anda menganalisis penulisan yang gagal ke pengikut dan menentukan mengapa pemrosesan tidak berhasil dalam database tujuan.
Untuk implementasi penulisan ganda yang lebih canggih, Anda dapat mengikuti praktik AWS terbaik untuk merancang urutan transaksi lokal menggunakan [pola saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Pola saga memastikan bahwa jika transaksi gagal, saga menjalankan transaksi kompensasi untuk mengembalikan perubahan database yang dibuat oleh transaksi sebelumnya.
Saat menggunakan dual-write untuk migrasi online, Anda dapat mengonfigurasi penulisan ganda mengikuti pola saga sehingga setiap penulisan adalah transaksi lokal untuk memastikan operasi atom di seluruh database heterogen. Untuk informasi selengkapnya tentang merancang aplikasi terdistribusi menggunakan pola desain yang direkomendasikanAWS Cloud, lihat [Pola, arsitektur, dan implementasi desain Cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Menerapkan penulisan ganda di lapisan aplikasi saat bermigrasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Messaging tier dual write** — Alih-alih menerapkan penulisan ganda di lapisan aplikasi, Anda dapat menggunakan tingkat perpesanan yang ada untuk melakukan penulisan ganda ke Cassandra dan Amazon Keyspaces.
Untuk melakukan ini, Anda dapat mengonfigurasi konsumen tambahan ke platform perpesanan Anda untuk mengirim tulisan ke kedua penyimpanan data. Pendekatan ini menyediakan strategi kode rendah sederhana menggunakan tingkat pesan untuk membuat dua tampilan di kedua database yang pada akhirnya konsisten.
# Mengunggah data historis selama migrasi online
Setelah menerapkan penulisan ganda untuk memastikan bahwa data baru ditulis ke kedua penyimpanan data secara real time, langkah selanjutnya dalam rencana migrasi adalah mengevaluasi berapa banyak data historis yang perlu Anda salin atau unggah massal dari Cassandra ke Amazon Keyspaces. Ini memastikan bahwa data baru dan data historis akan tersedia di database Amazon Keyspaces baru sebelum Anda memigrasikan aplikasi.
Bergantung pada persyaratan penyimpanan data Anda, misalnya berapa banyak data historis yang perlu Anda pertahankan berdasarkan kebijakan organisasi Anda, Anda dapat mempertimbangkan salah satu dari dua opsi berikut.
+ **Pengunggahan massal data historis** — Migrasi data historis dari penyebaran Cassandra Anda yang ada ke Amazon Keyspaces dapat dicapai melalui berbagai teknik, misalnya menggunakan AWS Glue atau skrip khusus untuk mengekstrak, mengubah, dan memuat (ETL) data. Untuk informasi selengkapnya tentang penggunaan AWS Glue untuk mengunggah data historis, lihat[Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md).
Saat merencanakan unggahan massal data historis, Anda perlu mempertimbangkan cara menyelesaikan konflik yang dapat terjadi ketika penulisan baru mencoba memperbarui data yang sama yang sedang dalam proses diunggah. Upload massal diharapkan pada akhirnya konsisten, yang berarti data akan mencapai semua node pada akhirnya.
Jika pembaruan data yang sama terjadi pada saat yang sama karena penulisan baru, Anda ingin memastikan bahwa itu tidak akan ditimpa oleh unggahan data historis. Untuk memastikan bahwa Anda mempertahankan pembaruan terbaru pada data Anda bahkan selama impor massal, Anda harus menambahkan resolusi konflik baik ke dalam skrip unggahan massal atau ke dalam logika aplikasi untuk penulisan ganda.
Misalnya, Anda dapat menggunakan [Transaksi ringan](functional-differences.md#functional-differences.light-transactions) (LWT) untuk membandingkan dan mengatur operasi. Untuk melakukan ini, Anda dapat menambahkan bidang tambahan ke model data Anda yang mewakili waktu modifikasi atau status.
Selain itu, Amazon Keyspaces mendukung fungsi stempel waktu Cassandra`WRITETIME`. Anda dapat menggunakan stempel waktu sisi klien Amazon Keyspaces untuk mempertahankan stempel waktu database sumber dan menerapkan resolusi konflik. last-writer-wins Untuk informasi selengkapnya, lihat [Stempel waktu sisi klien di Amazon Keyspaces](client-side-timestamps.md).
+ **Menggunakan Time-to-Live (TTL)** — Untuk periode retensi data yang lebih pendek dari 30, 60, atau 90 hari, Anda dapat menggunakan TTL di Cassandra dan Amazon Keyspaces selama migrasi untuk menghindari mengunggah data historis yang tidak perlu ke Amazon Keyspaces. TTL memungkinkan Anda untuk mengatur periode waktu setelah data dihapus secara otomatis dari database.
Selama fase migrasi, alih-alih menyalin data historis ke Amazon Keyspaces, Anda dapat mengonfigurasi pengaturan TTL agar data historis kedaluwarsa secara otomatis di sistem lama (Cassandra) sambil hanya menerapkan penulisan baru ke Amazon Keyspaces menggunakan metode penulisan ganda. Seiring waktu dan dengan data lama yang terus kedaluwarsa di cluster Cassandra dan data baru yang ditulis menggunakan metode dual-write, Amazon Keyspaces secara otomatis menangkap data yang sama dengan Cassandra.
Pendekatan ini dapat secara signifikan mengurangi jumlah data yang akan dimigrasi, menghasilkan proses migrasi yang lebih efisien dan efisien. Anda dapat mempertimbangkan pendekatan ini ketika berhadapan dengan kumpulan data besar dengan berbagai persyaratan retensi data. Untuk informasi lebih lanjut tentang TTL, lihat[Data kedaluwarsa dengan Time to Live (TTL) untuk Amazon Keyspaces (untuk Apache Cassandra)](TTL.md).
Pertimbangkan contoh migrasi dari Cassandra ke Amazon Keyspaces berikut menggunakan kedaluwarsa data TTL. Dalam contoh ini kami menetapkan TTL untuk kedua database ke 60 hari dan menunjukkan bagaimana proses migrasi berlangsung selama periode 90 hari. Kedua database menerima data yang baru ditulis yang sama selama periode ini menggunakan metode penulisan ganda. Kita akan melihat tiga fase migrasi yang berbeda, setiap fase adalah 30 hari.
Cara kerja proses migrasi untuk setiap fase ditunjukkan pada gambar berikut.
![\[Menggunakan TTL untuk kedaluwarsa data historis saat bermigrasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Setelah 30 hari pertama, cluster Cassandra dan Amazon Keyspaces telah menerima penulisan baru. Cluster Cassandra juga berisi data historis yang belum mencapai retensi 60 hari, yang merupakan 50% dari data dalam cluster.
Data yang lebih tua dari 60 hari secara otomatis dihapus di cluster Cassandra menggunakan TTL. Pada titik ini Amazon Keyspaces berisi 50% data yang disimpan di cluster Cassandra, yang terdiri dari penulisan baru dikurangi data historis.
1. Setelah 60 hari, cluster Cassandra dan Amazon Keyspaces berisi data yang sama yang ditulis dalam 60 hari terakhir.
1. Dalam 90 hari, Cassandra dan Amazon Keyspaces berisi data yang sama dan data kedaluwarsa dengan kecepatan yang sama.
Contoh ini menggambarkan cara menghindari langkah mengunggah data historis dengan menggunakan TTL dengan tanggal kedaluwarsa yang ditetapkan ke 60 hari.
# Memvalidasi konsistensi data selama migrasi online
Langkah selanjutnya dalam proses migrasi online adalah validasi data. Penulisan ganda menambahkan data baru ke database Amazon Keyspaces Anda dan Anda telah menyelesaikan migrasi data historis baik menggunakan unggahan massal atau kedaluwarsa data dengan TTL.
Sekarang Anda dapat menggunakan fase validasi untuk mengonfirmasi bahwa kedua penyimpanan data sebenarnya berisi data yang sama dan mengembalikan hasil baca yang sama. Anda dapat memilih dari salah satu dari dua opsi berikut untuk memvalidasi bahwa kedua database Anda berisi data yang identik.
+ **Bacaan ganda** — Untuk memvalidasi bahwa keduanya, sumber dan database tujuan berisi kumpulan data yang baru ditulis dan historis yang sama, Anda dapat menerapkan pembacaan ganda. Untuk melakukannya, Anda membaca dari Cassandra utama dan database Amazon Keyspaces sekunder Anda mirip dengan metode penulisan ganda dan membandingkan hasilnya secara asinkron.
Hasil dari database utama dikembalikan ke klien, dan hasil dari database sekunder digunakan untuk memvalidasi terhadap kumpulan hasil utama. Perbedaan yang ditemukan dapat dicatat atau dikirim ke [antrian surat mati (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) untuk rekonsiliasi nanti.
Dalam diagram berikut, aplikasi melakukan pembacaan sinkron dari Cassandra, yang merupakan penyimpanan data utama) dan pembacaan asinkron dari Amazon Keyspaces, yang merupakan penyimpanan data sekunder.
![\[Menggunakan pembacaan ganda untuk memvalidasi konsistensi data selama migrasi online dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Pembacaan sampel** — Solusi alternatif yang tidak memerlukan perubahan kode aplikasi adalah dengan menggunakan AWS Lambda fungsi untuk mengambil sampel data secara berkala dan acak dari cluster Cassandra sumber dan database Amazon Keyspaces tujuan.
Fungsi Lambda ini dapat dikonfigurasi untuk berjalan secara berkala. Fungsi Lambda mengambil subset data acak dari sistem sumber dan tujuan, dan kemudian melakukan perbandingan data sampel. Setiap perbedaan atau ketidakcocokan antara dua kumpulan data dapat direkam dan dikirim ke [antrian surat mati khusus (](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)DLQ) untuk rekonsiliasi nanti.
Proses ini diilustrasikan dalam diagram berikut.
![\[Menggunakan pembacaan sampel untuk memvalidasi konsistensi data selama dan migrasi online dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrasi aplikasi selama migrasi online
Pada fase keempat migrasi online, Anda memigrasikan aplikasi dan beralih ke Amazon Keyspaces sebagai penyimpanan data utama. Ini berarti Anda mengalihkan aplikasi Anda untuk membaca dan menulis langsung dari dan ke Amazon Keyspaces. Untuk memastikan gangguan minimal pada pengguna Anda, ini harus menjadi proses yang terencana dan terkoordinasi dengan baik.
Tersedia dua solusi berbeda yang direkomendasikan untuk migrasi aplikasi, strategi pemotongan hijau biru dan strategi pemotongan kenari. Bagian berikut menguraikan strategi ini secara lebih rinci.
+ **Strategi hijau biru** — Dengan menggunakan pendekatan ini, Anda mengalihkan aplikasi Anda untuk memperlakukan Amazon Keyspaces sebagai penyimpanan data utama dan Cassandra sebagai penyimpanan data sekunder dalam satu langkah. Anda dapat melakukan ini menggunakan flag AWS AppConfig fitur untuk mengontrol pemilihan penyimpanan data primer dan sekunder di seluruh instance aplikasi. Untuk informasi selengkapnya tentang flag fitur, lihat [Membuat profil konfigurasi flag fitur di AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Setelah menjadikan Amazon Keyspaces sebagai penyimpanan data utama, Anda memantau perilaku dan kinerja aplikasi, memastikan bahwa Amazon Keyspaces memenuhi persyaratan Anda dan migrasi berhasil.
Misalnya, jika Anda menerapkan pembacaan ganda untuk aplikasi Anda, selama fase migrasi aplikasi Anda mentransisikan pembacaan utama dari Cassandra ke Amazon Keyspaces dan pembacaan sekunder dari Amazon Keyspaces ke Cassandra. Setelah transisi, Anda terus memantau dan membandingkan hasil seperti yang dijelaskan di bagian [validasi data](migration-online-validation.md) untuk memastikan konsistensi di kedua database sebelum menonaktifkan Cassandra.
Jika Anda mendeteksi masalah apa pun, Anda dapat dengan cepat memutar kembali ke keadaan sebelumnya dengan kembali ke Cassandra sebagai penyimpanan data utama. Anda hanya melanjutkan ke fase penonaktifan migrasi jika Amazon Keyspaces memenuhi semua kebutuhan Anda sebagai penyimpanan data utama.
![\[Menggunakan strategi hijau biru untuk memigrasikan aplikasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Strategi kenari** — Dalam pendekatan ini, Anda secara bertahap meluncurkan migrasi ke subset pengguna atau lalu lintas Anda. Awalnya, sebagian kecil dari lalu lintas aplikasi Anda, misalnya 5% dari semua lalu lintas dirutekan ke versi menggunakan Amazon Keyspaces sebagai penyimpanan data utama, sementara sisa lalu lintas terus menggunakan Cassandra sebagai penyimpanan data utama.
Ini memungkinkan Anda untuk menguji versi migrasi secara menyeluruh dengan lalu lintas dunia nyata dan memantau kinerja, stabilitas, dan menyelidiki potensi masalah. Jika Anda tidak mendeteksi masalah apa pun, Anda dapat secara bertahap meningkatkan persentase lalu lintas yang dirutekan ke Amazon Keyspaces hingga menjadi penyimpanan data utama untuk semua pengguna dan lalu lintas.
Peluncuran bertahap ini meminimalkan risiko gangguan layanan yang meluas dan memungkinkan proses migrasi yang lebih terkontrol. Jika ada masalah kritis yang muncul selama penyebaran kenari, Anda dapat dengan cepat memutar kembali ke versi sebelumnya menggunakan Cassandra sebagai penyimpanan data utama untuk segmen lalu lintas yang terpengaruh. Anda hanya melanjutkan ke fase penonaktifan migrasi setelah Anda memvalidasi bahwa Amazon Keyspaces memproses 100% pengguna dan lalu lintas Anda seperti yang diharapkan.
Diagram berikut menggambarkan langkah-langkah individu dari strategi kenari.
![\[Menggunakan strategi kenari untuk memigrasikan aplikasi dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Menonaktifkan Cassandra setelah migrasi online
Setelah migrasi aplikasi selesai dengan aplikasi Anda sepenuhnya berjalan di Amazon Keyspaces dan Anda telah memvalidasi konsistensi data selama periode waktu tertentu, Anda dapat merencanakan untuk menonaktifkan cluster Cassandra Anda. Selama fase ini, Anda dapat mengevaluasi apakah data yang tersisa di cluster Cassandra Anda perlu diarsipkan atau dapat dihapus. Ini tergantung pada kebijakan organisasi Anda untuk penanganan dan penyimpanan data.
Dengan mengikuti strategi ini dan mempertimbangkan praktik terbaik yang direkomendasikan yang dijelaskan dalam topik ini saat merencanakan migrasi online Anda dari Cassandra ke Amazon Keyspaces, Anda dapat memastikan transisi yang mulus ke Amazon Keyspaces sambil read-after-write mempertahankan konsistensi dan ketersediaan aplikasi Anda.
Bermigrasi dari Apache Cassandra ke Amazon Keyspaces dapat memberikan banyak manfaat, termasuk pengurangan overhead operasional, penskalaan otomatis, keamanan yang ditingkatkan, dan kerangka kerja yang membantu Anda mencapai tujuan kepatuhan Anda. Dengan merencanakan strategi migrasi online dengan penulisan ganda, pengunggahan data historis, validasi data, dan peluncuran bertahap, Anda dapat memastikan transisi yang mulus dengan gangguan minimal pada aplikasi Anda dan penggunanya.
Menerapkan strategi migrasi online yang dibahas dalam topik ini memungkinkan Anda memvalidasi hasil migrasi, mengidentifikasi dan mengatasi masalah apa pun, dan pada akhirnya menonaktifkan penerapan Cassandra yang ada demi layanan Amazon Keyspaces yang dikelola sepenuhnya.