View a markdown version of this page

Kembalikan ke versi KCL sebelumnya - Amazon Kinesis Data Streams
Kembalikan dari Tahap 1 ke versi KCL sebelumnyaKembalikan dari Fase 2 ke Fase 1Langkah 1: Jalankan Alat Migrasi KCLLangkah 2: Gunakan kembali kode dengan konfigurasi Tahap 1 (opsional)

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

Kembalikan ke versi KCL sebelumnya

Topik ini menjelaskan langkah-langkah untuk mengembalikan konsumen KCL 3.5.x Anda ke versi sebelumnya. Proses rollback tergantung pada fase migrasi yang sedang dijalani aplikasi Anda saat ini.

penting

Alat Migrasi KCL hanya diperlukan saat memutar kembali dari Fase 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) ke Fase 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1). Jika aplikasi Anda masih dalam Tahap 1, Anda dapat memutar kembali ke versi KCL sebelumnya dengan menerapkan ulang kode sebelumnya tanpa menjalankan alat.

Kembalikan dari Tahap 1 ke versi KCL sebelumnya

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

Untuk memutar kembali dari Tahap 1:

  1. Gunakan kembali kode dengan versi KCL sebelumnya ke semua pekerja.

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 untuk memutar kembali ke Tahap 1. Ini adalah proses dua langkah:

  1. Jalankan Alat Migrasi KCL.

  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 versi KCL sebelumnya). Alat Migrasi KCL hanya menangani rollback Tahap 2 ke Fase 1.

catatan

Alat Migrasi KCL tidak menghapus entri non-sewa dari tabel sewa. Entri ini tidak kompatibel ke belakang dengan versi KCL sebelumnya, itulah sebabnya rollback dua tingkat dari Fase 2 langsung ke versi KCL sebelumnya 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, 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 2.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 2.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. Anda dapat merujuk ke Izin IAM diperlukan untuk aplikasi konsumen KCL untuk izin IAM yang diperlukan untuk menjalankan skrip. 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 milik 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 (opsional): 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 Tahap 2 (kompatibel 2x). 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 berjalan dalam mode Tahap 2 (3x) dan Alat Migrasi KCL mengembalikan mereka ke mode Tahap 2 (kompatibel 2x). 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.