Temu Duga Kejuruteraan Data: Pintu Peningkatan untuk Migrasi ZooKeeper-ke-KRaft Kafka 4.2

Gesaan dan konteks

Sebuah kluster Kafka berbilang penyewa (multi-tenant) masih menjalankan ZooKeeper. Pasukan ingin berhijrah kepada KRaft dan menaik taraf kepada Kafka 4.2. Kluster ini menggunakan pengeluar transaksi (transactional producers), Kafka Streams, dan Connect, serta tidak boleh bertolak ansur dengan kehilangan mesej, komit pendua, atau gangguan perkhidmatan yang lama. Reka bentuk semakan pra-pelaksanaan (preflight checks), peningkatan bergilir, pintu metadata-version, keserasian klien, pemulihan kegagalan, dan rollback.

Perkara yang diuji oleh penemu duga

• Menyedari bahawa Kafka 4.2 adalah khusus untuk KRaft (KRaft-only) dan bukannya menganggapnya sebagai penggantian broker biasa.
• Memisahkan versi perisian, metadata.version, dan status migrasi.
• Memilih 4.2.1 selepas mengambil kira pembaikan migrasi luar talian Streams dan peningkatan pengeluar transaksi pada 4.2.0.
• Merangkumi pengawal (controllers), broker, klien, Connect, dan Streams dalam pengesahan.
• Mengetahui bila rollback disokong dan bila perubahan metadata memerlukan pemulihan ke hadapan (forward recovery).

Soalan untuk penjelasan

1. Apakah versi Kafka, ZooKeeper, klien, dan Streams, dan adakah ia memenuhi prasyarat migrasi KRaft?
2. Bagaimanakah keidempoteman transaksi (transactional idempotence), tamat masa transaksi (transaction timeouts), dan transaksi terbuka dipantau?
3. Adakah terdapat replikasi rentas wilayah, MirrorMaker, atau kluster pemulihan yang telah disahkan?
4. Adakah beban kerja menggunakan Streams Rebalance Protocol, Share Groups, atau ciri 4.2 yang lain?
5. Apakah tetingkap peningkatan bergilir, pengimbangan semula pengguna (consumer rebalance), dan masa rollback yang boleh diterima oleh perniagaan?

Jawapan 30 saat

Saya akan menganggap 4.2 sebagai migrasi seni bina: kluster ZooKeeper mesti berhijrah kepada KRaft sebelum ia boleh dinaik taraf. Saya akan menyasarkan 4.2.1 untuk mengelakkan kecacatan migrasi luar talian Streams pada 4.2.0 dan isu peningkatan bergilir pengeluar transaksi. Sebelum migrasi, bekukan perubahan berisiko tinggi dan inventori klien, transaksi, status Streams, serta replika pemulihan. Lakukan peningkatan bergilir perisian terlebih dahulu, perhatikan tingkah laku dan prestasi, kemudian tingkatkan metadata.version secara berasingan. Setiap langkah menyemak mesej hujung-ke-hujung, komit transaksi, kelengahan pengguna (consumer lag), kuorum pengawal, dan status Streams. Jika sesuatu langkah gagal, berhenti sebelum pengaktifan metadata atau pulihkan melalui laluan serasi yang disokong dan bukannya menganggap perubahan metadata sebagai suis yang boleh diterbalikkan.

Perbincangan mendalam langkah demi langkah

1. Lakarkan matriks versi dan status

Kafka 4.2 hanya menyokong KRaft, jadi mod ZooKeeper mesti dimigrasikan terlebih dahulu. Versi perisian, versi metadata, dan status kuorum pengawal adalah dimensi yang bebas. Sahkan prasyarat dan rekodkan versi broker, pengawal, klien, Connect, Streams, dan protokol dalam senarai semak yang boleh diaudit.

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

2. Pilih versi tetap dan susunan

Gunakan 4.2.1 sebagai sasaran. Panduan peningkatan rasmi menyenaraikan pembaikan untuk peningkatan bergilir pengeluar transaksi yang boleh menghasilkan UnsupportedVersionException dan pembaikan untuk kecacatan migrasi luar talian Streams Rebalance Protocol; 4.2.0 tidak sepatutnya menjalankan migrasi classic ke streams group yang terjejas. Naik taraf perkakasan dan matriks klien terlebih dahulu, kemudian naik taraf satu broker pada satu masa untuk mengelakkan daripada mengubah beberapa domain kegagalan secara serentak.

3. Kawal perubahan metadata dan pengawal melalui pintu semakan

Selepas peningkatan bergilir perisian, perhatikan tingkah laku dan prestasi kluster sebelum meningkatkan metadata.version dengan kafka-features.sh. Pintu semakan merangkumi kestabilan kuorum pengawal, pemilihan ketua, latensi penyebaran metadata, ISR, dan kesihatan cakera. Kafka 4.2 mendokumentasikan sokongan penurunan taraf (downgrade) apabila tiada perubahan metadata, tetapi setiap versi sasaran memerlukan semakan keserasian metadatanya sendiri.

4. Sahkan transaksi, Streams, dan Connect

Ujian transaksi merangkumi epok pengeluar, komit, pengguguran (aborts), mula semula, pendua, dan tamat masa. Ujian Streams merangkumi pemulihan stor keadaan (state store), pengimbangan semula, log perubahan (changelogs), semantik pemprosesan, dan laluan migrasi luar talian. Ujian Connect merangkumi ofset, mula semula tugasan, dan keidempoteman sistem luaran. Jalankan semakan pengeluaran/penggunaan hujung-ke-hujung untuk setiap kelas klien; kesihatan broker sahaja tidak mencukupi.

5. Perhatikan dan lakukan latihan kegagalan

Rekodkan pemilihan pengawal, versi metadata, ralat broker, kegagalan permintaan, status transaksi, kelengahan pengguna, pemulihan Streams, tugasan Connect, dan pertumbuhan cakera. Lakukan latihan mula semula broker, kehilangan pengawal, transaksi yang terganggu, kegagalan migrasi Streams, dan klien yang tidak serasi; setiap senario memerlukan syarat henti peningkatan dan syarat pemulihan.

6. Tentukan sempadan rollback dan pemulihan

Sebelum meningkatkan metadata.version, simpan binari lama, konfigurasi, snapshot, dan kluster pemulihan, serta tentukan tetingkap pengesahan baca sahaja. Kegagalan peningkatan bergilir boleh dihentikan pada versi yang serasi dan memulihkan broker. Sebaik sahaja perubahan metadata yang tidak disokong berlaku, rollback bertukar menjadi pemulihan snapshot yang serasi atau membina semula kluster baharu; jangan paksa penurunan taraf binari. Kekalkan ketekalan transaksi dan ofset sebelum memulihkan daya pemprosesan (throughput).

Jawapan model

Pertama sekali, saya akan membuktikan bahawa ini bukan peningkatan versi yang rutin: Kafka 4.2 membuang sokongan ZooKeeper, jadi kluster sedia ada mesti berhijrah kepada KRaft. Saya akan memilih 4.2.1 kerana panduan rasmi menyatakan pembaikan untuk peningkatan bergilir pengeluar transaksi dan migrasi luar talian Streams. Terlebih dahulu, inventori broker, pengawal, klien, Connect, Streams, transaksi, dan replika pemulihan dalam matriks versi/status.

Lakukan peningkatan bergilir satu broker pada satu masa, sahkan kuorum pengawal, ISR, latensi, dan tingkah laku, kemudian tingkatkan metadata.version. Ujian transaksi merangkumi epok, komit, pengguguran, mula semula, dan pendua; ujian Streams merangkumi stor keadaan, log perubahan, pengimbangan semula, dan migrasi; ujian Connect merangkumi ofset dan pemulihan tugasan. Rekodkan versi metadata, pemilihan, kelengahan, dan ralat. Kegagalan pra-metadata boleh dihentikan pada peringkat yang serasi; selepas perubahan metadata yang tidak disokong, bina semula daripada snapshot atau kluster pemulihan dan bukannya memaksa penurunan taraf binari.

Kesilapan lazim

• Menggantikan broker ZooKeeper secara terus dengan Kafka 4.2 tanpa migrasi KRaft.
• Hanya menyemak keaktifan broker dan bukannya transaksi, status Streams, ofset Connect, dan mesej hujung-ke-hujung.
• Meningkatkan metadata.version serta-merta selepas peningkatan bergilir perisian.
• Menjalankan migrasi luar talian Streams yang berisiko pada 4.2.0.
• Menganggap metadata.version sebagai tetapan biasa yang sentiasa boleh diturunkan taraf.
• Tiada kluster pemulihan, snapshot, atau pintu henti peningkatan yang jelas.

Soalan susulan dan jawapan

Mengapakah kluster ZooKeeper tidak boleh dinaik taraf terus kepada Kafka 4.2?

Kafka 4.2 adalah khusus untuk KRaft sahaja dan telah membuang mod ZooKeeper. Kluster mesti berhijrah dan mengesahkan kuorum pengawal sebelum memasuki laluan peningkatan bergilir 4.2.

Bilakah metadata.version patut ditingkatkan?

Selepas semua perisian broker/pengawal dinaik taraf dan stabil, serta kuorum, ISR, ralat klien, dan prestasi lulus ujian. Meningkatkannya secara berasingan dapat membezakan masalah kod daripada pengaktifan protokol.

Bagaimana jika pemulihan status Streams gagal selepas pengaktifan metadata?

Hentikan pengaktifan ciri seterusnya, simpan bukti dan log, serta pulihkan daripada snapshot yang disokong atau laluan binaan semula. Jangan sembunyikan ketidakkonsistenan dengan memadam log perubahan atau memaksa penurunan taraf binari.