1. Home
2. Platform
3. ksqlDB と Kafka Streams
4. ksqlDB

ksqlDB のアップグレード

ksqlDB 6.0 から ksqlDB 6.1 へのアップグレード

変更の網羅的なリストについては、「ksqlDB changelog」を参照してください。

注釈

ksqlDB 6.0 用に作成したクエリは、変更なしで引き続き ksqlDB 6.1 でも実行できます。6.1 で発行された新しいクエリは、クエリのステートメント文が同じでも動作が異なる場合があります。

重大な変更

• ksqlDB が、compact ではなく compact、delete クリーンアップポリシーを使用して、ウィンドウ化されたテーブルを作成するようになりました。また、ストリームを戻すトピックは常に、ブローカーのデフォルト（デフォルトは delete）ではなく delete クリーンアップポリシーを使用して作成されます。

• HAVING 句により出力テーブルにない送信元からの行が除外された場合に、ksqlDB が不要な tombstone を出力しなくなりました。たとえば、次のようになります。

  -- source stream:
  CREATE STREAM FOO (ID INT KEY, VAL INT) WITH (...);
  -- aggregate into a table:
  CREATE TABLE BAR AS
  SELECT ID, SUM(VAL) AS SUM
  FROM FOO
  GROUP BY ID
  HAVING SUM(VAL) > 0;
  -- insert some values into the stream:
  INSERT INTO FOO VALUES(1, -5);
  INSERT INTO FOO VALUES(1, 6);
  INSERT INTO FOO VALUES(1, -2);
  INSERT INTO FOO VALUES(1, -1);
  

  Copy

  以前は、BAR シンクトピックの内容には以下のレコードが含まれていました。

  キー	値	注意事項
  1	null	不正な tombstone: テーブルにキー 1 の行がないため、tombstone は不要です。
  1	{sum=1}	HAVING 条件として追加された行を検出するようになりました
  1	null	HAVING 条件として削除された行は検出しなくなりました
  1	null	不正な tombstone: テーブルにキー 1 の行がないため、tombstone は不要です。

  トピックに以下が含まれるようになりました。

  キー	値
  1	{sum=1}
  1	null

ksqlDB 5.5 から ksqlDB 6.0 へのアップグレード

変更の網羅的なリストについては、「ksqlDB changelog」を参照してください。

注釈

ksqlDB 5.5 用に作成したクエリは、変更なしで引き続き ksqlDB 6.0 でも実行できます。新しいクエリでは、アップデートされた 6.0 の構文を使用する必要があります。

注釈

ksqlDB 5.5 から ksqlDB 6.0 以降にアップグレードする場合に、次の問題が発生することがあります: 「State Store Passes Wrong Changelog Topic to Serde for Optimized Source Tables」。アップグレードされた ksqlDB アプリケーションは動作する可能性がありますが、Schema Registry ログにシリアル化例外が多数出力されます。この問題を修正するには、「phantom」更新履歴サブジェクトを削除します。詳細については、「The Curious Incident of the State Store in Recovery in ksqlDB」を参照してください。

重大な変更

• 「select star」ステートメント（select *）はもう ROWTIME 列を含むようには拡張されません。代わりに、プロジェクションに明示的に含まれている場合にのみ、クエリの結果に ROWTIME が含まれます。その例が select rowtime, * です。この変更は、新しいステートメントにのみ影響を与えます。CREATE STREAM AS SELECT または CREATE TABLE AS SELECT ステートメントを使用して以前に作成されたビューは、いずれも影響を受けません。

• このリリースでは、構造体のプロジェクション逆参照フィールド内の任意の列に対してシステムが生成する列名が変更されています。以前は、名前を生成する際に完全なパスが使用されていました。6.0 では、最後のフィールド名のみが使用されます。たとえば SELECT someStruct->someField, ... の場合、以前は SOMESTRUCT__SOMEFIELD という列名を生成していましたが、現在は SOMEFIELD という列名を生成します。生成された列名には、たとえば SOMEFIELD_2 のように、一意性を確保するための数字が末尾に付加される場合があります。

  注釈

  命名ロジックはリリース間で変更される可能性があるため、本稼働環境ではシステムが生成する列名に依存しないようにすることをお勧めします。SELECT someStruct->someField AS someField のように明示的なエイリアスを指定することにより、リリース間で命名の一貫性を維持することができます。後方互換性のため、実行中の既存クエリはこの変更の影響を受けず、同じ列名で実行され続けます。アップグレードの 後に 実行されるステートメントはすべて、明示的なエイリアスの指定がなければ新しい名前を使用します。以前の名前が必要な場合は、SELECT someStruct->someField AS SOMESTRUCT__SOMEFIELD, ... のように明示的なエイリアスをステートメントに追加します。

• バージョン 5.5 では、プロジェクション内の単一の GROUP BY 列を参照するクエリは、重複列が原因で再送されると失敗することがありました。6.0 では、同じ既存クエリは、既に実行中であれば実行され続けます。つまりこの変更は、新たに送信されたクエリにのみ影響を与えます。既存のクエリは以前のクエリセマンティクスを使用します。

• 自動生成された列名に依存するプッシュクエリの場合は、列名が変更されることがあります。CREATE STREAM AS SELECT、CREATE TABLE AS SELECT、または INSERT INTO などで作成されたプルクエリや既存の永続的なクエリは、影響を受けません。

• ksqlDB サーバーの出荷に Jetty が含まれなくなりました。したがってサーバーを起動する際には、ksqlDB が Jetty を見つけられるように、KSQL_CLASSPATH 環境変数を使用して、HTTP 基本認証に使用する特定のログインモジュールをはじめとする Jetty 固有の依存関係を供給する必要があります。

任意キー名

PARTITION BY 句、GROUP BY 句、または JOIN 句を含むステートメントでは、異なる出力スキーマが生成されるようになりました。

PARTITION BY 句および GROUP BY 句の場合は、以下のルールにより、結果のキー列の名前がどのように決定されるかを定義します。

1. パーティション化またはグループ化が単一の列を参照する場合、キー列の名前はこの列の名前と同じになります。以下はその例です。

   -- OUTPUT has a key column named X;
   CREATE STREAM OUTPUT AS
     SELECT *
     FROM INPUT
     GROUP BY X;
   

   Copy

2. パーティション化またはグループ化が構造体内の単一のフィールドの場合、キー列の名前はこのフィールドの名前と同じになります。以下に例を示します。

   -- OUTPUT has a key column named FIELD1;
   CREATE STREAM OUTPUT AS
     SELECT *
     FROM INPUT
     GROUP BY X->field1;
   

   Copy

3. そうでない場合はキー列名をシステムが生成し、形式は KSQL_COL_n になります。ここでの n は正の整数です。

複数の列でグループ化する場合を除き、いずれの場合も、プロジェクションでエイリアスを定義することにより新しいキー列の名前を設定することができます。以下の例をご覧ください。

 -- OUTPUT has a key column named ID.
 CREATE TABLE OUTPUT AS
   SELECT
     USERID AS ID,
     COUNT(*)
   FROM USERS
   GROUP BY ID;

Copy

複数の式をグループ化する場合は、システムが生成したキー列の名前を指定することはできません。回避策の例として、グループ化された列を手動で結合するとエイリアスを指定することができます。

-- products_by_sub_cat has a key column named COMPOSITEKEY:
CREATE TABLE products_by_sub_cat AS
  SELECT
    categoryId + ‘§’ + subCategoryId AS compositeKey
    SUM(quantity) as totalQty
  FROM purchases
  GROUP BY CAST(categoryId AS STRING) + ‘§’ + CAST(subCategoryId AS STRING);

Copy

JOIN ステートメントの場合は、結果のキー列の名前は JOIN の基準により決定されます。

1. 結合基準に少なくとも 1 つの列参照が含まれている INNER 結合と LEFT OUTER 結合では、結合基準が列参照である左端のソースを基にキー列が命名されます。以下がその例です。

   -- OUTPUT has a key column named I2_ID.
   CREATE TABLE OUTPUT AS
     SELECT *
     FROM I1
       JOIN I2 ON abs(I1.ID) = I2.ID JOIN I3 ON I2.ID = I3.ID;
   

   Copy

   必要であれば、プロジェクションでエイリアスを定義することにより、キー列に新しい名前を付けることができます。以下がその例です。

   -- OUTPUT has a key column named ID.
   CREATE TABLE OUTPUT AS
     SELECT
       I2.ID AS ID,
       I1.V0,
       I2.V0,
       I3.V0
     FROM I1
       JOIN I2 ON abs(I1.ID) = I2.ID
       JOIN I3 ON I2.ID = I3.ID;
   

   Copy

2. 結合基準が列参照ではない FULL OUTER 結合またはその他の結合では、出力のキー列は、どのソースのどの列とも等しくなりません。キー列はシステム生成の名前を持ち、形式は KSQL_COL_n になります。ここでの n は正の整数です。以下がその例です。

   -- OUTPUT has a key column named KSQL_COL_0, or similar.
   CREATE TABLE OUTPUT AS
     SELECT *
     FROM I1
       FULL OUTER JOIN I2 ON I1.ID = I2.ID;
   

   Copy

   必要であれば、プロジェクションでエイリアスを定義することにより、キー列に新しい名前を付けることができます。6.0 では、エイリアスの定義に役立つように JOINKEY という名前の新しい UDF が導入されました。これは、結合基準をパラメーターとして受け取ります。以下がその例です。

   -- OUTPUT has a key column named ID.
   CREATE TABLE OUTPUT AS
     SELECT
       JOINKEY(I1.ID, I2.ID) AS ID,
       I1.V0,
       I2.V0
     FROM I1
       FULL OUTER JOIN I2 ON I1.ID = I2.ID;
   

   Copy

明示的なキー

バージョン 6.0 の新しい CREATE TABLE ステートメントは、PRIMARY KEY 列が指定されていなければ失敗します。たとえば以下のようなステートメントは、PRIMARY KEY の定義を含むようにアップデートする必要があります。

CREATE TABLE FOO (
    name STRING
  ) WITH (
    kafka_topic='foo',
    value_format='json'
  );

Copy

上記のステートメントを、PRIMARY KEY の定義を含むようにアップデートします。

 CREATE TABLE FOO (
     ID STRING PRIMARY KEY,
     name STRING
   ) WITH (
     kafka_topic='foo',
     value_format='json'
   );

Copy

「スキーマの推測」とも呼ばれる Schema Registry からトピックの値列を読み込むと、プライマリキーを部分スキーマとして指定することができます。以下はその例です。

-- FOO has value columns loaded from Schema Registry
CREATE TABLE FOO (
    ID INT PRIMARY KEY
  ) WITH (
    kafka_topic='foo',
    value_format='avro'
  );

Copy

KEY 列を定義していない CREATE STREAM ステートメントに暗黙的な ROWKEY キーが含まれなくなりました。以下がその例です。

CREATE STREAM BAR (
    NAME STRING
  ) WITH (...);

Copy

バージョン 5.5 では、前のステートメントは ROWKEY STRING KEY と NAME STRING の 2 つの列を持つストリームを生成していました。今回の変更により、前のステートメントでは NAME STRING 列のみを持つストリームが生成されます。

KEY 列を持たないストリームは null キーを持つ Apache Kafka® トピックにシリアル化されます。

プロジェクションで必須となるキー列

マテリアライズドビューを作成するステートメントの場合は、プロジェクションにキー列が含まれていなければなりません。以下がその例です。

 CREATE TABLE OUTPUT AS
   SELECT
       productId,            -- key column in projection
       SUM(quantity) as unitsSold
   FROM sales
   GROUP BY productId;

Copy

キー列 productId はプロジェクションでは必須です。以前のバージョンの ksqlDB では、プロジェクションに productId が存在すると、基盤となる Kafka トピックのレコードの 値 にデータの コピー が配置されていました。バージョン 6.0 からは、プロジェクションにはキー列が含まれていなければならず、ksqlDB はこれらの列の基盤となる Kafka レコードの キー に保管します。必要に応じて、キー列のエイリアスを指定することもできます。以下はその例です。

 CREATE TABLE OUTPUT AS
   SELECT
       productId as id,            -- aliased key column
       SUM(quantity) as unitsSold
   FROM sales
   GROUP BY productId;

Copy

Kafka のレコードの値のキー列のコピーが必要な場合は、AS_VALUE 関数を使用して、これを ksqlDB に指示します。たとえば以下のステートメントは、前述の例のマテリアライズドビューについて、以前のバージョンの ksqlDB のような出力を生成します。

 CREATE TABLE OUTPUT AS
   SELECT
       productId as ROWKEY,                -- key column named ROWKEY
       AS_VALUE(productId) as productId,   -- productId copied into value
       SUM(quantity) as unitsSold
   FROM sales
   GROUP BY productId;

Copy

WITH(KEY) 構文の削除

以前のバージョンでは、すべてのキー列が ROWKEY と命名されていました。クエリでよりわかりやすいキー列名を使用できるように、WITH 句でキー列のエイリアスを指定することができます。以下がその例です。

 CREATE TABLE INPUT (
     ROWKEY INT PRIMARY KEY,
     ID INT,
     V0 STRING
   ) WITH (
     key='ID',    -- removed in ksqlDB 6.0
     ...
   );

Copy

前述のクエリでは ID 列を ROWKEY のエイリアスとして使用できます。この方法では Kafka メッセージの値にキーの正確なコピーを含める必要がありました。KLIP-24 によりキー列は ROWKEY と命名しなければならないという制約がなくなり、WITH(KEY) 構文の必要性がなくなるため、この構文は削除されました。この変更により、Kafka メッセージの値にキーの正確なコピーを含めるという要件もなくなりました。

WITH 句から KEY を削除して KEY 列と PRIMARY KEY 列に適切な名前を付けることにより、クエリをアップデートします。たとえば、前述の CREATE TABLE ステートメントはこのように書き換えることができます。

 CREATE TABLE INPUT (
     ID INT PRIMARY KEY,
     V0 STRING
   ) WITH (...);

Copy

これは、値のフォーマットが DELIMITED の場合には動作しません。その理由は、値の列が 順序依存 であり ID 値の列を削除すると逆シリアル化エラーになるか、誤った値が読み込まれてしまうためです。DELIMITED を使用する場合は、前述の例を以下のように書き換えることを考慮してください。

 CREATE TABLE INPUT (
     ID INT PRIMARY KEY,
     ignoreMe INT,
     V0 STRING
   ) WITH (...);

Copy

基本 + ベアラー認証

ksql-server.properties で、以下の構成設定を削除します。

• rest.servlet.initializor.classes
• websocket.servlet.initializor.classes

以下の設定を追加します。

ksql.authentication.plugin.class=io.confluent.ksql.security.VertxBearerOrBasicAuthenticationPlugin

Copy

KSQL 5.4 から ksqlDB 5.5 へのアップグレード

警告

KSQL 5.4 から ksqlDB 5.5 へのアップグレードは、ローリング再起動ではありません。すべての KSQL インスタンスをシャットダウンしてからすべての ksqlDB インスタンスを起動する必要があるため、ダウンタイムが発生します。

以下の手順を完了して KSQL 5.4 から ksqlDB 5.5 へのアップグレードを実行します。

1. 既存 SQL ステートメントの取り込み
2. KSQL へ書き込むクライアントの停止
3. 既存の KSQL デプロイの停止
4. 新しいサービス ID を使用した新しい ksqlDB クラスターのデプロイ
5. セキュリティのセットアップ（省略可）
6. ユーザー定義関数の再コンパイル（省略可）
7. 最初のステップで取り込んだ SQL ステートメントの再生

既存 SQL ステートメントの取り込み

既存の SQL ステートメントを取り込むには、kafka-console-consumer を使用して既存の KSQL コマンドトピックを出力することをお勧めします。以下のコマンド例は、出力をパイプにより "jq" に連結して SQL コマンドを "statements.sql" ファイルに保存する方法を示しています。

注釈

-consumer.config オプションを使用して kafka-console-consumer コマンドの認証情報を指定する必要があります。詳細については、「SSL による暗号化と認証」を参照してください。

# export KSQL_SERVICE_ID=<ksql.service.id>
# export BROKER=localhost
# export PORT=9092
./bin/kafka-console-consumer --bootstrap-server ${BROKER}:${PORT} --topic _confluent-ksql-${KSQL_SERVICE_ID}_command_topic --from-beginning | jq -r ".statement" > statements.sql

Copy

kafka-console-consumer ツールを取得するには Confluent Platform をインストール します。

ステートメントを調べ、コマンドが想定どおりに動作したことを確認します。また、CREATE/DROP のステートメントをすべて新しいクラスターで実行する場合は、CREATE/DROP のペアリングを削除するほうがよいでしょう。

KSQL へ書き込むクライアントの停止

データの損失を防ぐために、KSQL クラスターへ書き込むすべてのクライアントのアプリケーションおよびプロデューサーを停止します。

既存の KSQL デプロイの停止

KSQL クラスターを停止します。クラスターを停止する手順はデプロイによって異なります。たとえば、RPM デプロイの場合は systemctl の使用をお勧めします。docker-compose スタックを使用している場合は docker-compose down コマンドを使用できます。

ksqlDB パッケージのインストール

DEB または RPM リリースの成果物を使用するデプロイの場合は、古いパッケージをアンインストールして新しいものをインストールする必要があります。構成ディレクトリが /etc/ksql から /etc/ksqldb へ変わったため、構成ファイルもすべて新しい場所へコピーする必要があります。

cp -p ${CONFLUENT_HOME}/etc/ksql/* ${CONFLUENT_HOME}/etc/ksqldb/

Copy

必ずすべてのファイルを、正しい所有者、グループ、ファイル権限を維持したままコピーします。権限に誤りがある場合は、手動で変更します。

ksqlDB サービス ID の変更

ksqlDB はデプロイの方法に応じて構成されますが ksql.service.id にもそれに応じた値を使用しなければ新しい ksqlDB サーバーを起動することはできません。古い値を使用すると、サーバーは起動しません。ここでは、一般的なデプロイのメカニズムと、この構成を変更する方法について説明します。

• Debian/RPM: ${CONFLUENT_HOME}/etc/ksqldb/ksql-server.properties でのプロパティを変更します。
• Docker: 環境変数 KSQL_KSQL_SERVICE_ID を変更します。
• Kubernetes 用の Confluent（CFK）: 「CFK によるアップグレード」を参照してください。

セキュリティのセットアップ（省略可）

セキュリティを有効にしている場合は、ksqlDB アプリのセキュリティをセットアップします。ksqlDB では、ロールベースアクセス制御（RBAC） および ACL の使用および認可の不使用がサポートされています。

ksql サービスプリンシパルに対して新しいロールバインディングを作成するか、ACL を割り当てます。

• Topic: __consumer_offsets

• Topic: __transaction_state

• TransactionalId: 構成ファイルで設定した値（ksqldb_ など）。

  セキュリティに ACL を使用している場合は、これらの ACL が必要です。

  • LITERAL 名が __consumer_offsets の TOPIC に対する DESCRIBE 操作。
  • LITERAL 名が __transaction_state の TOPIC に対する DESCRIBE 操作。
  • LITERAL 名が <ksql.service.id> の TRANSACTIONAL_ID に対する DESCRIBE および WRITE 操作。

  セキュリティに RBAC を使用している場合は、これらのロール割り当てが必要です。

  • __consumer_offsets トピックに対する DeveloperRead ロール
  • __transaction_state トピックに対する DeveloperRead ロール
  • <ksql.service.id> TransactionalId に対する DeveloperWrite ロール

ユーザー定義関数の再コンパイル（省略可）

KSQL アプリケーションがユーザー定義関数を使用する場合は、アップグレード済みの依存関係を使用してこれらを再コンパイルする必要があります。詳細については、「ksqlDB カスタム関数リファレンス（UDF、UDAF、および UDTF）」を参照してください。

ksqlDB の起動

ksqldb サービスを起動します。クラスターを開始する手順はデプロイによって異なります。たとえば、RPM デプロイの場合は systemctl の使用をお勧めします。docker-compose スタックを使用している場合は、docker-compose up コマンドを使用できます。

SQL ステートメントの再生

SQL ステートメントを再生するには、ksqlDB CLI を起動して RUN SCRIPT <path-to-statements.sql>; を発行します。

重要

KSQL と ksqlDB の間で後方互換性のない構文の変更があり、一部のステートメントは失敗する可能性があります。この場合は statements.sql でステートメントを 1 つずつ実行し、失敗したステートメントを修正します。特に継続的なクエリや永続的なクエリでは、EMIT CHANGES 構文が必須になりました。詳細については、「重大な変更」を参照してください。

KSQL 5.4 へのアップグレード

サーバーを一度に 1 台ずつ「ローリング再起動」でアップグレードします。残りのサーバーには、一時的に使用不可になる再起動中のサーバーから作業を引き継ぐのに十分な空き容量が必要です。

5.4 での注目すべき変更:

• KSQL Server

  • クエリ ID の生成

    • このバージョンの KSQL では、永続的なクエリ（INSERT INTO/CREATE STREAM AS SELECT/CREATE TABLE AS SELECT）に対するクエリ ID の生成方法が変更されています。以前は、永続的なクエリが正しく作成されるたびにクエリ ID が増やされていました。新しいクエリ ID は、KSQL コマンドトピックのクエリ作成コマンドの Kafka レコードオフセットを使用します。

      クエリ ID 間で不整合が生じないように、KSQL サーバー（5.3 以前）のアップグレード中に新しい永続的なクエリを作成しないでください。実行中の古いクエリは再起動時に元の ID を保持し、新しいクエリは新しい ID 生成規則を利用します。

      詳細については Github PR #3354 を参照してください。

KSQL 5.2 から KSQL 5.3 へのアップグレード

5.3 での注目すべき変更:

• KSQL Server

  • Avro スキーマの互換性

    • このバージョンの KSQL では、UDF および UDAF から返されるスキーマが Null 許容とマークされない場合があるというバグを修正します。これは null 値が存在する場合に、UDF が失敗すると遭遇するようなシリアル化の問題を引き起こす可能性があります。

      バグ修正により、すべてのフィールドが省略可能になりました。

      これは Avro における前方互換の変更であり、アップグレード後の KSQL は新しいスキーマを使用して古い値を読み取ることができます。ただし KSQL をアップグレードする前に、データを消費する下流のコンシューマーがアップデート済みのスキーマを使用していることを確認することが重要であり、そうでない場合は逆シリアル化が失敗する可能性があります。アップデート済みのスキーマを取得する最良の方法は、バージョン 5.3 を実行している別の KSQL クラスターでクエリを実行することです。

      詳細については Github issue #2769 を参照してください。

• 構成:

  • ksql.sink.partitions および ksql.sink.replicas は非推奨です。すべての新しいクエリは、パーティションとレプリカが WITH 句で設定されていない限り、代わりにシンクトピックのソーストピックのパーティション数とレプリカ数を使用します。
  • 新しい構成変数 ksql.internal.topic.replicas は、KSQL Server により作成される内部トピックのレプリカ数を設定するために導入されました。内部トピックには、コマンドトピックまたは構成トピックが含まれています。

KSQL 5.1 から KSQL 5.2 へのアップグレード

5.2 での注目すべき変更:

• KSQL Server
  • 対話型モード:
    • REST API を介した RUN SCRIPT の使用は非推奨になり、次のメジャーリリースでは削除されます。（ Github issue 2179 ）。この機能はある種の正確性チェックを周回するものであり、リクエストの本文でスクリプトのコンテンツを指定できるとすれば不要です。RUN SCRIPT 機能を KSQL CLI から使用する場合は、引き続きサポートされるためスクリプトは影響を受けません。RUN SCRIPT 機能を REST API に対して直接使用する場合、リクエストは 5.2 のサーバーでは動作しますが、次のメジャーバージョンリリース後は拒否されるようになります。代わりに、スクリプトのコンテンツをリクエストの本文に含めてください。
• 構成:
  • ヘッドレス（非対話型）モードのアプリケーションをバージョン 5.0.0 以前からアップグレードする場合は 5.1 のアップグレード手順 で指定されている構成を含める必要があります。
  • ヘッドレス（非対話型）モードのアプリケーションをアップグレードする場合は、以下のプロパティをプロパティファイルに含める必要があります。

ksql.windowed.session.key.legacy=true
ksql.named.internal.topics=off
ksql.streams.topology.optimization=none

Copy

KSQL のバージョン 5.1 およびそれ以前は、Kafka の、セッションウィンドウ化されたデータのレコードキーの終了時刻を誤って除外していました。ksql.windowed.session.key.legacy=true 構成により、終了時刻がないセッションキーを KSQL が継続して保管することが保証されます。

また、バージョン 5.1 は Kafka Streams 最適化を使用していませんでした。このため、内部トピック名を有効化する必要がありました。互換性を確保するため、ksql.named.internal.topics 構成と ksql.streams.topology.optimization 構成は無効になりました。

KSQL 5.0.0 以前から KSQL 5.1 へのアップグレード

• KSQL サーバー:
  • KSQL エンジンのメトリクスに ksql.service.id というプレフィックスが付けられるようになりました。メトリックモニタリングツールを使用している場合は、メトリック名をアップデートする必要があります。たとえば ksql.service.id が default_ に設定されるとすると messages-produced-per-sec は _confluent-ksql-default_messages-consumed-per-sec に変更されます。
• 構成:
  • ヘッドレス（非対話型）モードのアプリケーションをアップグレードする際には、クエリをアップデートして新しい SUBSTRING インデックス作成セマンティクスを使用するか ksql.functions.substring.legacy.args を true に設定する必要があります。可能であれば、この構成設定を有効にする代わりに、クエリを適切にアップデートすることをお勧めします。方法の詳細については、「関数ガイド」の SUBSTRING に関するドキュメントを参照してください。なおこれは、対話型モードの KSQL については必須ではありません。

KSQL 0.x（開発者プレビュー）から KSQL 4.1 へのアップグレード

KSQL 4.1 には、以前の KSQL 0.x 開発者プレビューリリースとの後方互換性はありません。特に、古いプレビューリリースの KSQL で実行されているクエリは、CREATE STREAM や CREATE TABLE のようなステートメントを再度発行することにより、4.1 バージョンへ手動で移行しなければなりません。

4.1 での注目すべき変更:

• KSQL CLI:
  • ksql-cli コマンドの名前が ksql に変更されました。
  • CLI は以前に「スタンドアロン」または「ローカル」と呼ばれていたモードをもうサポートしていません。これらのモードでは、ksql-cli は CLI および同一 JVM（Java 仮想マシン）内の KSQL サーバープロセスの両方を実行していました。4.1 では ksql は CLI のみを実行します。ローカルでの開発およびテスト向けには confluent start （これにより KSQL サーバーも起動）に続けて ksql を実行し、CLI を起動できます。このセットアップは Confluent Platform クイックスタート にも使用できます。または、「ksqlDB サーバーの起動」の説明に従って KSQL サーバーを直接起動した後 ksql で CLI を起動することもできます。
• KSQL サーバー:
  • listeners のデフォルトアドレスが http://localhost:8088 に変更されました（KSQL 0.x では http://localhost:8080 を使用していました）。
  • 特定の KSQL クラスターへの KSQL サーバーの割り当てが簡素化され、ksql.service.id 設定で行われるようになりました。詳細については、「ksql.service.id」を参照してください。
• .sql ファイルの実行: .sql ファイルに格納されている定義済み KSQL クエリを実行するには、「非対話型（ヘッドレス）ksqlDB の使用法」を参照してください。
• 構成: KSQL に熟練したユーザーであれば、KSQL が使用する Kafka Streams および Kafka プロデューサー/コンシューマークライアント設定を構成できます。これを行うには、それぞれの構成設定向けのプレフィックスを使用します。詳細については、「ksqlDB サーバーを構成する」、「構成パラメーターリファレンス」、および「ksqlDB CLI の構成」を参照してください。