Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Buat rencana migrasi untuk migrasi dari Apache Cassandra ke Amazon Keyspaces
Agar migrasi berhasil dari Apache Cassandra ke Amazon Keyspaces, kami merekomendasikan peninjauan konsep migrasi yang berlaku dan praktik terbaik serta perbandingan opsi yang tersedia.
Topik ini menguraikan cara kerja proses migrasi dengan memperkenalkan beberapa konsep kunci dan alat serta teknik yang tersedia untuk Anda. Anda dapat mengevaluasi berbagai strategi migrasi untuk memilih salah satu yang paling sesuai dengan kebutuhan Anda.
**Topics**
+ [Kompatibilitas fungsional](#migrating-cassandra-compatibility)
+ [Perkirakan harga Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Pilih strategi migrasi](#migrating-cassandra-strategy)
+ [Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik](migrating-online.md)
+ [Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md)
+ [Menggunakan solusi migrasi hibrida: Apache Cassandra ke Amazon Keyspaces](migrating-hybrid.md)
## Kompatibilitas fungsional
Pertimbangkan perbedaan fungsional antara Apache Cassandra dan Amazon Keyspaces dengan hati-hati sebelum migrasi. Amazon Keyspaces mendukung semua operasi bidang data Cassandra yang umum digunakan, seperti membuat ruang kunci dan tabel, membaca data, dan menulis data.
Namun ada beberapa Cassandra yang tidak APIs didukung Amazon Keyspaces. Untuk informasi selengkapnya tentang dukungan APIs, lihat[Cassandra APIs, operasi, fungsi, dan tipe data yang didukung](cassandra-apis.md). Untuk gambaran umum tentang semua perbedaan fungsional antara Amazon Keyspaces dan Apache Cassandra, lihat. [Perbedaan fungsional: Amazon Keyspaces vs Apache Cassandra](functional-differences.md)
Untuk membandingkan Cassandra APIs dan skema yang Anda gunakan dengan fungsionalitas yang didukung di Amazon Keyspaces, Anda dapat menjalankan skrip kompatibilitas yang tersedia di toolkit Amazon Keyspaces. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Cara menggunakan skrip kompatibilitas**
1. Unduh skrip Python kompatibilitas dari [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)dan pindahkan ke lokasi yang memiliki akses ke cluster Apache Cassandra Anda yang ada.
1. Skrip kompatibilitas menggunakan parameter yang sama seperti`CQLSH`. Untuk `--host` dan `--port` masukkan alamat IP dan port yang Anda gunakan untuk menghubungkan dan menjalankan kueri ke salah satu node Cassandra di cluster Anda.
Jika cluster Cassandra Anda menggunakan otentikasi, Anda juga perlu menyediakan dan. `-username` `-password` Untuk menjalankan skrip kompatibilitas, Anda dapat menggunakan perintah berikut.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Perkirakan harga Amazon Keyspaces
Bagian ini memberikan gambaran umum tentang informasi yang perlu Anda kumpulkan dari tabel Apache Cassandra Anda untuk menghitung perkiraan biaya Amazon Keyspaces. Setiap tabel Anda memerlukan tipe data yang berbeda, perlu mendukung kueri CQL yang berbeda, dan mempertahankan lalu lintas yang berbeda. read/write
Memikirkan kebutuhan Anda berdasarkan tabel sejalan dengan isolasi sumber daya tingkat tabel Amazon Keyspaces [dan](ReadWriteCapacityMode.md) mode kapasitas throughput baca/tulis. Dengan Amazon Keyspaces, Anda dapat menentukan kapasitas baca/tulis dan kebijakan [penskalaan otomatis](autoscaling.md) untuk tabel secara independen.
Memahami persyaratan tabel membantu Anda memprioritaskan tabel untuk migrasi berdasarkan fungsionalitas, biaya, dan upaya migrasi.
Kumpulkan metrik tabel Cassandra berikut sebelum migrasi. Informasi ini membantu memperkirakan biaya beban kerja Anda di Amazon Keyspaces.
+ **Nama tabel** - Nama ruang kunci dan nama tabel yang sepenuhnya memenuhi syarat.
+ **Deskripsi** — Deskripsi tabel, misalnya bagaimana itu digunakan, atau jenis data apa yang disimpan di dalamnya.
+ **Pembacaan rata-rata per detik** — Jumlah rata-rata pembacaan tingkat koordinat terhadap tabel selama interval waktu yang besar.
+ **Rata-rata menulis per detik** — Jumlah rata-rata tingkat koordinat menulis terhadap tabel selama interval waktu yang besar.
+ **Ukuran baris rata-rata dalam byte** - Ukuran baris rata-rata dalam byte.
+ **Ukuran penyimpanan di GBs** — Ukuran penyimpanan mentah untuk sebuah meja.
+ **Rincian konsistensi baca** — Persentase pembacaan yang menggunakan konsistensi akhirnya (`LOCAL_ONE`atau`ONE`) vs. konsistensi kuat (`LOCAL_QUORUM`).
Tabel ini menunjukkan contoh informasi tentang tabel yang perlu Anda kumpulkan saat merencanakan migrasi.
****
| Nama tabel | Deskripsi | Rata-rata membaca per detik | Rata-rata menulis per detik | Ukuran baris rata-rata dalam byte | Ukuran penyimpanan di GBs | Baca rincian konsistensi |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Digunakan untuk menyimpan sejarah keranjang belanja | 10.000 | 5.000 | 2.200 | 2.000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | Digunakan untuk menyimpan informasi profil terbaru | 20.000 | 1.000 | 850 | 1.000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### Cara mengumpulkan metrik tabel
Bagian ini memberikan petunjuk langkah demi langkah tentang cara mengumpulkan metrik tabel yang diperlukan dari cluster Cassandra Anda yang ada. Metrik ini mencakup ukuran baris, ukuran tabel, dan read/write permintaan per detik (RPS). Mereka memungkinkan Anda menilai persyaratan kapasitas throughput untuk tabel Amazon Keyspaces dan memperkirakan harga.
**Cara mengumpulkan metrik tabel di tabel sumber Cassandra**
1. Tentukan ukuran baris
Ukuran baris penting untuk menentukan kapasitas baca dan pemanfaatan kapasitas tulis di Amazon Keyspaces. Diagram berikut menunjukkan distribusi data tipikal pada rentang token Cassandra.
![\[Diagram yang menunjukkan distribusi data tipikal pada rentang token Cassandra menggunakan partisi. murmur3\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Anda dapat menggunakan skrip sampler ukuran baris yang tersedia [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)untuk mengumpulkan metrik ukuran baris untuk setiap tabel di cluster Cassandra Anda.
Skrip mengekspor data tabel dari Apache Cassandra dengan menggunakan `cqlsh` dan `awk` menghitung min, maks, rata-rata, dan standar deviasi ukuran baris atas kumpulan sampel data tabel yang dapat dikonfigurasi. Sampler ukuran baris meneruskan argumen ke`cqlsh`, sehingga parameter yang sama dapat digunakan untuk menghubungkan dan membaca dari cluster Cassandra Anda.
Pernyataan berikut adalah contoh dari ini.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Untuk informasi selengkapnya tentang cara menghitung ukuran baris di Amazon Keyspaces, lihat. [Perkirakan ukuran baris di Amazon Keyspaces](calculating-row-size.md)
1. Tentukan ukuran tabel
Dengan Amazon Keyspaces, Anda tidak perlu menyediakan penyimpanan terlebih dahulu. Amazon Keyspaces memantau ukuran tabel yang dapat ditagih secara terus menerus untuk menentukan biaya penyimpanan Anda. Penyimpanan ditagih per GB-bulan. Ukuran tabel Amazon Keyspaces didasarkan pada ukuran mentah (tidak terkompresi) dari satu replika.
Untuk memantau ukuran tabel di Amazon Keyspaces, Anda dapat menggunakan metrik`BillableTableSizeInBytes`, yang ditampilkan untuk setiap tabel di. Konsol Manajemen AWS
Untuk memperkirakan ukuran tabel Amazon Keyspaces yang dapat ditagih, Anda dapat menggunakan salah satu dari dua metode ini:
+ Gunakan ukuran baris rata-rata dan kalikan dengan angka atau baris.
Anda dapat memperkirakan ukuran tabel Amazon Keyspaces dengan mengalikan ukuran baris rata-rata dengan jumlah baris dari tabel sumber Cassandra Anda. Gunakan skrip sampel ukuran baris dari bagian sebelumnya untuk menangkap ukuran baris rata-rata. Untuk menangkap jumlah baris, Anda dapat menggunakan alat seperti `dsbulk count` untuk menentukan jumlah total baris di tabel sumber Anda.
+ Gunakan metadata tabel `nodetool` untuk mengumpulkan.
`Nodetool`adalah alat administrasi yang disediakan dalam distribusi Apache Cassandra yang memberikan wawasan tentang keadaan proses Cassandra dan mengembalikan metadata tabel. Anda dapat menggunakan `nodetool` metadata sampel tentang ukuran tabel dan dengan itu mengekstrapolasi ukuran tabel di Amazon Keyspaces.
Perintah yang harus digunakan adalah`nodetool tablestats`. Tablestats mengembalikan ukuran tabel dan rasio kompresi. Ukuran tabel disimpan sebagai `tablelivespace` untuk tabel dan Anda dapat membaginya dengan`compression ratio`. Kemudian gandakan nilai ukuran ini dengan jumlah node. Akhirnya bagi dengan faktor replikasi (biasanya tiga).
Ini adalah rumus lengkap untuk perhitungan yang dapat Anda gunakan untuk menilai ukuran tabel.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Mari kita asumsikan bahwa cluster Cassandra Anda memiliki 12 node. Menjalankan `nodetool tablestats` perintah mengembalikan 200 GB dan `compression ratio` 0,5. `tablelivespace` Ruang kunci memiliki faktor replikasi tiga.
Seperti inilah perhitungan untuk contoh ini.
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. Menangkap jumlah membaca dan menulis
Untuk menentukan persyaratan kapasitas dan penskalaan untuk tabel Amazon Keyspaces Anda, tangkap tingkat permintaan baca dan tulis tabel Cassandra Anda sebelum migrasi.
Amazon Keyspaces tanpa server dan Anda hanya membayar untuk apa yang Anda gunakan. Secara umum, harga read/write throughput di Amazon Keyspaces didasarkan pada jumlah dan ukuran permintaan.
Ada dua mode kapasitas di Amazon Keyspaces:
+ [On-demand](ReadWriteCapacityMode.OnDemand.md) — Ini adalah opsi penagihan fleksibel yang mampu melayani ribuan permintaan per detik tanpa perlu perencanaan kapasitas. Ini menawarkan pay-per-request harga untuk permintaan baca dan tulis sehingga Anda hanya membayar untuk apa yang Anda gunakan.
+ [Disediakan](ReadWriteCapacityMode.Provisioned.md) — Jika Anda memilih mode kapasitas throughput yang disediakan, Anda menentukan jumlah pembacaan dan penulisan per detik yang diperlukan untuk aplikasi Anda. Ini membantu Anda mengelola penggunaan Amazon Keyspaces agar tetap pada atau di bawah tingkat permintaan yang ditentukan untuk mempertahankan prediktabilitas.
Mode yang disediakan menawarkan [penskalaan otomatis](autoscaling.md) untuk secara otomatis menyesuaikan tarif yang disediakan untuk meningkatkan atau menurunkan skala guna meningkatkan efisiensi operasional. Untuk informasi selengkapnya tentang manajemen sumber daya tanpa server, lihat. [Mengelola sumber daya tanpa server di Amazon Keyspaces (untuk Apache Cassandra)](serverless_resource_management.md)
Karena Anda menyediakan kapasitas throughput baca dan tulis di Amazon Keyspaces secara terpisah, Anda perlu mengukur tingkat permintaan untuk membaca dan menulis di tabel yang ada secara independen.
Untuk mengumpulkan metrik pemanfaatan paling akurat dari cluster Cassandra yang ada, tangkap permintaan rata-rata per detik (RPS) untuk operasi baca dan tulis tingkat koordinator selama periode waktu yang lama untuk tabel yang dikumpulkan di semua node dalam satu pusat data.
Menangkap RPS rata-rata selama periode setidaknya beberapa minggu menangkap puncak dan lembah dalam pola lalu lintas Anda, seperti yang ditunjukkan pada diagram berikut.
![\[Diagram yang menunjukkan tingkat rata-rata permintaan per detik per hari selama dua minggu.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-rps.png)
Anda memiliki dua opsi untuk menentukan tingkat permintaan baca dan tulis dari tabel Cassandra Anda.
+ Gunakan pemantauan Cassandra yang ada
Anda dapat menggunakan metrik yang ditampilkan dalam tabel berikut untuk mengamati permintaan baca dan tulis. Perhatikan bahwa nama metrik dapat berubah berdasarkan alat pemantauan yang Anda gunakan.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/migrating-cassandra.html)
+ Gunakan `nodetool`
Gunakan `nodetool tablestats` dan `nodetool info` untuk menangkap rata-rata operasi baca dan tulis dari tabel. `tablestats`mengembalikan total jumlah baca dan tulis dari waktu node telah dimulai. `nodetool info`menyediakan up-time untuk node dalam hitungan detik.
Untuk menerima rata-rata per detik membaca dan menulis, bagilah jumlah baca dan tulis dengan waktu aktif node dalam hitungan detik. Kemudian, untuk pembacaan Anda membagi dengan iklan tingkat konsistensi untuk penulisan yang Anda bagi dengan faktor replikasi. Perhitungan ini dinyatakan dalam rumus berikut.
Rumus untuk pembacaan rata-rata per detik:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Rumus untuk penulisan rata-rata per detik:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Mari kita asumsikan kita memiliki 12 node cluster yang telah naik selama 4 minggu. `nodetool info`mengembalikan 2.419.200 detik up-time dan `nodetool tablestats` mengembalikan 1 miliar penulisan dan 2 miliar pembacaan. Contoh ini akan menghasilkan perhitungan berikut.
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. Tentukan pemanfaatan kapasitas tabel
Untuk memperkirakan pemanfaatan kapasitas rata-rata, mulailah dengan tingkat permintaan rata-rata dan ukuran baris rata-rata tabel sumber Cassandra Anda.
Amazon Keyspaces menggunakan *read capacity units* (RCUs) dan *write capacity units* (WCUs) untuk mengukur kapasitas throughput yang disediakan untuk membaca dan menulis untuk tabel. Untuk perkiraan ini, kami menggunakan unit ini untuk menghitung kebutuhan kapasitas baca dan tulis dari tabel Amazon Keyspaces baru setelah migrasi.
Nanti dalam topik ini kita akan membahas bagaimana pilihan antara mode kapasitas yang disediakan dan sesuai permintaan memengaruhi penagihan. Tetapi untuk perkiraan pemanfaatan kapasitas dalam contoh ini, kami berasumsi bahwa tabel dalam mode yang disediakan.
+ **Membaca** - Satu RCU mewakili satu permintaan `LOCAL_QUORUM` baca, atau dua permintaan `LOCAL_ONE` baca, untuk satu baris hingga 4 KB. Jika Anda perlu membaca baris yang lebih besar dari 4 KB, operasi baca menggunakan tambahan RCUs. Jumlah total yang RCUs dibutuhkan tergantung pada ukuran baris, dan apakah Anda ingin menggunakan `LOCAL_QUORUM` atau `LOCAL_ONE` membaca konsistensi.
Misalnya, membaca baris 8 KB membutuhkan 2 RCUs menggunakan konsistensi `LOCAL_QUORUM` baca, dan 1 RCU jika Anda memilih konsistensi `LOCAL_ONE` baca.
+ **Menulis** — Satu WCU mewakili satu tulis untuk satu baris dengan ukuran hingga 1 KB. Semua penulisan menggunakan `LOCAL_QUORUM` konsistensi, dan tidak ada biaya tambahan untuk menggunakan transaksi ringan (LWTs).
Jumlah total yang WCUs dibutuhkan tergantung pada ukuran baris. Jika Anda perlu menulis baris yang lebih besar dari 1 KB, operasi tulis menggunakan tambahan WCUs. Misalnya, jika ukuran baris Anda adalah 2 KB, Anda memerlukan 2 WCUs untuk melakukan satu permintaan tulis.
Rumus berikut dapat digunakan untuk memperkirakan yang dibutuhkan RCUs dan WCUs.
+ **Kapasitas baca RCUs** dapat ditentukan dengan mengalikan pembacaan per detik dengan jumlah baris yang dibaca per bacaan dikalikan dengan ukuran baris rata-rata dibagi 4KB dan dibulatkan ke atas ke bilangan bulat terdekat.
+ **Kapasitas tulis dalam WCUs** dapat ditentukan dengan mengalikan jumlah permintaan dengan ukuran baris rata-rata dibagi dengan 1KB dan dibulatkan ke bilangan bulat terdekat.
Ini dinyatakan dalam rumus berikut.
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
Misalnya, jika Anda melakukan 4.960 permintaan baca dengan ukuran baris 2,5KB di tabel Cassandra Anda, Anda memerlukan 4.960 di Amazon Keyspaces. RCUs Jika saat ini Anda melakukan 1.653 permintaan tulis per detik dengan ukuran baris 2,5KB di tabel Cassandra Anda, Anda memerlukan 4.959 per detik di Amazon Keyspaces. WCUs
Contoh ini dinyatakan dalam rumus berikut.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
Menggunakan `eventual consistency` memungkinkan Anda menghemat hingga setengah dari kapasitas throughput pada setiap permintaan baca. Setiap pembacaan yang konsisten pada akhirnya dapat mengkonsumsi hingga 8KB. Anda dapat menghitung pembacaan konsisten akhirnya dengan mengalikan perhitungan sebelumnya dengan 0,5 seperti yang ditunjukkan pada rumus berikut.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Hitung estimasi harga bulanan untuk Amazon Keyspaces
Untuk memperkirakan penagihan bulanan untuk tabel berdasarkan throughput read/write kapasitas, Anda dapat menghitung harga untuk on-demand dan untuk mode yang disediakan menggunakan rumus yang berbeda dan membandingkan opsi untuk tabel Anda.
**Mode yang disediakan** - Konsumsi kapasitas baca dan tulis ditagih dengan tarif per jam berdasarkan unit kapasitas per detik. Pertama, bagi tingkat itu dengan 0,7 untuk mewakili pemanfaatan target autoscaling default sebesar 70%. Kemudian beberapa kali dengan 30 hari kalender, 24 jam per hari, dan harga tarif regional.
Perhitungan ini dirangkum dalam rumus berikut.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**Mode sesuai permintaan** - Kapasitas baca dan tulis ditagih berdasarkan tarif per permintaan. Pertama, kalikan tingkat permintaan dengan 30 hari kalender, dan 24 jam per hari. Kemudian bagi dengan satu juta unit permintaan. Akhirnya, kalikan dengan tarif regional.
Perhitungan ini dirangkum dalam rumus berikut.
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## Pilih strategi migrasi
Anda dapat memilih di antara strategi migrasi berikut saat bermigrasi dari Apache Cassandra ke Amazon Keyspaces:
+ **Online** — Ini adalah migrasi langsung menggunakan penulisan ganda untuk mulai menulis data baru ke Amazon Keyspaces dan cluster Cassandra secara bersamaan. Jenis migrasi ini direkomendasikan untuk aplikasi yang tidak memerlukan waktu henti selama migrasi dan konsistensi baca setelah penulisan.
Untuk informasi selengkapnya tentang cara merencanakan dan menerapkan strategi migrasi online, lihat[Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik](migrating-online.md).
+ **Offline** — Teknik migrasi ini melibatkan penyalinan kumpulan data dari Cassandra ke Amazon Keyspaces selama jendela downtime. Migrasi offline dapat menyederhanakan proses migrasi, karena tidak memerlukan perubahan pada aplikasi Anda atau resolusi konflik antara data historis dan penulisan baru.
Untuk informasi selengkapnya tentang cara merencanakan migrasi offline, lihat[Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces](migrating-offline.md).
+ **Hybrid** — Teknik migrasi ini memungkinkan perubahan direplikasi ke Amazon Keyspaces dalam waktu dekat, tetapi tanpa konsistensi baca demi tulis.
Untuk informasi selengkapnya tentang cara merencanakan migrasi hibrida, lihat[Menggunakan solusi migrasi hibrida: Apache Cassandra ke Amazon Keyspaces](migrating-hybrid.md).
Setelah meninjau teknik migrasi dan praktik terbaik yang dibahas dalam topik ini, Anda dapat menempatkan opsi yang tersedia di pohon keputusan untuk merancang strategi migrasi berdasarkan kebutuhan dan sumber daya yang tersedia.
# 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.
# Proses migrasi offline: Apache Cassandra ke Amazon Keyspaces
Migrasi offline cocok bila Anda mampu melakukan downtime untuk melakukan migrasi. Sudah umum di antara perusahaan untuk memiliki jendela pemeliharaan untuk patching, rilis besar, atau downtime untuk peningkatan perangkat keras atau peningkatan besar. Migrasi offline dapat menggunakan jendela ini untuk menyalin data dan mengalihkan lalu lintas aplikasi dari Apache Cassandra ke Amazon Keyspaces.
Migrasi offline mengurangi modifikasi pada aplikasi karena tidak memerlukan komunikasi ke Cassandra dan Amazon Keyspaces secara bersamaan. Selain itu, dengan aliran data dijeda, status yang tepat dapat disalin tanpa mempertahankan mutasi.
Dalam contoh ini, kami menggunakan Amazon Simple Storage Service (Amazon S3) sebagai area pementasan data selama migrasi offline untuk meminimalkan waktu henti. Anda dapat secara otomatis mengimpor data yang Anda simpan dalam format Parket di Amazon S3 ke dalam tabel Amazon Keyspaces menggunakan konektor Spark Cassandra dan. AWS Glue Bagian berikut akan menunjukkan ikhtisar tingkat tinggi dari proses tersebut. Anda dapat menemukan contoh kode untuk proses ini di [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
Proses migrasi offline dari Apache Cassandra ke Amazon Keyspaces menggunakan Amazon S3 dan memerlukan pekerjaan berikut. AWS Glue AWS Glue
1. Pekerjaan ETL yang mengekstrak dan mengubah data CQL dan menyimpannya di bucket Amazon S3.
1. Pekerjaan kedua yang mengimpor data dari bucket ke Amazon Keyspaces.
1. Pekerjaan ketiga untuk mengimpor data tambahan.
**Cara melakukan migrasi offline ke Amazon Keyspaces dari Cassandra yang berjalan di Amazon EC2 di Amazon Virtual Private Cloud**
1. Pertama Anda gunakan AWS Glue untuk mengekspor data tabel dari Cassandra dalam format Parket dan menyimpannya ke ember Amazon S3. Anda perlu menjalankan AWS Glue pekerjaan menggunakan AWS Glue konektor ke VPC tempat EC2 instans Amazon yang menjalankan Cassandra berada. Kemudian, menggunakan titik akhir pribadi Amazon S3, Anda dapat menyimpan data ke bucket Amazon S3.
Diagram berikut menggambarkan langkah-langkah ini.
![\[Memigrasi data Apache Cassandra dari Amazon yang berjalan EC2 di VPC ke bucket Amazon S3 menggunakan. AWS Glue\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Kocokkan data di bucket Amazon S3 untuk meningkatkan pengacakan data. Data yang diimpor secara merata memungkinkan lalu lintas yang lebih terdistribusi di tabel target.
Langkah ini diperlukan saat mengekspor data dari Cassandra dengan partisi besar (partisi dengan lebih dari 1000 baris) untuk menghindari pola tombol pintas saat memasukkan data ke Amazon Keyspaces. Masalah kunci panas terjadi `WriteThrottleEvents` di Amazon Keyspaces dan mengakibatkan peningkatan waktu muat.
![\[AWS GluePekerjaan mengacak data dari bucket Amazon S3 dan mengembalikannya ke bucket Amazon S3 lainnya.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Gunakan AWS Glue pekerjaan lain untuk mengimpor data dari bucket Amazon S3 ke Amazon Keyspaces. Data yang diacak di bucket Amazon S3 disimpan dalam format Parket.
![\[Pekerjaan AWS Glue impor mengambil data acak dari bucket Amazon S3 dan memindahkannya ke tabel Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/migration-import.png)
Untuk informasi selengkapnya tentang proses migrasi offline, lihat lokakarya [Amazon Keyspaces with AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# Menggunakan solusi migrasi hibrida: Apache Cassandra ke Amazon Keyspaces
Solusi migrasi berikut dapat dianggap sebagai hibrida antara migrasi online dan offline. Dengan pendekatan hybrid ini, data ditulis ke database tujuan dalam waktu dekat tanpa memberikan konsistensi baca demi tulis. Ini berarti bahwa data yang baru ditulis tidak akan segera tersedia dan penundaan diharapkan terjadi. Jika Anda perlu membaca setelah menulis konsistensi, lihat[Migrasi online ke Amazon Keyspaces: strategi dan praktik terbaik](migrating-online.md).
Untuk migrasi waktu nyata dari Apache Cassandra ke Amazon Keyspaces, Anda dapat memilih di antara dua metode yang tersedia.
+ **CQLReplicator**— (Disarankan) CQLReplicator adalah utilitas open source yang tersedia di [Github](https://github.com/aws-samples/cql-replicator) yang membantu Anda memigrasikan data dari Apache Cassandra ke Amazon Keyspaces dalam waktu dekat.
Untuk menentukan penulisan dan pembaruan untuk disebarkan ke database tujuan, CQLReplicator memindai rentang token Apache Cassandra dan menggunakan AWS Glue pekerjaan untuk menghapus peristiwa duplikat dan menerapkan penulisan dan pembaruan langsung ke Amazon Keyspaces.
+ **Ubah pengambilan data (CDC)** - Jika Anda terbiasa dengan Cassandra CDC, fitur CDC bawaan Apache Cassandra yang memungkinkan pengambilan perubahan dengan menyalin log komit ke direktori CDC terpisah adalah opsi lain untuk menerapkan migrasi hibrida.
Anda dapat melakukannya dengan mereplikasi perubahan data ke Amazon Keyspaces, menjadikan CDC sebagai opsi alternatif untuk skenario migrasi data.
Jika Anda tidak memerlukan konsistensi baca setelah menulis, Anda dapat menggunakan pipeline CQLReplicator atau CDC untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces berdasarkan preferensi dan keakraban Anda dengan alat dan digunakan di setiap solusi. Layanan AWS Menggunakan metode ini untuk memigrasikan data dalam waktu dekat dapat dianggap sebagai pendekatan hibrida untuk migrasi yang menawarkan alternatif untuk migrasi online.
Strategi ini dianggap sebagai pendekatan hibrida, karena selain opsi yang diuraikan dalam topik ini, Anda harus menerapkan beberapa langkah kemajuan migrasi online, misalnya salinan data historis dan strategi migrasi aplikasi yang dibahas dalam topik [migrasi online](migrating-online.md).
Bagian berikut membahas opsi migrasi hibrida secara lebih rinci.
**Topics**
+ [Migrasi data menggunakan CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migrasi data menggunakan change data capture (CDC)](migration-hybrid-cdc.md)
# Migrasi data menggunakan CQLReplicator
Dengan [CQLReplicator](https://github.com/aws-samples/cql-replicator), Anda dapat membaca data dari Apache Cassandra dalam waktu dekat dengan memindai cincin token Cassandra secara cerdas menggunakan kueri CQL. CQLReplicator tidak menggunakan Cassandra CDC dan sebagai gantinya menerapkan strategi caching untuk mengurangi penalti kinerja pemindaian penuh.
Untuk mengurangi jumlah penulisan ke tujuan, CQLReplicator secara otomatis menghapus duplikat peristiwa replikasi. Dengan CQLReplicator, Anda dapat menyetel replikasi perubahan dari database sumber ke database tujuan, memungkinkan migrasi data secara real time dari Apache Cassandra ke Amazon Keyspaces.
Diagram berikut menunjukkan arsitektur khas CQLReplicator pekerjaan menggunakanAWS Glue.
1. **Untuk memungkinkan akses ke Apache Cassandra berjalan di VPC pribadi, konfigurasikan AWS Glue koneksi dengan jenis koneksi Jaringan.**
1. Untuk menghapus duplikat dan mengaktifkan caching kunci dengan CQLReplicator pekerjaan, konfigurasikan Amazon Simple Storage Service (Amazon S3).
1. Database sumber terverifikasi streaming CQLReplicator pekerjaan berubah langsung ke Amazon Keyspaces.
![\[Menggunakan CQLReplicator untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Untuk informasi selengkapnya tentang proses migrasi yang digunakan CQLReplicator, lihat postingan berikut di blog AWS Database [Migrasikan beban kerja Cassandra ke Amazon Keyspaces CQLReplicator menggunakan dan panduan preskriptif [Memigrasikan beban kerja Apache](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) Cassandra AWS ke Amazon Keyspaces](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) menggunakan. AWS Glue
# Migrasi data menggunakan change data capture (CDC)
Jika sudah terbiasa mengonfigurasi pipeline change data capture (CDC) dengan [Debezium](https://debezium.io/), Anda dapat menggunakan opsi ini untuk memigrasikan data ke Amazon Keyspaces sebagai alternatif penggunaan. CQLReplicator Debezium adalah platform terdistribusi open-source untuk CDC, yang dirancang untuk memantau database dan menangkap perubahan tingkat baris dengan andal.
[Konektor Debezium untuk Apache Cassandra mengunggah](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) perubahan ke Amazon Managed Streaming for Apache Kafka (Amazon MSK) sehingga dapat dikonsumsi dan diproses oleh konsumen hilir yang pada gilirannya menulis data ke Amazon Keyspaces. Untuk informasi selengkapnya, lihat [Panduan migrasi data berkelanjutan dari Apache Cassandra ke Amazon](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/) Keyspaces.
Untuk mengatasi masalah konsistensi data potensial, Anda dapat menerapkan proses dengan Amazon MSK di mana konsumen membandingkan kunci atau partisi di Cassandra dengan yang ada di Amazon Keyspaces.
Untuk mengimplementasikan solusi ini dengan sukses, kami sarankan untuk mempertimbangkan hal berikut.
+ Cara mengurai log komit CDC, misalnya cara menghapus peristiwa duplikat.
+ Cara memelihara direktori CDC, misalnya cara menghapus log lama.
+ Cara menangani kegagalan sebagian di Apache Cassandra, misalnya jika penulisan hanya berhasil dalam satu dari tiga replika.
+ Cara menangani alokasi sumber daya, misalnya meningkatkan ukuran instance untuk memperhitungkan persyaratan CPU, memori, DISK, dan IO tambahan untuk proses CDC yang terjadi pada node.
Pola ini memperlakukan perubahan dari Cassandra sebagai “petunjuk” bahwa kunci mungkin telah berubah dari keadaan sebelumnya. Untuk menentukan apakah ada perubahan untuk disebarkan ke database tujuan, Anda harus terlebih dahulu membaca dari cluster Cassandra sumber menggunakan `LOCAL_QUORUM` operasi untuk menerima catatan terbaru dan kemudian menuliskannya ke Amazon Keyspaces.
Dalam kasus penghapusan rentang atau pembaruan rentang, Anda mungkin perlu melakukan perbandingan terhadap seluruh partisi untuk menentukan peristiwa penulisan atau pembaruan mana yang perlu ditulis ke database tujuan Anda.
Dalam kasus di mana penulisan tidak idempoten, Anda juga perlu membandingkan tulisan Anda dengan apa yang sudah ada di database tujuan sebelum menulis ke Amazon Keyspaces.
Diagram berikut menunjukkan arsitektur khas pipa CDC menggunakan Debezium dan Amazon MSK.
![\[Menggunakan pipeline pengambilan data perubahan untuk memigrasikan data dari Apache Cassandra ke Amazon Keyspaces.\]](http://docs.aws.amazon.com/id_id/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)