Confluent Platform のアップグレード

注釈

Confluent Platform のサブスクライバーであり、アップグレードに関するご質問やサポートが必要な場合は、サポートポータル からお問い合わせください。

重要

Confluent Platform パッケージにはデフォルトで Confluent Server が含まれており、server.properties ファイルに confluent.license キーが必要です。Confluent Platform 5.4.x 以降では、Confluent Server ブローカーは起動時にライセンスをチェックします。以下のように confluent.license プロパティを使用して、各ブローカーのプロパティファイルにライセンスの文字列を指定する必要があります。

confluent.license=LICENCE_STRING_HERE_NO_QUOTES

Kafka ブローカーを使用する場合は、confluent-community パッケージをダウンロードしてください。Kafka ブローカーは、すべての Debian、または RHEL および CentOS パッケージでデフォルトです。

準備

アップグレードの準備にあたっては、以下のガイドラインを考慮してください。

  • 5.3.1 より前のバージョンの Confluent Platform を実行している場合は、6.1.x 以降にアップグレードする前に 5.3.1 にアップグレードしてください。

  • すべてのコンポーネントが同じバージョンを実行するように、プラットフォームのデプロイ全体をアップグレードします。複数のコンポーネントバージョンを混在させないでください。

  • アップグレードする前に、必ずすべての構成ファイルをバックアップしてください。たとえば、/etc/kafka/etc/kafka-rest/etc/schema-registry などのファイルです。

  • アップグレードプロセスを開始する前に、ドキュメントを読んで、特定の要件および環境に適合したアップグレード計画を作成します。つまり、ライブ運用中のクラスターでこのガイドが示す作業を開始しないでください。ガイドを最後まで読み、計画を立ててから作業を実行してください。

  • コンポーネントのアップグレード順序を慎重に検討します。バージョン 0.10.2 以降では、Java クライアント(プロデューサーとコンシューマー)は以前のバージョンのブローカーと通信できます。 バージョン 0.10.2 のクライアントは、バージョン 0.10.0 以降のブローカーと通信できます。ただし、0.10.0 より前のブローカーの場合は、クライアントをアップグレードする前に、Apache Kafka® クラスター内のすべてのブローカーをアップグレードする必要があります。バージョン 0.10.2 のブローカーは、0.8.x 以降のクライアントをサポートします。0.10.2 より前のバージョンの場合、Kafka には後方互換性があります。つまり、Kafka 0.8.x リリース(Confluent Platform 1.0.x)のクライアントは、Kafka リリース 0.8.x から 2.8 (Confluent Platform 2.0.x から 6.2 .x)のブローカーと連携して動作しますが、その逆は動作しません。この場合は、必ずクライアントより先に "すべての" ブローカーがアップグレードされるようにアップグレードを計画する必要があります。クライアントには、Kafka プロデューサーまたはコンシューマー、コマンドラインツール、Camus、Schema Registry、REST Proxy、Kafka Connect、および Kafka Streams を使用するアプリケーションが含まれます。

    重要

    Kafka 0.9.0.0(Confluent Platform 2.0.0)で発生したバグにより、ZooKeeper に依存するクライアント(古いコンシューマーとともに使用される場合は古い Scala 高レベルコンシューマーと MirrorMaker)は 0.10.x.x 以降のブローカーでは動作しません。したがって、Kafka 0.9.0.0(Confluent Platform 2.0.0)クライアントは、ブローカーを 0.10.x.x 以降にアップグレードする "前に"、0.9.0.1(Confluent Platform 2.0.1)にアップグレードする必要があります。この手順は、0.8.x または 0.9.0.1 クライアントでは必要ありません。

    重要

    推奨されませんが、クライアントがブローカーと同じ場所(同じノード上)に配置されるようなデプロイ方法もあります。この場合、ブローカーとクライアントの両方が同じパッケージを共有します。クライアントをアップグレードする前に "すべての" ブローカーをアップグレードする必要があるため、この方法には問題があります。アップグレードする際は、この点に注意してください。

  • Starting in Confluent Platform 6.0, connectors are no longer packaged with Confluent Platform, and you need to manually install connectors. If you are running Connect and plan to upgrade from any version prior to version 6.0, refer to this important upgrade note.

  • Kafka 2.0.0 では、以前のメジャーバージョン(例: 0.8.x.x、0.9.x.x、0.10.x.x、0.11.x.x、および 1.0.x)との互換性に影響する可能性のある変更や非推奨事項が含まれています。Apache Kafka のドキュメント を参照して、Kafka を使用するアプリケーションへの影響を把握してください。

    重要

    Java 7 はサポートされなくなりました。Java 8 が最低限必要なバージョンになりました。互換性の詳細については、「サポートされているバージョンおよび相互運用性」を参照してください。

  • Confluent LDAP Authorizer を使用している場合、6.2.0 にアップグレードするときに商用の confluent-server パッケージに移行する必要があります。詳細については、「Confluent Server への移行」を参照してください。

  • ローリング再起動 中にブローカーのステータスをモニタリングするには、Confluent Control Center の使用を検討してください。

  • 適切な Java バージョンを決定し、インストールします。アップグレードする Confluent Platform のバージョンでサポートされているバージョンを確認するには、「サポートされている Java のバージョン」を参照してください。

  • クライアントがブローカーと同じ場所にあるかどうかを確認します。同じ場所にある場合は、"すべての" Kafka ブローカーがアップグレードされるまで、クライアントプロセスをアップグレードしないようにしてください。

  • ローリングアップグレードまたはダウンタイムアップグレードのいずれを実行するかを決定します。Confluent Platform では、ローリングアップグレード(クラスターのダウンタイムを回避するために一度に 1 つのブローカーをアップグレードする)とダウンタイムアップグレード(クラスター全体を停止してアップグレードしたあとに、すべてを起動し直す)の両方がサポートされています。

  • Confluent Platform 6.2.4 リリースノート」をお読みください。注目すべき機能や、アップグレードに影響を与える可能性のある構成の変更に関する重要な情報が含まれています。

アップグレード手順

推奨されるアップグレードの順序は以下のとおりです。

  1. Zookeeper をアップグレードします。

  2. すべての Kafka ブローカーをアップグレードします

  3. このトピックの後半の説明に従って、残りの Confluent Platform コンポーネントをアップグレードします。

    ほとんどの場合、Confluent Platform コンポーネントの中で Confluent Control Center を最後にアップグレードすることをお勧めします。ただし、6.0.1 または 6.0.2 から 6.1.0 以降にアップグレードする場合は、Confluent Control Center が不安定になるのを避けるために、まず Confluent Control Center をアップグレードしてから、Kafka ブローカーをアップグレードする必要があります。既に Kafka ブローカーをアップグレードしてしまって Confluent Control Center がクラッシュする場合でも、Confluent Control Center をアップグレードすれば、症状は自然に解消します。

  4. Camus をアップグレード します。

  5. 妥当な場合は、新しい 6.2.x ライブラリに対して Kafka プロデューサーおよびコンシューマーを使用するアプリケーションを構築し、新しいバージョンをデプロイします。6.2.x ライブラリの使用方法の詳細については、「アプリケーション開発」を参照してください。

ZooKeeper のアップグレード

ZooKeeper は、Confluent Platform 6.2 で 3.5.x にアップグレードされました。

アップグレードの準備として、以下のガイドラインを考慮してください。

  • アップグレードする前に、すべての構成ファイルをバックアップします。
  • リーダーから ZooKeeper データをバックアップします。障害が発生した場合は、コミットされた最新のステートに戻ります。
  • アップグレードプロセスを開始する前に、ドキュメントを読んで、特定の要件および環境に適合したアップグレード計画を作成します。

ZooKeeper のローリングアップグレード

ローリングアップグレードに必要な情報を収集するには、以下の手順を実行します。

  1. どのノードがリーダーかを特定するには、以下のコマンドを実行します。

    echo mntr | nc localhost 2181 | grep zk_server_state
    

    ZooKeeper アンサンブル全体にリーダーが 1 つしかないことを確認します。

  2. リーダーと同期しているノードの数を調べるには、以下のコマンドを実行します。

    echo mntr | nc localhost 2181 | grep zk_synced_followers
    
  3. すべてのフォロワーがリーダーと同期していることを確認します。以下のコマンドは、同じ結果を返すはずです。

    echo mntr | nc localhost 2181 | grep zk_synced_followers
    
    echo mntr | nc localhost 2181 | grep zk_followers
    

ZooKeeper サーバーごとに、以下の手順を繰り返します。リーダーの ZooKeeper サーバーは最後にアップグレードする必要があります。

  1. ZooKeeper プロセスを慎重に停止します。

  2. ZooKeeper バイナリをアップグレードします。

  3. ZooKeeper プロセスを開始します。

  4. すべてのフォロワーがリーダーと同期するまで待ちます。すべてのフォロワーがリーダーと同期している場合、以下のコマンドは同じ結果を返すはずです。

    echo mntr | nc localhost 2181 | grep zk_synced_followers
    
    echo mntr | nc localhost 2181 | grep zk_followers
    

アップグレード中に問題が発生した場合は、同じ手順でロールバックできます。

AdminServer

組み込みの Jetty ベースの AdminServer が ZooKeeper 3.5 に追加されました。

Confluent Platform の一部として配布される ZooKeeper では、AdminServer はデフォルトで無効になっています。AdminServer を有効にするには、ローカルの zookeeper.properties ファイルで admin.enableServer=true を設定します。

Apache Kafka® ディストリビューションによって提供される ZooKeeper では、AdminServer はデフォルト(ポート 8080)で有効になっています。AdminServer を構成するには、『AdminServer configuration』を参照してください。

ZooKeeper における 4 文字単語のホワイトリスト

ZooKeeper 3.5.3 以降では、4 文字単語のコマンドを有効にするには、ZooKeeper サーバーの zookeeper.4lw.commands.whitelist 設定で明示的にホワイトリスト化する必要があります。デフォルトでは zkServer.sh が使用する srvr コマンドのみがホワイトリストに含まれています。残りの 4 文字単語のコマンドはデフォルトで無効になっています。

statruokconf、および isro コマンドをホワイトリスト化し、残りの 4 文字単語のコマンドを無効にする例を以下に示します。

4lw.commands.whitelist=stat, ruok, conf, isro

4 文字単語のコマンドをすべてホワイトリスト化する例:

4lw.commands.whitelist=*

Docker コンテナーで ZooKeeper を実行する場合、docker run コマンドで Java システムプロパティ -e KAFKA_OPTS=-'Dzookeeper.4lw.commands.whitelist=' を使用します。以下に例を示します。

docker run -d \
 --net=host
 --name=zookeeper \
 -e ZOOKEEPER_CLIENT_PORT=32181 \
 -e ZOOKEEPER_TICK_TIME=2000 \
 -e ZOOKEEPER_SYNC_LIMIT=2 \
 -e KAFKA_OPTS='-Dzookeeper.4lw.commands.whitelist=*' \
 confluentinc/cp-zookeeper:6.2.4

詳細については、『 The Four Letter Words』を参照してください。

スナップショットファイルが見つからないアップグレードの問題

3.4.X から 3.5.X への ZooKeeper アップグレードは、3.4 データディレクトリにスナップショットファイルがない場合、以下のエラーにより失敗することがあります。

ERROR Unable to load database on disk
(org.apache.zookeeper.server.quorum.QuorumPeer) java.io.IOException: No
snapshot found, but there are log entries. Something is broken! at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:222)
at org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:240) at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:919)
at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:905) at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:205)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:123)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:82)

これは通常、スナップショットファイルが作成されていない既存の 3.4 データディレクトリを ZooKeeper 3.5.X がロードしようとするテストアップグレードで発生します。この問題の詳細については、『 ZOOKEEPER-3056』を参照してください。

推奨される回避策は以下のとおりです。

  1. 現在の ZooKeeper data ディレクトリのバックアップを作成します。
  2. ZooKeeper data ディレクトリでスナップショットファイル(snapshot で始まるファイル名)を探します。
    • スナップショットファイルがある場合は、安全にアップグレードできます。
    • スナップショットファイルがない場合は、空のスナップショットファイルをダウンロードし、data ディレクトリに配置します。空のスナップショットファイルは、https://issues.apache.org/jira/browse/ZOOKEEPER-3056 から添付ファイルとして入手できます。

回避策の詳細については、ZooKeeper の『Upgrade FAQ』を参照してください。

Kafka ブローカーのアップグレード

ローリングアップグレードのシナリオでは、エンドユーザーのダウンタイムを回避するための ローリング再起動 に関する推奨事項を考慮して、一度に 1 つの Kafka ブローカーをアップグレードします。

ダウンタイムアップグレードのシナリオでは、クラスター全体を停止し、各 Kafka ブローカーをアップグレードしてからクラスターを起動します。

修正パックリリースのアップグレード手順

いずれの修正パックリリースも、各ブローカーを一度に 1 つずつアップグレードするだけで、ローリングアップグレード(たとえば、3.1.1 から 3.1.2)を実行できます。

各ブローカーをアップグレードするには、以下のとおり実行します。

  1. ブローカーを停止します。
  2. ソフトウェアをアップグレードします(パッケージタイプについては、以下を参照してください)。
  3. ブローカーを起動します。

以前のバージョンを 6.2.x にアップグレードする手順

ローリングアップグレードシナリオでは、Confluent Platform 6.2.x(Kafka 2.8.x)にアップグレードするには特別な手順が必要です。これは、Kafka 2.8.x にはワイヤープロトコルとブローカー間プロトコルの変更が含まれているためです。

ローリングアップグレードの手順は、以下のとおりです。

  1. 現在インストールされているバージョンに一致するように、プロパティ inter.broker.protocol.version および log.message.format.version を変更して、すべての Kafka ブローカーの server.properties をアップデートします。

    • Confluent Platform 2.0.x の場合は、inter.broker.protocol.version=0.9.0log.message.format.version=0.9.0 を使用します。
    • Confluent Platform 3.0.x の場合は、inter.broker.protocol.version=0.10.0log.message.format.version=0.10.0 を使用します。
    • Confluent Platform 3.1.x の場合は、inter.broker.protocol.version=0.10.1log.message.format.version=0.10.1 を使用します。
    • Confluent Platform 3.2.x の場合は、inter.broker.protocol.version=0.10.2log.message.format.version=0.10.2 を使用します。
    • Confluent Platform 3.3.x の場合は、inter.broker.protocol.version=0.11.0log.message.format.version=0.11.0 を使用します。
    • Confluent Platform 4.0.x の場合は、inter.broker.protocol.version=1.0log.message.format.version=1.0 を使用します。
    • Confluent Platform 4.1.x の場合は、inter.broker.protocol.version=1.1log.message.format.version=1.1 を使用します。
    • Confluent Platform 5.0.x の場合は、inter.broker.protocol.version=2.0log.message.format.version=2.0 を使用します。
    • Confluent Platform 5.1.x の場合は、inter.broker.protocol.version=2.1log.message.format.version=2.1 を使用します。
    • Confluent Platform 5.2.x の場合は、inter.broker.protocol.version=2.2log.message.format.version=2.2 を使用します。
    • Confluent Platform 5.3.x の場合は、inter.broker.protocol.version=2.3log.message.format.version=2.3 を使用します。
    • Confluent Platform 5.4.x の場合は、inter.broker.protocol.version=2.4log.message.format.version=2.4 を使用します。
    • Confluent Platform 5.5.x の場合は、inter.broker.protocol.version=2.5log.message.format.version=2.5 を使用します。
    • Confluent Platform 6.0.x の場合は、inter.broker.protocol.version=2.6log.message.format.version=2.6 を使用します。
    • Confluent Platform 6.1.x の場合は、inter.broker.protocol.version=2.7log.message.format.version=2.7 を使用します。
    • Confluent Platform 6.2.x の場合は、inter.broker.protocol.version=2.8log.message.format.version=2.8 を使用します。

    Confluent Server を使用する場合は、有効な Confluent ライセンスキーを入力する必要があります。たとえば、confluent.license=123 のように指定します。

  2. 各 Kafka ブローカーを一度に 1 つずつアップグレードします。

  3. Kafka ブローカーがすべてアップグレードされた後、server.propertiesinter.broker.protocol.version=2.8 のようにアップデートを行います。

  4. 各 Kafka ブローカーを一度に 1 つずつ再起動して、構成変更を適用します。

  5. Confluent Platform 3.2.x 以前からアップグレードする場合は、以下の追加手順を実行します。

    メッセージフォーマットは Confluent Platform 3.3.x から 6.2.x まで同じであるため、Confluent Platform 3.3.x 以降のバージョンからアップグレードする場合は、この手順を省略できます。

    1. すべての(またはほとんどの)コンシューマーを 6.2.x にアップグレードしたら、各ブローカーで log.message.format.version=2.8 を設定します。
    2. 各 Kafka ブローカーを一度に 1 つずつ再起動します。

メンテナンスの対象外となった古い Scala クライアントは、0.11 で導入されたメッセージフォーマットをサポートしていません。したがって、変換コストを避ける(または、"厳密に 1 回" のセマンティクスを利用する)ために、新しい Java クライアントを使用する必要があります。

Confluent ライセンス

server.propertiesconfluent.license 構成パラメーターを追加します。Confluent Platform 5.4.x 以降では、起動するには confluent.license が必要です。詳細については、「confluent-server」を参照してください。

アドバタイズされるリスナー

5.x 以前のバージョンから 6.x 以降のバージョンにアップグレードする場合は、以下のプロパティを server.properties ファイルに含める必要があります。

セキュリティ

5.4.x 以降、新しいオーソライザークラス kafka.security.authorizer.AclAuthorizerkafka.security.auth.SimpleAclAuthorizer に代わって使用されます。server.properties ファイルで kafka.security.auth.SimpleAclAuthorizer の既存のインスタンスを kafka.security.authorizer.AclAuthorizer に手動で変更する必要があります。詳細については、「ACL のコンセプト」を参照してください。

Self-Balancing Clusters のレプリケーション係数

Self-Balancing 構成用に confluent.balancer.topic.replication.factor 設定が Confluent Platform 6.0.0 に追加されました。

confluent.balancer.topic.replication.factor の値がブローカーの総数より大きい場合、ブローカーは起動しません。

confluent.balancer.topic.replication.factor のデフォルト値は 3 です。

設定の詳細については、「confluent.balancer.topic.replication.factor」を参照してください。

APT を使用した DEB パッケージのアップグレード

  1. /etc/kafka/etc/kafka-rest/etc/schema-registry など、/etc のすべての構成ファイルをバックアップします。

  2. サービスを停止し、既存のパッケージとその依存関係を削除します。これは、ローリングアップグレード(「以前のバージョンを 6.2.x にアップグレードする手順」を参照)として一度に 1 台のサーバーで実行できます。

    # The example below removes the Kafka package
      sudo kafka-server-stop
      sudo apt-get remove confluent-kafka
    
    # To remove Confluent Platform 5.5 and all its dependencies at once, run the following after stopping all services
      sudo apt-get autoremove confluent-platform-2.12
    
  3. 古い GPG キーを削除して、アップデートされたキーをインポートします。アップデートされた 8b1da6120c2bf624 キーが既にインポート済みの場合は、この手順を省略できます。ただし、古い 670540c841468433 キーがまだインストールされている場合は、この時点で削除し、8b1da6120c2bf624 キーをインポートしてください。

    sudo apt-key del 41468433
    wget -qO - https://packages.confluent.io/deb/6.2/archive.key | sudo apt-key add -
    
  4. 前のバージョンのリポジトリファイルを削除します。

    sudo add-apt-repository -r "deb https://packages.confluent.io/deb/<currently installed version> stable main"
    
  5. 6.2 リポジトリを /etc/apt/sources.list に追加します。

    sudo add-apt-repository "deb https://packages.confluent.io/deb/6.2 stable main"
    
  6. リポジトリメタデータを更新します。

    sudo apt-get update
    
  7. 構成ファイルを変更した場合、競合を解決するよう apt からメッセージが表示されます。必ず元の構成を保持してください。新しいバージョンをインストールします。

      sudo apt-get install confluent-platform
    
    # Or install the packages you need one by one. For example, to install only Kafka:
      sudo apt-get install confluent-kafka
    

    ちなみに

    以下のコマンドで、使用可能なすべての Confluent Platform ビルドを表示できます。

    apt-cache show confluent-platform
    

    特定の Confluent Platform ビルドをインストールするには、install コマンドにバージョン(&lt;version&gt;)を追加します。

    sudo apt-get install confluent-platform-<version>
    
  8. Confluent Platform コンポーネントを起動します。

    kafka-server-start -daemon /etc/kafka/server.properties
    

YUM を使用した RPM パッケージのアップグレード

  1. /etc/kafka/etc/kafka-rest/etc/schema-registry など、/etc のすべての構成ファイルをバックアップします。

  2. サービスを停止し、既存のパッケージとその依存関係を削除します。これは、ローリングアップグレード(「以前のバージョンを 6.2.x にアップグレードする手順」を参照)として一度に 1 台のサーバーで実行できます。

    # The example below removes the Kafka package
      sudo kafka-server-stop
      sudo yum remove confluent-kafka
    
    # To remove Confluent-Platform 5.5 and all its dependencies at once, run the following after stopping all services
      sudo yum autoremove confluent-platform-2.12
    
  3. 前のバージョンのリポジトリファイルを削除します。

    sudo rm /etc/yum.repos.d/confluent.repo
    
  4. 古い GPG キーを削除します。Confluent の古い(670540c841468433)GPG キーをまだ削除していない場合、この手順はオプションです。Confluent の新しい(8b1da6120c2bf624)キーは、RPM データベースに gpg-pubkey-0c2bf624-60904208 として表示されます。

    sudo rpm -e gpg-pubkey-41468433-54d512a8
    sudo rpm --import https://packages.confluent.io/rpm/6.2/archive.key
    
  5. リポジトリを /etc/yum.repos.d/ ディレクトリの confluent-6.2.repo という名前のファイルに追加します。

    [confluent-6.2]
    name=Confluent repository for 6.2.x packages
    baseurl=https://packages.confluent.io/rpm/6.2
    gpgcheck=1
    gpgkey=https://packages.confluent.io/rpm/6.2/archive.key
    enabled=1
    
  6. リポジトリメタデータを更新します。

    sudo yum clean all
    
  7. 新しいバージョンをインストールします。yum は既存の構成ファイルをオーバーライドする可能性があるので、パッケージをインストールした後にバックアップから復元する必要があります。

      sudo yum install confluent-platform
    
    # Or install the packages you need one by one. For example, to install just Kafka:
      sudo yum install confluent-kafka
    
  8. サービスを起動します。

    kafka-server-start -daemon /etc/kafka/server.properties
    

TAR または ZIP アーカイブを使用したアップグレード

ZIP および TAR アーカイブの場合、新しいアーカイブフォルダーが作成され、以前の構成ファイルがコピーされたら、以下の手順に従って古いアーカイブディレクトリを削除できます。

  1. Confluent Platform をインストールしたディレクトリに戻ります。

  2. ./etc から、./etc/kafka./etc/kafka-rest./etc/schema-registry./etc/confluent-control-center などのすべての構成ファイルをバックアップします。

  3. サービスを停止し、既存のパッケージとその依存関係を削除します。これは、ローリングアップグレード(「以前のバージョンを 6.2.x にアップグレードする手順」を参照)として一度に 1 台のサーバーで実行できます。

      ./bin/control-center-stop
      ./bin/kafka-rest-stop
      ./bin/schema-registry-stop
      ./bin/kafka-server-stop
      ./bin/zookeeper-server-stop
    
    # To remove Confluent Platform and all its dependencies at once, run the following after stopping all services
      cd ..
      rm -R confluent-3.3.1 (use the installed version number)
    
  4. 新しいアーカイブを解凍します。YUM は既存の構成ファイルをオーバーライドする可能性があるので、パッケージをインストールした後にバックアップから復元する必要があります。

      tar xzf confluent-6.2.4.tar.gz
    
    # Or for ZIP archives:
    
      unzip confluent-6.2.4.zip
    
  5. サービスを起動します。

    sudo confluent-6.2.4/bin/zookeeper-server-start -daemon /etc/kafka/zookeeper.properties
    sudo confluent-6.2.4/bin/kafka-server-start -daemon /etc/kafka/server.properties
    

Schema Registry のアップグレード

"すべての" Kafka ブローカーをアップグレードした後で Schema Registry をアップグレードできます。

以下では、バージョン固有のアップグレードの考慮事項について説明します。

  • バージョン 6.0 への Kafka 選出を使用して Schema Registry クラスターをライブアップデートするには、まず以前のインスタンスが既にバージョン 5.0.1 以降にアップデートされていることを確認します。

    Confluent Platform 5.0.1 以降を実行するインスタンスは、ライブアップグレードの互換性を損なうことなく、アップグレードの一部として Kafka 選出プロトコルの拡張をサポートします。

  • Confluent Platform 4.1.1 以前のバージョンを実行しているマルチノード Schema Registry クラスターがある場合は、5.2.x へのローリングアップグレードを直接実行しないでください。これを行うと、Schema Registry のレガシーノードと新しいノードが混在する中間ステートにあるライブ運用中のクラスターが原因でエラーが発生する可能性があり、スキーマ ID を管理するために機能パリティが必要になります。代わりに、以下のいずれかの操作を行います。

    • ローリングアップグレードを使用する場合、まずバージョン 4.1.2 または 4.1.3 にアップグレードしてから、5.2.x 以降のバージョンへのローリングアップグレードを実行します。
    • 4.1.1 クラスター全体を停止し、すべての Schema Registry ノードを同時に 5.2.x 以降のバージョンにアップグレードします。
  • Confluent Platform 6.2.2 以降、Schema Registry は、RBAC が有効になっている Schema Registry と Control Center とのやり取りをサポートする、表示される Schema Registry クラスターをフィルター処理するための Confluent Control Center 用の新しいエンドポイントを提供しています。Control Center はこのエンドポイントを呼び出すようにアップグレードされます。したがって、Control Center は 6.2.2 より前の Schema Registry に存在しないエンドポイントを呼び出そうとするため、6.2.2 以降のバージョンの Control Center は、6.2.2 より前のバージョンの Schema Registry と互換性がありません。デプロイを Confluent Platform 6.2.1 以前からアップグレードする場合は、RBAC が有効になっている Schema Registry クラスターで Control Center が適切に動作するように Control Center と Schema Registry も 6.2.2 以降にアップグレードする必要があります。具体的には、Control Center を 6.2.2 より前のバージョンからアップグレードする場合は、Schema Registry もアップグレードする必要があります。詳細については、Confluent Platform コンポーネントの更新履歴 にあるバージョン 6.2.2 の Schema Registry の DGS-2570 と Control Center の DGS-2570 を参照してください。

Schema Registry にアップグレードするには、以下のとおり実行します。

  1. RBAC が有効な環境の場合のみ: Confluent ライセンストピックリソースの REST Proxy ユーザーの ResourceOwner を追加します(デフォルト名は _confluent-command です)。その例を次に示します。

    confluent iam rolebinding create \
    --role ResourceOwner \
    --principal User:<service-account-id> \
    --resource Topic:_confluent-command \
    --kafka-cluster-id <kafka-cluster-id>
    
  2. Schema Registry を停止します。

    schema-registry-stop
    
  3. 構成ファイルをバックアップします。その例を次に示します。

    cp SR.properties /back-up/SR.properties
    
  4. 古いバージョンを削除します。

    yum remove confluent-schema-registry-<old release number>
    

    その例を次に示します。

    yum remove confluent-schema-registry-5.1.2
    
  5. 新しいバージョンをインストールします。

    yum install -y confluent-schema-registry-<new release number>
    
  6. Schema Registry を再起動します。

    schema-registry-start SR.properties
    

Confluent REST Proxy のアップグレード

"すべての" Kafka ブローカーをアップグレードした後で Confluent REST Proxy サービスをアップグレードできます。

REST Proxy にアップグレードするには、以下のとおり実行します。

  1. RBAC が有効な環境の場合のみ: Confluent ライセンストピックリソースの REST Proxy ユーザーの ResourceOwner を追加します(デフォルト名は _confluent-command です)。その例を次に示します。

    confluent iam rolebinding create \
    --role ResourceOwner \
    --principal User:<service-account-id> \
    --resource Topic:_confluent-command \
    --kafka-cluster-id <kafka-cluster-id>
    
  2. 上記と同じ手順に従って、パッケージをアップグレードします(構成ファイルのバックアップ、パッケージの削除、アップグレードされたパッケージのインストールなど)。

  3. Confluent REST Proxy サービスを起動します。

Kafka Streams アプリケーションのアップグレード

Kafka ブローカーを最初にアップグレードしなくても、Kafka Streams アプリケーションを個別にアップグレードできます。

Kafka Streams の最新バージョンを使用するようにアプリケーションをアップグレードするには、「Kafka Streams アップグレードガイド」の手順に従います。

Kafka Connect のアップグレード

Kafka Connect は、スタンドアロンモードまたは分散モードでアップグレードできます。

重要

Starting in Confluent Platform 6.0, connectors are no longer packaged with Confluent Platform, and you need to manually install connectors. If you are upgrading Confluent Platform from any version prior to version 6.0, refer to this important upgrade note.

Kafka Connect スタンドアロンモードのアップグレード

"すべての" Kafka ブローカーがアップグレードされた後、スタンドアロンモードで Kafka Connect をアップグレードできます。

Kafka Connect をアップグレードするには、上記と同じ手順でパッケージをアップグレードします(構成ファイルのバックアップ、パッケージの削除、アップグレードされたパッケージのインストールなど)。その後、クライアントプロセスを再起動します。

Kafka Connect 分散モードのアップグレード

新しい必須構成 status.storage.topic トピック が、0.10.0.1 で Kafka Connect に追加されました。Kafka Connect クラスターをアップグレードするには、新しいバージョンにアップデートする前にこの構成を追加します。この設定は、旧バージョンの Kafka Connect では無視されます。

  1. ワーカーの構成ファイルをバックアップします。
  2. Modify your configuration file to add the status.storage.topic setting. You can safely modify the configuration file while the worker is running. Note that you should create this topic manually. See Distributed Mode Configuration in the Connect User Guide for a detailed explanation.
  3. ワーカーのローリング再起動を実行します。

ksqlDB のアップグレード

Confluent Platform ksqlDB を最新バージョンにアップグレードするには、「ksqlDB のアップグレード」の手順に従います。

Camus のアップグレード

Camus は Confluent Platform 3.0.0 で非推奨となり、Confluent Platform 5.0.0 で削除されました。

Confluent Control Center のアップグレード

Confluent Control Center のアップグレードガイド の指示に従います。

他のクライアントアプリケーションのアップグレード

クライアントアプリケーションをアップグレードする前に、「クロスコンポーネントの互換性」を確認してください。

バージョン 0.10.2 以降の Java クライアント(プロデューサーとコンシューマー)は、バージョン 0.10.0 以降の Kafka ブローカーで動作します。

0.10.0 より前のブローカーの場合は、Java クライアントをアップグレードする前に、Apache Kafka® クラスター内のすべてのブローカーをアップグレードする必要があります。

バージョン 0.10.2 のブローカーは、バージョン 0.8.x 以降の Java クライアントをサポートします。

Confluent の C/C++、Python、Go、.NET クライアントはリリースされたすべての Kafka ブローカーのバージョンをサポートしていますが、一部の機能はより新しいブローカー機能に依存しているため、ブローカーバージョンによっては使用できない機能があります。最新バージョンのクライアントでサポートされている Kafka の機能のリストについては、「Kafka クライアント」を参照してください。

妥当な場合は、新しい 2.8.x ライブラリに対して Kafka プロデューサーおよびコンシューマーを使用するアプリケーションを構築し、新しいバージョンをデプロイします。2.8.x ライブラリの使用方法の詳細については、「アプリケーション開発」を参照してください。

クライアントアプリケーションの追加アップグレード情報

  • コンシューマー API が変更されました (Kafka 0.9.0.x と 0.10.0.0 の間)。
  • librdkafka バージョン 0.11.0 では、api.version.request 構成のプロパティのデフォルト値が false から true に変更されています。つまり、librdkafka は、このプロパティを明示的に true に設定する必要なく、ブローカーの最新のプロトコル機能を使用します。その結果、Kafka 0.9.0.x のバグが原因で、0.9.0.x ブローカーでの接続開始時にクライアントとブローカーの接続が 10 秒間停止します。この問題を回避するには、0.9.0.x 以前のブローカーと通信するクライアントで api.version.request を明示的に false に構成します。