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 から完全データと増分データを読み取ります。ディメンションテーブルまたはシンクテーブルのユースケースでは、 (CDC ではなく) 通常の MySQL テーブルを使用してください。

MySQL CDC コネクタが完全データの読み取り後に停止し、増分モードに移行しない原因

通常、以下の4つの原因が考えられます：

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

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

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

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

完全データ同期の完了を確認する方法

2つの方法があります：

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

  

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

  4123  2022-01-12 05:12:52,157 [pool-6757-thread-1] INFO  io.debezium.jdbc.JdbcConnection                    [] - Connection gracefully close...
  4124  2022-01-12 05:12:52,158 [Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job vertex id
           6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO  org.apache.flink.connector.base.source.reader.SourceReaderBase [] - Adding split(s) to reader:
           [MySqlBinlogSplit{splitId='binlog-split', offset={ts_sec=0, file=mysql-bin.008066, pos=459422339,
           gtids=c32c3579-5c0d-11ec-889a-00163e368abf:1-311125098, row=0, event=0}, endOffset={ts_sec=0, file=, pos=-9223372036854775808, row=0, event=0}}]
  4125  2022-01-12 05:12:52,158 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job
           vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO  org.apache.flink.connector.base.source.reader.fetcher.SplitFetcher [] - Starting split
           fetcher_138?
  4126  2022-01-12 05:12:52,159 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job
           vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO  com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader [] - BinlogSplitReader
           is created.
  4127  2022-01-12 05:12:56,853 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job
           vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] WARN  io.debezium.relational.history.DatabaseHistoryMetrics          [] - Unable to register the
           MBean 'debezium.mysql:type=connector-metrics,context=schema-history,server=mysql_binlog_source': debezium.mysql:type=connector-metrics,
           context=schema-history,server=mysql_binlog_source
  4128  2022-01-12 05:12:56,860 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job

  4126 行目に BinlogSplitReader is created と表示されており、これは完全データの読み取りが完了し、デプロイが増分バイナリログの読み取りに移行したことを示します。4127 行目の WARN ログ (Unable to register the MBean) は正常であり、データ同期には影響しません。

デプロイの再起動による開始位置の変更

これは、[Deployment Starting Configuration] ダイアログボックスで選択する [起動ストラテジー] によって異なります：

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

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

たとえば、デプロイが {file=mysql-bin.01, position=40} で開始するように設定されていても、位置 210 でキャンセルされた場合、[最新のステート] では 210 から再開し、[NONE] では 40 から読み取りを再開します。

MySQL CDC コネクタの仕組みとデータベースへの影響

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

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

2. 完全データの読み取り後、binlog クライアントに切り替えて、記録された位置から増分変更を読み取ります。

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

show variables like '%max_connections%';

スナップショットフェーズをスキップした変更データのみの読み取り

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

scan.startup.mode = timestamp の場合における binlog 位置の特定

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

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

2. そのファイルの先頭から binlog イベントを読み取ります。

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

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

境界条件：

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

• 指定されたタイムスタンプに対応する binlog がすでにパージされている場合、読み取りは利用可能な最も古い位置から開始されます。これは earliest-offset と同等です。

シャーディングされた MySQL テーブルの処理

table-name パラメーターと正規表現を使用して、すべてのシャードにマッチさせます。たとえば、接頭辞が user_ のすべてのテーブルを監視するには、次のようにします：

'table-name' = 'user_.*'

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

table-name の正規表現に含まれるコンマによる解析エラーへの対処

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

13-vvr-4.0.13-1-SNAPSHOT.jar:1.13-vvr-4.0.13-1-SNAPSHOT]
Caused by: java.util.regex.PatternSyntaxException: Unclosed counted closure near index 35
zhangtest.t_process_wi_history_\d{1
	at java.util.regex.Pattern.error(Pattern.java:1969) ~[?:1.8.0_302]
	at java.util.regex.Pattern.closure(Pattern.java:3155) ~[?:1.8.0_302]

代わりに選択 (alternation) を使用してください：

'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 ソーステーブルを再利用して、複数のデプロイが単一の binlog 接続を共有するようにします。「MySQL コネクタ」の「MySQL CDC ソーステーブルの再利用の有効化」セクションをご参照ください。

タイムスタンプフィールドが MySQL サーバーのタイムゾーンと比較して 8 時間ずれる原因

考えられる原因は2つあります：

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

• カスタムデシリアライザー (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();
// 後続の処理ロジックを追加

データベース内の全テーブルの一括同期のサポート

はい。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             |
+------------------+----------+--------------+------------------+----------------------+

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

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

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

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

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 $changestage 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 のバージョンによって異なります。

• pre-image/post-image が有効な 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 メッセージを生成しますが、このオペレーターはすべてのキーステートを格納するため、オーバーヘッドが増加します。DataStream API と MongoDBSource を (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 Central リポジトリには公開されていません。SNAPSHOT バージョンを使用する場合は、ソースからコンパイルするか、Maven Central リポジトリで入手可能な 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 に変更します。「Setting the binary log format」をご参照ください。

3. デプロイメントを再起動します。

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

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

• 権限の不足：アカウントに、デプロイメントで使用されるすべてのデータベースへのアクセス権がありません。必要な権限を付与してください。「Configure a MySQL database」をご参照ください。

• 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"

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

"EventDataDeserializationException: Failed to deserialize data of EventHeaderV4"

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

• MySQL CDC ソーステーブルの設定に 'debezium.connect.keep.alive.interval.ms' = '40000' を追加するか、データベースの net_write_timeout を増やしてください。「Optimize instance parameters」をご参照ください。

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

• 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'"

このエラーは、MySQL CDC ソーステーブルが DDL WITH 句にプライマリキーなしで作成された場合に、VVR 4.0.x で発生します。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 を指定してください。詳細については、「Create a MySQL CDC source table」の「Precautions」セクションをご参照ください。

"NullPointerException" after adding a column during full data reading

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

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

"MySQL 8.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) からバイナリログファイルをダウンロードする権限がありません。必要な権限を付与してください。「Authorize a RAM user with read-only permissions to download backup files」をご参照ください。

"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 権限を付与してください。