ksqlDB のアップグレード¶
ksqlDB 6.1 から ksqlDB 6.2 へのアップグレード¶
変更の網羅的なリストについては、「ksqlDB changelog」を参照してください。
注釈
ksqlDB 6.1 用に作成したクエリは、変更なしで引き続き ksqlDB 6.2 でも実行できます。6.2 で発行された新しいクエリは、クエリのステートメント文が同じでも動作が異なります。
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);
以前は、
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 句の場合は、以下のルールにより、結果のキー列の名前がどのように決定されるかを定義します。
パーティション化またはグループ化が単一の列を参照する場合、キー列の名前はこの列の名前と同じになります。以下はその例です。
-- OUTPUT has a key column named X; CREATE STREAM OUTPUT AS SELECT * FROM INPUT GROUP BY X;
パーティション化またはグループ化が構造体内の単一のフィールドの場合、キー列の名前はこのフィールドの名前と同じになります。以下に例を示します。
-- OUTPUT has a key column named FIELD1; CREATE STREAM OUTPUT AS SELECT * FROM INPUT GROUP BY X->field1;
そうでない場合はキー列名をシステムが生成し、形式は
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;
複数の式をグループ化する場合は、システムが生成したキー列の名前を指定することはできません。回避策の例として、グループ化された列を手動で結合するとエイリアスを指定することができます。
-- 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);
JOIN ステートメントの場合は、結果のキー列の名前は JOIN の基準により決定されます。
結合基準に少なくとも 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;
必要であれば、プロジェクションでエイリアスを定義することにより、キー列に新しい名前を付けることができます。以下がその例です。
-- 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;
結合基準が列参照ではない 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;
必要であれば、プロジェクションでエイリアスを定義することにより、キー列に新しい名前を付けることができます。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;
明示的なキー¶
バージョン 6.0 の新しい CREATE TABLE
ステートメントは、PRIMARY KEY
列が指定されていなければ失敗します。たとえば以下のようなステートメントは、PRIMARY KEY の定義を含むようにアップデートする必要があります。
CREATE TABLE FOO (
name STRING
) WITH (
kafka_topic='foo',
value_format='json'
);
上記のステートメントを、PRIMARY KEY の定義を含むようにアップデートします。
CREATE TABLE FOO (
ID STRING PRIMARY KEY,
name STRING
) WITH (
kafka_topic='foo',
value_format='json'
);
「スキーマの推測」とも呼ばれる Schema Registry からトピックの値列を読み込むと、プライマリキーを部分スキーマとして指定することができます。以下はその例です。
-- FOO has value columns loaded from Schema Registry
CREATE TABLE FOO (
ID INT PRIMARY KEY
) WITH (
kafka_topic='foo',
value_format='avro'
);
KEY
列を定義していない CREATE STREAM ステートメントに暗黙的な ROWKEY
キーが含まれなくなりました。以下がその例です。
CREATE STREAM BAR (
NAME STRING
) WITH (...);
バージョン 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;
キー列 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;
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;
WITH(KEY) 構文の削除¶
以前のバージョンでは、すべてのキー列が ROWKEY
と命名されていました。クエリでよりわかりやすいキー列名を使用できるように、WITH 句でキー列のエイリアスを指定することができます。以下がその例です。
CREATE TABLE INPUT (
ROWKEY INT PRIMARY KEY,
ID INT,
V0 STRING
) WITH (
key='ID', -- removed in ksqlDB 6.0
...
);
前述のクエリでは 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 (...);
これは、値のフォーマットが DELIMITED
の場合には動作しません。その理由は、値の列が 順序依存 であり ID
値の列を削除すると逆シリアル化エラーになるか、誤った値が読み込まれてしまうためです。DELIMITED
を使用する場合は、前述の例を以下のように書き換えることを考慮してください。
CREATE TABLE INPUT (
ID INT PRIMARY KEY,
ignoreMe INT,
V0 STRING
) WITH (...);
基本 + ベアラー認証¶
ksql-server.properties
で、以下の構成設定を削除します。
rest.servlet.initializor.classes
websocket.servlet.initializor.classes
以下の設定を追加します。
ksql.authentication.plugin.class=io.confluent.ksql.security.VertxBearerOrBasicAuthenticationPlugin
KSQL 5.4 から ksqlDB 5.5 へのアップグレード¶
警告
KSQL 5.4 から ksqlDB 5.5 へのアップグレードは、ローリング再起動ではありません。すべての KSQL インスタンスをシャットダウンしてからすべての ksqlDB インスタンスを起動する必要があるため、ダウンタイムが発生します。
以下の手順を完了して KSQL 5.4 から ksqlDB 5.5 へのアップグレードを実行します。
- 既存 SQL ステートメントの取り込み
- KSQL へ書き込むクライアントの停止
- 既存の KSQL デプロイの停止
- 新しいサービス ID を使用した新しい ksqlDB クラスターのデプロイ
- セキュリティのセットアップ(省略可)
- ユーザー定義関数の再コンパイル(省略可)
- 最初のステップで取り込んだ 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
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/
必ずすべてのファイルを、正しい所有者、グループ、ファイル権限を維持したままコピーします。権限に誤りがある場合は、手動で変更します。
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 はその構成を使用しますが、Confluent ではそのような構成を使用しないことを推奨しています。- 新しい構成変数
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 のサーバーでは動作しますが、次のメジャーバージョンリリース後は拒否されるようになります。代わりに、スクリプトのコンテンツをリクエストの本文に含めてください。
- REST API を介した
- 対話型モード:
- 構成:
- ヘッドレス(非対話型)モードのアプリケーションをバージョン 5.0.0 以前からアップグレードする場合は 5.1 のアップグレード手順 で指定されている構成を含める必要があります。
- ヘッドレス(非対話型)モードのアプリケーションをアップグレードする場合は、以下のプロパティをプロパティファイルに含める必要があります。
ksql.windowed.session.key.legacy=true
ksql.named.internal.topics=off
ksql.streams.topology.optimization=none
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
に変更されます。
- KSQL エンジンのメトリクスに
- 構成:
- ヘッドレス(非対話型)モードのアプリケーションをアップグレードする際には、クエリをアップデートして新しい SUBSTRING インデックス作成セマンティクスを使用するか
ksql.functions.substring.legacy.args
をtrue
に設定する必要があります。可能であれば、この構成設定を有効にする代わりに、クエリを適切にアップデートすることをお勧めします。方法の詳細については、「関数ガイド」の SUBSTRING に関するドキュメントを参照してください。なおこれは、対話型モードの KSQL については必須ではありません。
- ヘッドレス(非対話型)モードのアプリケーションをアップグレードする際には、クエリをアップデートして新しい SUBSTRING インデックス作成セマンティクスを使用するか
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 の構成」を参照してください。