32.2. ZooKeeper 使用時の Kafka のダウングレード


ZooKeeper モードで Kafka を使用している場合、ダウングレードプロセスには、Kafka バージョンと、関連する log.message.format.version および inter.broker.protocol.version プロパティーの変更が含まれます。

32.2.1. ダウングレードでの Kafka バージョンの互換性

Kafka のダウングレードは、互換性のある現在およびターゲットの Kafka バージョン と、メッセージがログに記録された状態に依存します。

そのバージョンが、クラスターで これまで使用された inter.broker.protocol.version 設定をサポートしない場合、または新しい log.message.format.version を使用するメッセージログにメッセージが追加された場合は、下位バージョンの Kafka に戻すことはできません。

inter.broker.protocol.version は、__consumer_offsets に書き込まれたメッセージのスキーマなど、ブローカーによって保存される永続メタデータに使用されるスキーマを判断します。クラスターで以前使用された inter.broker.protocol.version が認識されない Kafka バージョンにダウングレードすると、ブローカーが認識できないデータが発生します。

ダウングレードする Kafka のバージョンの関係は次のとおりです。

  • ダウングレードする Kafka バージョンの log.message.format.version が現行バージョンと 同じ である場合、Cluster Operator は、ブローカーのローリング再起動を 1 回実行してダウングレードを行います。
  • log.message.format.version の場合、ダウングレード後のバージョンが使用するバージョンに設定された log.message.format.version に実行中のクラスターに存在する場合に限り、ダウングレードが可能です。通常は、アップグレードの手順が log.message.format.version の変更前に中止された場合にのみ該当します。その場合、ダウングレードには以下が必要です。

    • 2 つのバージョンで interbroker プロトコルが異なる場合、ブローカーのローリング再起動が 2 回必要です。
    • 両バージョンで同じ場合は、ローリング再起動が 1 回必要です。

以前のバージョンでサポートされない log.message.format.version が新バージョンで使われていた場合 (log.message.format.version のデフォルト値が使われていた場合など)、ダウングレードは実行 できません。たとえば、log.message.format.version が変更されていないため、このリソースは Kafka バージョン 3.8.0 にダウングレードできます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
spec:
  # ...
  kafka:
    version: 3.9.0
    config:
      inter.broker.protocol.version: "3.8"
      log.message.format.version: "3.8"
      # ...

log.message.format.version"3.9" に設定されている場合、または値が存在しない場合は、ダウングレードは不可能であり、パラメーターは 3.9.0 ブローカーのデフォルト値である 3.9 を取得します。

重要

Kafka 3.0.0 以降、inter.broker.protocol.version3.0 以上に設定されていると、log.message.format.version オプションは無視されるため、設定する必要はありません。

32.2.2. ZooKeeper ベースの Kafka クラスターとクライアントアプリケーションのダウングレード

ZooKeeper ベースの Kafka クラスターを以前のバージョンにダウングレードします。ZooKeeper ベースの Kafka クラスターを下位バージョンにダウングレードする場合 (3.9.0 から 3.8.0 に移行する場合など)、Kafka クラスターで使用されるブローカー間プロトコルバージョンが、ダウングレード先の Kafka バージョンでサポートされているバージョンであることを確認します。ダウングレード元の Kafka バージョンのブローカー間プロトコルバージョンは、ダウングレード先のバージョンより高くする必要があります。

注記

ZooKeeper ベースのダウングレードに関連するサポートと制限事項は、Apache Kafka のドキュメントを参照してください。

前提条件

  • Cluster Operator が稼働中である。
  • Kafka クラスターをダウングレードする前に、Kafka リソースについて次の点を確認してください。

    • 重要: Kafka バージョンの互換性
    • Kafka カスタムリソースには、ダウングレードされる Kafka バージョンでサポートされていないオプションは含まれません。
    • Kafka.spec.kafka.config に、ダウングレード先の Kafka バージョンでサポートされる log.message.format.versioninter.broker.protocol.version がある。

      Kafka 3.0.0 以降、inter.broker.protocol.version3.0 以上に設定されていると、log.message.format.version オプションは無視されるため、設定する必要はありません。

手順

  1. Kafka クラスター設定を更新します。

    oc edit kafka <kafka_configuration_file>
  2. inter.broker.protocol.version バージョン (および該当する場合は log.message.format.version) を、ダウングレードする Kafka バージョンでサポートされているバージョンに変更します。Kafka.spec.kafka.version現在 の Kafka バージョンのままにしておきます。

    たとえば、Kafka 3.9.0 から 3.8.0 にダウングレードする場合:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      # ...
      kafka:
        version: 3.9.0 
    1
    
        config:
          inter.broker.protocol.version: "3.8" 
    2
    
          log.message.format.version: "3.8"
          # ...
    1
    Kafka のバージョンは変更されていません。
    2
    ブローカー間プロトコルのバージョンが、以前の Kafka バージョンでサポートされているバージョンに変更されました。
    注記

    log.message.format.version および inter.broker.protocol.version の値は、浮動小数点数として解釈されないように文字列である必要があります。

  3. エディターを保存して終了し、ローリング更新の完了を待ちます。

    Pod の状態の遷移を監視して、ローリング更新の進捗を確認します。

    oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'

    ローリング更新により、各 Pod が指定された Kafka ブローカー間プロトコルバージョンを使用していることが保証されます。

  4. Kafka.spec.kafka.version を以前のバージョンに変更します。

    たとえば、Kafka 3.9.0 から 3.8.0 にダウングレードする場合:

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      # ...
      kafka:
        version: 3.8.0 
    1
    
        config:
          inter.broker.protocol.version: "3.8" 
    2
    
          log.message.format.version: "3.8"
          # ...
    1
    Kafka のバージョンが新しいバージョンに変更されます。
    2
    ブローカー間プロトコルのバージョンは、Kafka バージョンでサポートされています。
  5. Kafka バージョンのイメージが Cluster Operator の STRIMZI_KAFKA_IMAGES に定義されているイメージとは異なる場合は、Kafka.spec.kafka.image を更新します。

    「Kafka バージョンおよびイメージマッピング」を参照してください。

  6. Cluster Operator によってクラスターが更新されるまで待ちます。

    Kafka リソースのステータスからダウングレードが正常に完了したことを確認 できます。

  7. すべてのクライアントアプリケーション (コンシューマー) をダウングレードして、以前のバージョンのクライアントバイナリーを使用します。

    これで、Kafka クラスターおよびクライアントは以前の Kafka バージョンを使用するようになります。

  8. トピックメタデータの保存に ZooKeeper を使用する 1.7 よりも前のバージョンの Streams for Apache Kafka に戻す場合は、Kafka クラスターから内部トピックストアのトピックを削除します。

    oc run kafka-admin -ti --image=registry.redhat.io/amq-streams/kafka-39-rhel9:2.9.3 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る