Realtime Compute for Apache Flink:Flink CDC に関するよくある質問

失敗時に再起動ではなくキャンセルするようにデプロイを設定できますか?

デプロイ設定で再起動ストラテジーを設定します。次の例では、再起動を 10 秒間隔で 2 回まで試行し、両方とも失敗した場合はデプロイをキャンセルします。

restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2
restart-strategy.fixed-delay.delay: 10 s

MySQL CDC ソーステーブルと Hologres CDC ソーステーブルはウィンドウ関数をサポートしていません。分単位の集計を実装するにはどうすればよいですか?

DATE_FORMAT を使用してタイムスタンプを分単位の文字列に変換し、その文字列で GROUP BY を実行します。次の例では、店舗ごとの注文数と売上を毎分計算します。

SELECT
    shop_id,
    DATE_FORMAT(order_ts, 'yyyy-MM-dd HH:mm') AS window,
    COUNT(*) AS order_count,
    SUM(price) AS amount
FROM order_mysql_cdc
GROUP BY shop_id, window

MySQL CDC テーブルをディメンションテーブルまたはシンクテーブルとして使用できますか?

いいえ。MySQL CDC テーブルはソーステーブルとしてのみ使用できます。MySQL から完全データとインクリメンタルデータを読み取ります。ディメンションまたはシンクのユースケースでは、通常の MySQL テーブル (CDC ではない) を使用してください。

MySQL CDC コネクタが完全データの読み取り後に停止し、インクリメンタルモードに切り替わらないのはなぜですか?

通常、次の 4 つの原因のいずれかが考えられます：

• セカンダリまたは読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンス：これらのインスタンスはバイナリログファイルにデータを書き込まないため、コネクタが読み取るインクリメンタルデータがありません。書き込み可能なインスタンスを使用するか、V5.6 より後のバージョンにアップグレードしてください。

• バイナリログトランザクション圧縮が有効：MySQL CDC ソーステーブルはバイナリログトランザクション圧縮をサポートしていません。セルフマネージド MySQL クラスターでこの機能を無効にしてください。

• 完全データ読み取り中のメモリ不足 (OOM)：最後のシャードが大きすぎる場合、OOM エラーによりフェイルオーバー後にデプロイが一時停止します。並列度を上げて完全データの読み取りを高速化してください。

• チェックポイント間隔が長すぎる：すべての並列サブタスクが完全データの読み取りを完了した後、コネクタはインクリメンタルモードに切り替わる前に 1 つのチェックポイントを待機します。チェックポイント間隔が 20 分の場合、20 分の遅延が発生します。要件に基づいて、より短いチェックポイント間隔を設定してください。

完全データ同期が完了したことを確認するにはどうすればよいですか?

2 つの方法があります：

• currentEmitEventTimeLag メトリック: [デプロイメント] ページの [メトリクス] タブで、このメトリックを確認します。値が 0 以下の場合、フル同期がまだ進行中であることを意味します。値が 0 より大きい場合は、コネクタがフル同期を完了し、バイナリログデータの読み取りを開始したことを意味します。

  

• TaskManager ログ：TaskManager ログで BinlogSplitReader is created を検索します。このメッセージは、完全データの読み取りが完了したことを示します。

  

デプロイを再起動すると、開始位置は変わりますか?

[デプロイ開始設定] ダイアログボックスで選択する 開始戦略 によって異なります:

• [NONE]：コネクタは設定された開始位置から再度読み取ります。

• [Latest State]：コネクタは、デプロイが最後にキャンセルされたバイナリログ位置から再開します。

たとえば、デプロイが {file=mysql-bin.01, position=40} から開始するように設定されていたが、位置 210 でキャンセルされた場合、 [Latest State] は 210 から再開し、 [NONE] は 40 から再起動します。

MySQL CDC コネクタはどのように動作し、データベースにどのような影響を与えますか?

scan.startup.mode が initial (デフォルト) に設定されている場合、コネクタは次のように動作します：

1. JDBC 経由で接続し、SELECT ステートメントを実行して完全データを読み取り、現在のバイナリログ位置を記録します。

2. 完全データの読み取り後、バイナリログクライアントに切り替えて、記録された位置からインクリメンタルな変更を読み取ります。

完全データの読み取りは、SELECT ステートメントによってクエリ負荷を増加させます。インクリメンタル読み取り中、各ソーステーブルは 1 つのバイナリログ接続を保持します。ソーステーブルが多数ある場合は、接続制限を確認してください。

show variables like '%max_connections%';

スナップショットフェーズをスキップして、変更データのみを読み取るにはどうすればよいですか?

WITH 句で scan.startup.mode を次のいずれかに設定します：earliest-offset、latest-offset、specific-offset、または timestamp。詳細については、「MySQL CDC ソーステーブルの作成」の「WITH 句のパラメータ」セクションをご参照ください。

scan.startup.mode = timestamp の場合、MySQL CDC はどのようにバイナリログ位置を特定しますか?

timestamp 起動モードでは、MySQL CDC は次のように初期消費位置を決定します：

1. すべてのバイナリログファイルをスキャンし、最終更新時刻が指定されたタイムスタンプ以上である最初のファイルを見つけます。

2. そのファイルの先頭からバイナリログイベントを読み取ります。

3. タイムスタンプが指定されたタイムスタンプより前のイベントをスキップします。

4. タイムスタンプが指定されたタイムスタンプ以上である最初のイベントから消費を開始します。

境界ケース：

• 指定されたタイムスタンプが未来の場合、利用可能な最新の位置から消費を開始します。これは latest-offset と同等です。

• 指定されたタイムスタンプに対応するバイナリログがすでにパージされている場合、利用可能な最も古い位置から消費を開始します。これは earliest-offset と同等です。

コネクタはシャーディングされた MySQL テーブルをどのように処理しますか?

table-name パラメータで正規表現を使用して、すべてのシャードに一致させます。たとえば、プレフィックスが user_ のすべてのテーブルを監視するには、次のようにします：

'table-name' = 'user_.*'

すべてのシャードのテーブルが同じスキーマを持つ場合は、代わりに database-name で正規表現を使用します。

table-name 正規表現内のカンマが解析エラーを引き起こす場合、どうすればよいですか?

Debezium はカンマを区切り文字として使用するため、t_process_wi_history_\d{1,2} のようなパターンは失敗します。

代わりに選択を使用してください。

'table-name' = '(t_process_wi_history_\d{1}|t_process_wi_history_\d{2})'

複数の MySQL CDC デプロイによってデータベース負荷が高くなっています。どうすればよいですか?

2 つのアプローチがあります：

• Kafka へのオフロード：MySQL CDC ソーステーブルを ApsaraMQ for Kafka シンクテーブルに同期します。他のデプロイは、バイナリログを直接読み取る代わりに Kafka から消費します。詳細については、「MySQL データベース内のすべてのテーブルを Kafka に同期する」をご参照ください。

• 共有サーバー ID でデプロイをマージ：複数の CREATE TABLE AS デプロイが同じ設定を共有する場合、同じサーバー ID を割り当ててデータソースを再利用します。詳細については、「例 4：複数の CREATE TABLE AS ステートメントの実行」をご参照ください。

小規模な更新で異常に高い帯域幅使用量となるのはなぜですか?

バイナリログファイルには、MySQL インスタンス内のすべてのデータベースとテーブルの変更が含まれています。デプロイが監視するものだけではありません。インスタンスに 3 つのテーブルがある場合、デプロイが 1 つのテーブルのみを追跡していても、バイナリログには 3 つすべてからの変更が含まれます。

これを修正するには、MySQL CDC ソーステーブルを再利用して、複数のデプロイが単一のバイナリログ接続を共有するように設定します。詳細については、「MySQL コネクタ」の「MySQL CDC ソーステーブルの再利用の有効化」セクションをご参照ください。

タイムスタンプフィールドが MySQL サーバーのタイムゾーンと比較して 8 時間ずれて表示されるのはなぜですか?

2 つの原因が考えられます：

• CDC デプロイの server-time-zone パラメータが実際の MySQL サーバーのタイムゾーンと一致していません。server-time-zone を実際の MySQL サーバーのタイムゾーンと一致するように更新してください。

• カスタムデシリアライザ (MyDeserializer implements DebeziumDeserializationSchema) が serverTimeZone を設定していません。RowDataDebeziumDeserializeSchema が TIMESTAMP データを解析する方法に基づいて serverTimeZone を設定してください。

  private TimestampData convertToTimestamp(Object dbzObj, Schema schema) {
      if (dbzObj instanceof Long) {
          switch (schema.name()) {
              case Timestamp.SCHEMA_NAME:
                 return TimestampData.fromEpochMillis((Long) dbzObj);
              case MicroTimestamp.SCHEMA_NAME:
                 long micro = (long) dbzObj;
                 return TimestampData.fromEpochMillis(micro / 1000, (int) (micro % 1000 * 1000));
              case NanoTimestamp.SCHEMA_NAME:
                 long nano = (long) dbzObj;
                 return TimestampData.fromEpochMillis(nano / 1000_000, (int) (nano % 1000_000));
          }
      }
      LocalDateTime localDateTime = TemporalConversions.toLocalDateTime(dbzObj, serverTimeZone);
      return TimestampData.fromLocalDateTime(localDateTime);
  }

MySQL CDC コネクタはセカンダリデータベースをリッスンできますか?

はい。プライマリから同期されたデータがセカンダリのバイナリログに書き込まれるように、セカンダリデータベース設定に次の設定を追加してください：

log-slave-updates = 1

プライマリでグローバルトランザクション識別子 (GTID) モードが有効になっている場合は、セカンダリでも有効にします。

gtid_mode = on
enforce_gtid_consistency = on

DDL イベントをキャプチャするにはどうすればよいですか?

DataStream API で MySqlSource を使用し、includeSchemaChanges(true) を設定します。

MySqlSource<xxx> mySqlSource =
    MySqlSource.<xxx>builder()
        .hostname(...)
        .port(...)
        .databaseList("<databaseName>")
        .tableList("<databaseName>.<tableName>")
        .username(...)
        .password(...)
        .serverId(...)
        .deserializer(...)
        .includeSchemaChanges(true) // DDL イベントをキャプチャ
        .build();
// ダウンストリーム処理ロジックを追加

MySQL CDC はデータベース内のすべてのテーブルを一度に同期することをサポートしていますか?

はい。CREATE TABLE AS または CREATE DATABASE AS ステートメントを使用します。詳細については、「CREATE TABLE AS ステートメント」または「CREATE DATABASE AS ステートメント」をご参照ください。

セカンダリまたは読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスは、インクリメンタルな変更をバイナリログファイルに書き込まないため、コネクタはこれらのインスタンスからインクリメンタルデータを読み取ることができません。

特定のテーブルのインクリメンタルデータが同期されないのはなぜですか?

MySQL サーバーのバイナリログフィルターがそのデータベースを除外している可能性があります。次のコマンドを実行して確認してください：

show master status;

出力の Binlog_Ignore_DB および Binlog_Do_DB 列を確認してください。

+------------------+----------+--------------+------------------+----------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |  Executed_Gtid_Set   |
+------------------+----------+--------------+------------------+----------------------+
| mysql-bin.000006 |     4594 |              |                  | xxx:1-15             |
+------------------+----------+--------------+------------------+----------------------+

MySQL CDC に DataStream API を使用する場合、tableList をどのように設定しますか?

tableList の値には、データベース名とテーブル名の両方を yourDatabaseName.yourTableName の形式で含める必要があります。

完全データの読み取り中にデプロイが失敗した場合、コネクタはチェックポイントから再開できますか?

はい。WITH 句で 'scan.incremental.snapshot.enabled' = 'true' を設定して、完全データの読み取り中にチェックポイントベースのリカバリを有効にします。

MongoDB CDC はインクリメンタルデータのみの読み取りをサポートしていますか?

デフォルトでは、コネクタは完全データとインクリメンタルデータの両方を読み取ります。完全データをスキップしてインクリメンタルな変更のみを読み取るには、WITH 句で 'scan.startup.mode' = 'latest-offset' を設定します。

特定のコレクションのみをサブスクライブできますか?

いいえ。コネクタはデータベースレベルでサブスクライブします。WITH 句で 'database' = 'mgdb' および 'collection' = '' を設定して、データベース内のすべてのコレクションをサブスクライブします。

MongoDB CDC は並列読み取りをサポートしていますか?

はい、初期スナップショットフェーズ中です。scan.incremental.snapshot.enabled を true に設定して並列読み取りを有効にします。

どの MongoDB バージョンがサポートされていますか?

MongoDB 3.6 以降 (変更ストリームは 3.6 で導入されました)。MongoDB 4.0 以降を推奨します。3.6 より前のバージョンでは、コネクタはエラー "Unrecognized pipeline stage name: '$changeStream'" を返します。

どの MongoDB アーキテクチャがサポートされていますか?

コネクタにはレプリカセットまたはシャーディングクラスタが必要です。変更ストリームはこれらのモードでのみ機能します。ローカルテストの場合は、rs.initiate() を使用して MongoDB を単一ノードレプリカセットに変換します。これを行わないと、コネクタは "The $changeStream is only supported on replica sets" を返します。

MongoDB CDC は Debezium パラメータをサポートしていますか?

いいえ。MongoDB CDC コネクタは Flink CDC で独自に開発されたものであり、Debezium には依存していません。

認証情報が正しいにもかかわらず、認証が失敗するのはなぜですか?

ユーザー認証情報のスコープは特定のデータベースに限定されます。WITH 句に 'connection.options' = 'authSource=<database_the_user_belongs_to>' を追加してください。

デプロイの再起動後、コネクタはチェックポイントから再開できますか?

はい。チェックポイントは変更ストリームの再開トークンを保存します。デプロイが再起動すると、コネクタは再開トークンを読み取り、oplog.rs コレクション内の対応する位置から続行します。

再開トークンが oplog.rs に存在しなくなった場合 (固定容量のコレクションで、満杯になるとローテーションします)、早期のローテーションを防ぐために oplog サイズを増やしてください。詳細については、「セルフマネージドレプリカセットメンバーの Oplog サイズの変更」をご参照ください。

MongoDB CDC は UPDATE_BEFORE メッセージ (更新前イメージ) をサポートしていますか?

MongoDB のバージョンによって異なります：

• MongoDB 6.0 以降で、事前イメージ/事後イメージが有効な場合：'scan.full-changelog' = 'true' を設定します。MongoDBSource は UPDATE_BEFORE メッセージを直接生成します。

• MongoDB 6.0 より前：oplog.rs コレクションには INSERT、UPDATE、REPLACE、DELETE タイプが含まれますが、UPDATE_BEFORE は含まれません。SQL モードで MongoDBTableSource を使用する場合、Flink プランナーは自動的に ChangelogNormalize オペレータを適用して UPDATE_BEFORE メッセージを生成しますが、このオペレータはすべてのキー状態を保存するためオーバーヘッドが生じます。MongoDBSource で DataStream API を使用する場合 (Flink プランナーの最適化なし)、ChangelogNormalize は自動的に適用されません。状態を自分で管理するか、MongoDBTableSource を使用して変更ログストリームに変換してください。

  tEnv.executeSql("CREATE TABLE orders ( ... ) WITH ( 'connector'='mongodb-cdc', ... )");
  
  Table table = tEnv.from("orders").select($("*"));
  
  tEnv.toChangelogStream(table)
      .print()
      .setParallelism(1);
  
  env.execute();

無効な日付値をフィルタリングするにはどうすればよいですか?

WITH 句に次のいずれかを追加してください：

• 'debezium.event.deserialization.failure.handling.mode' = 'warn'：無効なレコードをスキップし、警告としてログに記録します。

• 'debezium.event.deserialization.failure.handling.mode' = 'ignore'：無効なレコードを黙ってスキップします。

更新時に TOAST データが欠落しているのはなぜですか?

動作は、テーブルの REPLICA IDENTITY 設定によって異なります。

• REPLICA IDENTITY FULL：TOAST 列の値は、変更イベントの before および after フィールドの両方に、他の列と同様に表示されます。

• REPLICA IDENTITY DEFAULT (デフォルト)：変更されていない TOAST 列は UPDATE イベントから省略されます。'debezium.schema.refresh.mode' = 'columns_diff_exclude_unchanged_toast' が使用されている場合、wal2json プラグインは変更されていない TOAST データを省略します。したがって、これらの列は、レプリカアイデンティティが FULL の場合にのみ WAL ログに表示されます。

欠落している TOAST データを修正するには、レプリカアイデンティティを FULL に設定します。

ALTER TABLE your_table_name REPLICA IDENTITY FULL;

WAL ログが解放されず、ディスク使用量が高いのはなぜですか?

PostgreSQL CDC コネクタは、Flink チェックポイントが完了したときにのみ、レプリケーションスロットのログシーケンス番号 (LSN) を更新します。ディスク使用量が高い場合は、次を確認してください：

• デプロイでチェックポイントが有効になっているかどうか。

• 使用されていないレプリケーションスロット、または同期ラグが大きいレプリケーションスロットがあるかどうか。

DECIMAL 精度が宣言された列精度を超えるとどうなりますか?

値は null として返されます。元の値を保持するには、'debezium.decimal.handling.mode' = 'string' を設定して、DECIMAL データを代わりに文字列として読み取るようにします。

PostgreSQL CDC に DataStream API を使用する場合、tableList をどのように設定しますか?

tableList の値には、スキーマ名とテーブル名の両方を my_schema.my_table の形式で含める必要があります。

flink-sql-connector-mysql-cdc-2.2-SNAPSHOT.jar をダウンロードできないのはなぜですか?

SNAPSHOT バージョンは開発ブランチに対応しており、Maven セントラルリポジトリには公開されていません。SNAPSHOT バージョンを使用するにはソースからコンパイルするか、Maven セントラルリポジトリで利用可能な flink-sql-connector-mysql-cdc-2.1.0.jar などの安定版リリースを使用してください。

flink-sql-connector-xxx.jar と flink-connector-xxx.jar の違いは何ですか?

• flink-sql-connector-xxx：コネクタコードとすべてのシェードされた依存関係を含む fat JAR です。SQL デプロイの場合は、lib ディレクトリに追加してください。

• flink-connector-xxx：依存関係を含まない、コネクタコードのみが含まれています。DataStream デプロイに使用し、exclude および shade 操作で競合を解決するなど、サードパーティの依存関係を自分で管理してください。

Maven リポジトリで Flink CDC 2.x コネクタパッケージが見つからないのはなぜですか?

Flink CDC 2.0.0 以降、グループ ID が com.alibaba.ververica から com.ververica に変更されました。2.x パッケージの Maven パスは /com/ververica/ です。

JsonDebeziumDeserializationSchema を使用すると、数値フィールドが文字列として返されます。どのように修正しますか?

ソースを構築する際に、Debezium の数値処理プロパティを設定してください。

Properties properties = new Properties();
properties.setProperty("bigint.unsigned.handling.mode", "long");
properties.setProperty("decimal.handling.mode", "double");

MySqlSource.<String>builder()
    .hostname(config.getHostname())
    // ...
    .debeziumProperties(properties);

Debezium が数値型を変換する方法の詳細については、「Debezium connector for MySQL」をご参照ください。

"Replication slot 'xxxx' is active"

PostgreSQL CDC デプロイが終了した後、そのレプリケーションスロットが自動的に解放されない場合があります。手動で解放してください。

select pg_drop_replication_slot('rep_slot');

スロットがアクティブなプロセスによって保持されている場合は、まずプロセスを終了します。

select pg_terminate_backend(162564);
select pg_drop_replication_slot('rep_slot');

または、PostgreSQL ソース設定に 'debezium.slot.drop.on.stop' = 'true' を追加して、デプロイがキャンセルされたときにスロットを自動的に削除するように設定します。

"binlog probably contains events generated with statement or mixed based replication format"

MySQL CDC ソーステーブルは、 ROW 形式のバイナリログのみをサポートしています。形式が STATEMENT または MIXED の場合、コネクタは失敗します。

1. 現在の形式を確認します：

   show variables like "binlog_format";
   -- グローバル設定を確認するには：
   show global variables like "binlog_format";

2. 形式を ROW に変更してください。詳細については、「バイナリログ形式の設定」をご参照ください。

3. デプロイを再起動してください。

"Encountered change event for table xxx.xxx whose schema isn't known to this connector"

3 つの一般的な原因があります：

• 権限の欠如：アカウントが、デプロイで使用されるすべてのデータベースへのアクセス権を持っていません。必要な権限を付与してください。詳細については、「MySQL データベースの設定」をご参照ください。

• debezium.snapshot.mode を never に設定：バイナリログの最初から読み取ると、そこに記録されているテーブルスキーマが現在のスキーマと一致しない可能性があります。この設定は避けてください。スキーマの不一致を許容するには、'debezium.inconsistent.schema.handling.mode' = 'warn' を追加してください。

• サポートされていない DDL 構文：Debezium は、DEFAULT (now()) などの特定の式を解釈できません。io.debezium.connector.mysql.MySqlSchema WARN ログを確認して、問題のあるステートメントを特定してください。

"The connector is trying to read binlog starting at GTIDs ..., but this is no longer available on the server"

コネクタが必要とするバイナリログファイルが削除されました。一般的な原因と修正方法は次のとおりです：

<table> <thead> <tr> <th><b>原因</b></th> <th><b>修正方法</b></th> </tr> </thead> <tbody> <tr> <td>バイナリログの保持期間が短すぎる</td> <td>保持期間を延長します (例： 7 日間に)： <code>set global expire_logs_days=7;</code></td> </tr> <tr> <td>デプロイがバイナリログを消費するのが遅すぎる (ダウンストリームオペレータでバックプレッシャー)</td> <td>リソース設定を最適化してバックプレッシャーを軽減</td> </tr> <tr> <td>ApsaraDB RDS for MySQL： ログは最大 18 時間、ストレージの最大 30% まで保持される</td> <td>RDS のバイナリログ有効期限ポリシーを調整</td> </tr> <tr> <td>読み取り専用 ApsaraDB RDS for MySQL インスタンス： ローカルバイナリログは Object Storage Service (OSS) にアップロードされる前に最低 10 秒間保持される</td> <td>CDC には読み取り専用インスタンス (ホスト名が <code>rr</code> で始まる) を使用せず、通常のインスタンス (ホスト名が <code>rm</code> で始まる) を使用してください</td> </tr> <tr> <td>RDS インスタンスでの内部データ移行</td> <td>デプロイを再起動してデータを再読み取り</td> </tr> </tbody> </table>

"EventDataDeserializationException: Failed to deserialize data of EventHeaderV4"

MySQL サーバーがアイドル状態のバイナリログ接続を切断しました。net_write_timeout パラメータがこのタイムアウトを制御します (デフォルト： 60 秒)。バックプレッシャーやネットワークの問題により非アクティブな接続は切断されます。

• MySQL CDC ソーステーブル設定に 'debezium.connect.keep.alive.interval.ms' = '40000' を追加するか、データベースで net_write_timeout を増やしてください。詳細については、「インスタンスパラメータの最適化」をご参照ください。

• エラーがバックプレッシャーによって引き起こされている場合は、デプロイのリソース設定を調整してください。

• Ververica Runtime (VVR) 8.0.7 以降では、バックプレッシャーが原因のエラーが発生した場合、自動的に再試行します。

"The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs"

完全データの読み取りに時間がかかりすぎて、完全同期の開始時に記録された GTID 位置が、コネクタがインクリメンタル読み取りに切り替わるまでにサーバーから削除されました。

バイナリログの保持期間または最大ファイルサイズを増やしてください。

mysql> show variables like 'expire_logs_days';
mysql> set global expire_logs_days=7;

"The 'before' field of UPDATE/DELETE message is null"

PostgreSQL テーブルの REPLICA IDENTITY が FULL に設定されていません。次を実行してください：

ALTER TABLE yourTableName REPLICA IDENTITY FULL;

デプロイを再起動してもエラーが解消されない場合は、デプロイコードにそのステートメントを追加します。

"Can't find any matched tables, please check your configured database-name and table-name"

2 つの原因が考えられます：

• テーブル名がデータベースに存在しません。設定されたテーブル名を確認してください。

• アカウントが、デプロイ内の特定のデータベースに対する権限を持っていません。すべてのデータベースに必要な権限を付与してください。

"The primary key is necessary when enable 'scan.incremental.snapshot.enabled'"

このエラーは、VVR 4.0.x で DDL WITH 句に主キーを指定せずに MySQL CDC ソーステーブルを作成した場合に発生します。DDL ステートメントに主キー定義を追加してください。

"java.io.EOFException: SSL peer shut down incorrectly" {#javaioeofe-xception-ssl-peer-shut-down-incorrectly}

MySQL 8.0.27 はデフォルトで SSL 接続を有効にしますが、JDBC ドライバはデフォルト設定では SSL 経由で接続できません。

• VVR 6.0.2 以降を使用している場合は、WITH 句に 'jdbc.properties.useSSL' = 'false' を追加してください。

• テーブルがディメンションテーブルとしてのみ使用される場合は、コネクタを rds に設定し、URL に characterEncoding=utf-8&useSSL=false を追加してください。

  'url' = 'jdbc:mysql://***.***.***.***:3306/test?characterEncoding=utf-8&useSSL=false'

"A slave with the same server_uuid/server_id as this slave has connected to the master"

MySQL CDC ソーステーブルの各並列サブタスクには、一意のサーバー ID が必要です。同じデプロイ内の並列サブタスク、または複数のデプロイ間の並列サブタスクが同じサーバー ID を共有している場合、このエラーが発生します。

各並列サブタスクにグローバルに一意のサーバー ID を指定してください。詳細については、「MySQL CDC ソーステーブルの作成」の「注意事項」セクションをご参照ください。

完全データの読み取り中に列を追加した後に "NullPointerException" が発生する

デプロイは起動時にテーブルスキーマを記録し、チェックポイントに保存します。完全データの読み取り中に列を追加すると、スキーマの不一致が発生し、NullPointerException をトリガーします。

デプロイをキャンセルし、ダウンストリームテーブルを削除して、状態なしでデプロイを再起動してください。

"Mysql8.0 Public Key Retrieval is not allowed"

MySQL ユーザーが SHA256 パスワード認証で設定されており、TLS が必要です。ユーザーをネイティブパスワード認証に切り替えてください。

ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;

"sub account not auth permission"

ApsaraDB RDS for MySQL を CDC ソースとして使用する場合、RAM ユーザーが Object Storage Service (OSS) からバイナリログファイルをダウンロードする権限を持っていません。必要な権限を付与してください。詳細については、「バックアップファイルをダウンロードするための読み取り専用権限を持つ RAM ユーザーの承認」をご参照ください。

"DELETE command denied to user 'userName'@'\....' for table 'table_name'"

WHERE 句が CDC データストリームをフィルタリングする場合、Realtime Compute for Apache Flink は各 UPDATE 操作に対して BEFORE UPDATE および AFTER UPDATE レコードの両方を出力します。ダウンストリームシンクは BEFORE UPDATE レコードを DELETE として扱います。シンクテーブルで操作を実行するデータベースユーザーに DELETE 権限を付与してください。