View a markdown version of this page

Putar kembali ke versi KCL sebelumnya - Amazon DynamoDB

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Putar kembali ke versi KCL sebelumnya

Topik ini menjelaskan cara mengembalikan aplikasi konsumen KCL 3.5.x+ Anda ke KCL 1.x. Proses rollback tergantung pada fase migrasi yang sedang dijalani aplikasi Anda saat ini.

Putar kembali dari Fase 1 ke KCL 1.x

Jika aplikasi Anda berada di Tahap 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), Anda dapat memutar kembali ke KCL 1.x dengan menerapkan ulang kode sebelumnya. Fase 1 kompatibel ke belakang dengan KCL 1.x dan tidak membuat entri khusus migrasi apa pun di tabel sewa. Tidak diperlukan alat migrasi. Untuk memutar kembali dari Tahap 1, gunakan kembali kode dengan versi KCL 1.x Anda ke semua pekerja.

penting

Fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) adalah perubahan besar untuk rollback. Setelah aplikasi Anda memasuki Tahap 2, entri non-sewa (WORKER_METRIC_STATSdanMigration3.0) ditulis ke tabel sewa yang tidak kompatibel ke belakang dengan KCL 1.x. Ini secara permanen mencegah rollback langsung ke KCL 1.x. Kami sangat menyarankan untuk memanggang aplikasi Anda di Fase 1 untuk jangka waktu yang lama untuk memvalidasi stabilitas sebelum melanjutkan ke Fase 2.

Kembalikan dari Fase 2 ke Fase 1

Jika aplikasi Anda berada di Tahap 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X), Anda harus menggunakan Alat Migrasi KCL di GitHub situs web untuk memutar kembali ke Tahap 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Ini adalah proses dua langkah:

  1. Jalankan Alat Migrasi KCL di GitHub situs web.

  2. Gunakan kembali kode dengan konfigurasi Tahap 1 (opsional).

penting

Anda tidak dapat memutar kembali dua level (dari Fase 2 ke Fase 1 dan kemudian ke KCL 1.x). Alat Migrasi KCL hanya menangani rollback Tahap 2 ke Fase 1. Alat ini tidak menghapus entri non-sewa dari tabel sewa. Entri ini tidak kompatibel ke belakang dengan KCL 1.x, itulah sebabnya rollback dua tingkat dari Fase 2 langsung ke KCL 1.x tidak dimungkinkan.

Langkah 1: Jalankan Alat Migrasi KCL

Saat Anda perlu memutar kembali dari Phase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) ke Phase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1), jalankan Alat Migrasi KCL. Alat ini melakukan tugas-tugas berikut:

  • Ini menghapus Indeks Sekunder Global (LeaseOwnerToLeaseKeyIndex) pada tabel sewa di DynamoDB. Indeks ini dibuat oleh KCL 3.5.x+ tetapi tidak diperlukan saat Anda memutar kembali ke Tahap 1.

  • Itu membuat semua pekerja berjalan dalam mode yang kompatibel dengan KCL 1.x dan mulai menggunakan algoritma penyeimbangan beban yang digunakan dalam versi KCL sebelumnya. Jika Anda memiliki masalah dengan algoritma penyeimbangan beban baru di KCL 3.5.x+, ini segera mengurangi masalah.

penting

Entri status koordinator (Migration3.0) dalam tabel sewa tidak boleh dihapus selama proses migrasi, rollback, dan rollforward.

catatan

Semua pekerja dalam aplikasi konsumen Anda harus menggunakan algoritma penyeimbangan beban yang sama pada waktu tertentu. Alat Migrasi KCL memastikan bahwa semua pekerja di aplikasi konsumen KCL 3.5.x+ Anda beralih ke mode yang kompatibel dengan KCL 1.x sehingga semua pekerja menjalankan algoritma penyeimbangan beban yang sama selama penerapan bergulir kembali ke Fase 1.

Anda dapat mengunduh Alat Migrasi KCL di direktori skrip repositori KCL GitHub. Jalankan skrip dari salah satu pekerja Anda atau host mana pun yang memiliki izin yang diperlukan untuk menulis dan memperbarui tabel sewa. Pastikan izin IAM yang sesuai dikonfigurasi untuk aplikasi konsumen KCL. Anda harus menjalankan skrip hanya sekali per aplikasi KCL. Jalankan Alat Migrasi KCL dengan perintah berikut:

python3 ./KclMigrationTool.py --region region --mode rollback [--application_name applicationName] [--lease_table_name leaseTableName]

Parameter

--region

Ganti region dengan Anda Wilayah AWS.

--application_name

Parameter ini diperlukan jika Anda menggunakan nama default untuk tabel sewa Anda. Jika Anda telah menentukan nama khusus untuk tabel sewa, Anda dapat menghilangkan parameter ini. Ganti applicationName dengan nama aplikasi KCL Anda yang sebenarnya. Alat ini menggunakan nama ini untuk mendapatkan nama tabel default jika nama kustom tidak disediakan.

--lease_table_name

Parameter ini diperlukan ketika Anda telah menetapkan nama khusus untuk tabel sewa dalam konfigurasi KCL Anda. Jika Anda menggunakan nama tabel default, Anda dapat menghilangkan parameter ini. Ganti leaseTableName dengan nama tabel khusus yang Anda tentukan untuk tabel sewa Anda.

Langkah 2: Gunakan kembali kode dengan konfigurasi Tahap 1 (opsional)

Setelah menjalankan Alat Migrasi KCL untuk rollback dari Fase 2 ke Fase 1, Anda akan melihat salah satu pesan berikut:

Pesan 1

“Rollback selesai. Aplikasi Anda menjalankan fungsionalitas Tahap 2 (2x kompatibel). Silakan kembalikan ke Tahap 1 dengan menerapkan aplikasi KCL 3.5.x Anda dengan konfigurasi Tahap 1.

Tindakan yang diperlukan: Pekerja Anda berjalan dalam mode yang kompatibel dengan KCL 1.x (Fase 2 belum dialihkan secara otomatis ke penyeimbangan beban 3.x penuh). Gunakan kembali aplikasi KCL 3.5.x+ Anda dengan konfigurasi Tahap 1 () CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1 ke pekerja Anda.

Pesan 2

“Rollback selesai. Aplikasi KCL Anda menjalankan fungsionalitas Tahap 2 (3x) dan telah diputar kembali ke mode Tahap 2 (kompatibel 2x). Jika Anda tidak melihat mitigasi setelah periode waktu yang singkat, silakan kembalikan ke Tahap 1 dengan menerapkan aplikasi KCL 3.5.x Anda dengan konfigurasi Tahap 1.

Tindakan yang diperlukan: Pekerja Anda telah beralih secara otomatis ke penyeimbangan beban KCL 3.x penuh dan Alat Migrasi KCL mengalihkannya kembali ke mode yang kompatibel dengan KCL 1.x. Jika masalah teratasi, Anda tidak perlu menyebarkan ulang. Jika masalah berlanjut, gunakan kembali aplikasi KCL 3.5.x+ Anda dengan konfigurasi Tahap 1 () CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1 ke pekerja Anda.