Wawancara Rekayasa Data: Upgrade Gates untuk Migrasi ZooKeeper-ke-KRaft pada Kafka 4.2

Petunjuk dan konteks

Sebuah klaster Kafka multi-tenant masih menjalankan ZooKeeper. Tim ingin bermigrasi ke KRaft dan melakukan upgrade ke Kafka 4.2. Klaster ini menggunakan transactional producer, Kafka Streams, dan Connect, serta tidak dapat mentoleransi kehilangan pesan, duplicate commit, atau pemadaman (outage) yang lama. Rancang preflight check, rolling upgrade, metadata-version gate, kompatibilitas klien, pemulihan kegagalan, dan rollback.

Hal yang diuji oleh pewawancara

• Mengenali bahwa Kafka 4.2 bersifat KRaft-only daripada memperlakukannya sebagai penggantian broker biasa.
• Memisahkan versi perangkat lunak, metadata.version, dan status migrasi.
• Memilih 4.2.1 setelah memperhitungkan perbaikan migrasi offline Streams dan perbaikan upgrade transactional producer pada 4.2.0.
• Mencakup controller, broker, klien, Connect, dan Streams dalam verifikasi.
• Mengetahui kapan rollback didukung dan kapan perubahan metadata memerlukan forward recovery.

Pertanyaan untuk klarifikasi

1. Berapa versi Kafka, ZooKeeper, klien, dan Streams, dan apakah semuanya memenuhi prasyarat migrasi KRaft?
2. Bagaimana idempotensi transaksional, transaction timeout, dan open transaction dipantau?
3. Apakah ada replikasi lintas wilayah (cross-region), MirrorMaker, atau klaster pemulihan yang telah diverifikasi?
4. Apakah beban kerja menggunakan Streams Rebalance Protocol, Share Groups, atau fitur 4.2 lainnya?
5. Berapa rolling window, consumer rebalance, dan waktu rollback yang dapat diterima oleh bisnis?

Jawaban 30 detik

Saya akan memperlakukan 4.2 sebagai migrasi arsitektur: klaster ZooKeeper harus bermigrasi ke KRaft sebelum dapat ditingkatkan. Saya akan menargetkan 4.2.1 untuk menghindari cacat migrasi offline Streams pada 4.2.0 dan masalah rolling upgrade pada transactional producer. Sebelum migrasi, bekukan perubahan berisiko tinggi dan inventarisasi klien, transaksi, status Streams, serta replika pemulihan. Lakukan rolling upgrade perangkat lunak terlebih dahulu, amati perilaku dan performanya, lalu naikkan metadata.version secara terpisah. Setiap langkah memeriksa pesan end-to-end, transaction commit, consumer lag, kuorum controller, dan status Streams. Jika ada langkah yang gagal, hentikan sebelum aktivasi metadata atau lakukan pemulihan melalui jalur kompatibel yang didukung daripada memperlakukan perubahan metadata sebagai sakelar yang dapat dibalikkan begitu saja.

Pembahasan mendalam langkah demi langkah

1. Buat matriks versi dan status

Kafka 4.2 hanya mendukung KRaft, sehingga mode ZooKeeper harus dimigrasikan terlebih dahulu. Versi perangkat lunak, versi metadata, dan status kuorum controller adalah dimensi yang independen. Konfirmasikan prasyarat dan catat versi broker, controller, klien, Connect, Streams, serta protokol dalam checklist yang dapat diaudit.

ZooKeeper -> KRaft migration -> rolling broker/controller upgrade -> verify -> raise metadata.version
    |             |                      |                         |
    +-- blocked --+----------------------+----------> stop and recover

2. Pilih versi perbaikan dan urutannya

Gunakan 4.2.1 sebagai target. Panduan upgrade resmi mencantumkan perbaikan untuk rolling upgrade transactional producer yang dapat menghasilkan UnsupportedVersionException dan perbaikan untuk cacat migrasi offline Streams Rebalance Protocol; 4.2.0 tidak boleh menjalankan migrasi dari classic ke streams group yang terdampak. Tingkatkan perkakas (tooling) dan matriks klien terlebih dahulu, lalu lakukan rolling satu broker pada satu waktu untuk menghindari perubahan beberapa domain kegagalan secara bersamaan.

3. Terapkan gate pada metadata dan perubahan controller

Setelah rolling upgrade perangkat lunak selesai, amati perilaku dan performa klaster sebelum menaikkan metadata.version dengan kafka-features.sh. Gate mencakup stabilitas kuorum controller, pemilihan leader, latensi propagasi metadata, ISR, dan kesehatan disk. Kafka 4.2 mendokumentasikan dukungan downgrade ketika tidak ada perubahan metadata, tetapi setiap versi target memerlukan pemeriksaan kompatibilitas metadatanya sendiri.

4. Verifikasi transaksi, Streams, dan Connect

Uji transaksi mencakup producer epoch, commit, abort, restart, duplikat, dan timeout. Uji Streams mencakup restorasi state-store, rebalance, changelog, pemrosesan semantik, dan jalur migrasi offline. Uji Connect mencakup offset, restart task, dan idempotensi sistem eksternal. Jalankan pemeriksaan produce/consume end-to-end untuk setiap kelas klien; kesehatan broker saja tidak cukup.

5. Amati dan simulasikan kegagalan

Catat pemilihan controller, versi metadata, error pada broker, kegagalan request, status transaksi, consumer lag, restorasi Streams, task Connect, dan pertumbuhan disk. Simulasikan broker restart, kehilangan controller, transaksi yang terinterupsi, kegagalan migrasi Streams, dan klien yang tidak kompatibel; setiap skenario membutuhkan kondisi stop-upgrade dan kondisi pemulihan.

6. Tentukan batas rollback dan pemulihan

Sebelum menaikkan metadata.version, simpan biner lama, konfigurasi, snapshot, dan klaster pemulihan, serta tentukan periode verifikasi read-only. Kegagalan saat rolling upgrade dapat dihentikan pada versi yang kompatibel dan memulihkan broker. Begitu perubahan metadata yang tidak didukung terjadi, rollback berubah menjadi restorasi snapshot yang kompatibel atau membangun klaster baru; jangan memaksakan downgrade biner. Pertahankan konsistensi transaksi dan offset sebelum memulihkan throughput.

Jawaban model

Pertama, saya akan membuktikan bahwa ini bukan upgrade versi rutin: Kafka 4.2 menghapus dukungan ZooKeeper, sehingga klaster yang ada harus bermigrasi ke KRaft. Saya akan memilih 4.2.1 karena panduan resmi menyebutkan perbaikan untuk rolling upgrade transactional producer dan migrasi offline Streams. Sebelumnya, inventarisasi broker, controller, klien, Connect, Streams, transaksi, dan replika pemulihan dalam matriks versi/status.

Lakukan rolling satu broker pada satu waktu, verifikasi kuorum controller, ISR, latensi, dan perilaku, lalu naikkan metadata.version. Uji transaksi mencakup epoch, commit, abort, restart, dan duplikat; uji Streams mencakup state store, changelog, rebalance, dan migrasi; uji Connect mencakup offset dan pemulihan task. Catat versi metadata, pemilihan leader, lag, dan error. Kegagalan sebelum aktivasi metadata dapat dihentikan pada tahap yang kompatibel; setelah perubahan metadata yang tidak didukung terjadi, bangun ulang dari snapshot atau klaster pemulihan daripada memaksakan downgrade biner.

Kesalahan umum

• Mengganti broker ZooKeeper secara langsung dengan Kafka 4.2 tanpa migrasi KRaft.
• Hanya memeriksa keaktifan broker alih-alih transaksi, status Streams, offset Connect, dan pesan end-to-end.
• Menaikkan metadata.version segera setelah rolling upgrade perangkat lunak.
• Menjalankan migrasi offline Streams yang berisiko pada 4.2.0.
• Memperlakukan metadata.version seperti pengaturan biasa yang selalu dapat di-downgrade.
• Tidak memiliki klaster pemulihan, snapshot, atau gate penghentian upgrade yang eksplisit.

Pertanyaan lanjutan dan tanggapan

Mengapa klaster ZooKeeper tidak dapat langsung di-upgrade ke Kafka 4.2?

Kafka 4.2 bersifat KRaft-only dan telah menghapus mode ZooKeeper. Klaster harus bermigrasi dan memverifikasi kuorum controller sebelum memasuki jalur rolling upgrade ke 4.2.

Kapan metadata.version harus dinaikkan?

Setelah semua perangkat lunak broker/controller ditingkatkan dan stabil, serta kuorum, ISR, error klien, dan performa telah lolos pengujian. Menaikkannya secara terpisah membedakan masalah kode dari aktivasi protokol.

Bagaimana jika restorasi status Streams gagal setelah aktivasi metadata?

Hentikan aktivasi fitur lebih lanjut, simpan bukti dan log, serta pulihkan dari snapshot yang didukung atau jalur pembangunan ulang. Jangan menyembunyikan inkonsistensi dengan menghapus changelog atau memaksakan downgrade biner.