Realtime Compute for Apache Flink：CDC問題

Flink CDC作業失敗後能不能徹底退出，而不是重啟？

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

MySQL/Hologres CDC源表不支援視窗函數，如何?類似每分鐘彙總統計的需求?

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表只能作為Source嗎？

是的。MySQL CDC源表可以讀取MySQL資料庫表中的全量和增量資料，只能作為Source使用。而MySQL表可以用作維表或者結果表。

MySQL CDC讀取全量資料後，不讀增量資料是為什嗎？

MySQL CDC使用table-nameRegex不能解析逗號，怎麼辦？

• 報錯原因

  例如配置'table-name' = 't_process_wi_history_\d{1,2}'，報錯如下。

• 報錯原因

  Debezium使用逗號作為分隔字元，不支援帶逗號的Regex，所以解析會報錯。

• 解決方案

  建議您使用'table-name' = '(t_process_wi_history_\d{1}|t_process_wi_history_\d{2})'進行配置。

作業重啟時，MySQL CDC源表會從作業停止時的位置消費，還是從作業配置的位置重新消費？

作業重啟時，您可以自由選擇啟動策略。如果選擇全新啟動，MySQL CDC源表會從配置的位置重新消費。如果選擇從最新狀態恢複，MySQL CDC源表會從作業停止時的位置開始消費。

比如，作業配置為從Binlog位點{file=mysql-bin.01， position=40}啟動作業，作業運行一段時間後停止，此時消費到Binlog位點{file=mysql-bin.01， position=210}。如果選擇全新啟動，MySQL CDC源表會重新從Binlog位點{file=mysql-bin.01， position=40}消費。如果選擇從最新狀態恢複，則會從Binlog位點{file=mysql-bin.01， position=210}開始消費。

MySQL CDC源表如何工作，會對資料庫造成什麼影響？

在啟動模式為initial（預設值）時，MySQL CDC源表會先通過JDBC串連MySQL，使用SELECT語句讀取全量的資料，並記錄Binlog的位點。全量階段結束後，再從屬記錄的位點開始讀取Binlog中的增量資料。

show variables like '%max_connections%';

如何跳過Snapshot階段，只從變更資料開始讀取？

可以通過WITH參數scan.startup.mode來控制，您可以指定從最早可用的Binlog位點消費、從最新的Binlog位點消費、指定時間戳記消費或指定具體的Binlog位點消費，詳情可參見WITH參數：scan.startup.mode。

如何讀取一個分庫分表的MySQL資料庫？

如果MySQL是一個分庫分表的資料庫，分成了user_00、user_02和user_99等多個表，且所有表的schema一致。則可以通過table-name選項，指定一個Regex來匹配讀取多張表，例如設定table-name為user_.*，監控所有user_首碼的表。database-name選項也支援該功能，但需要所有的表schema一致。

全表讀取階段效率慢、存在反壓，應該如何解決？

如何判斷MySQL CDC作業是否已完成全量資料同步？

• 您可以通過資料曲線頁面currentEmitEventTimeLag指標來判斷作業是否完成了全量資料同步。

  currentEmitEventTimeLag指標記錄的是Source發送一條記錄到下遊節點的時間點和該記錄在資料庫中產生時間點的差值，用于衡量資料從資料庫中產生到離開Source節點的延遲。

  currentEmitEventTimeLag指標取值含義如下：

  • 當該指標小於等於0時，則代表作業還在全量資料同步階段。

  • 當該指標大於0時，則代表作業完成了全量資料同步，進入了Binlog讀取階段。

• 在MySQL CDC源表所在的TM日誌中排查是否有BinlogSplitReader is created日誌來判斷是否讀取完了全量資料，例如下圖所示。

  

多個CDC作業導致資料庫壓力過大怎麼辦？

MySQL CDC源表需要串連資料庫讀取Binlog，當源表數量逐漸增加，資料庫壓力也會逐漸增加。為瞭解決資料庫壓力過大的問題，可以考慮通過將表同步到Kafka訊息佇列中，再通過消費Kafka中資料進行解耦。詳情請參見MySQL整庫同步Kafka。

如果是通過CTAS方式同步資料導致的資料庫壓力過大，可以將多個CTAS作業合并為一個作業運行。在配置相同的情況下，為每一個MySQL CDC源表配置相同Server ID，可以實現資料來源的複用，從而減小資料庫的壓力。詳情請參見程式碼範例四：多CTAS語句。

使用MySQL CDC，為什麼資料量不大，但是flink讀取時候消耗了大量頻寬？

• 問題詳情

  MySQL的源表資料更新量不大，但是Flink在讀取資料時消耗了大量的頻寬。

• 問題原因

  在MySQL中，Binlog是整個執行個體層級的，因此它會記錄所有資料庫和所有表的變更。也就是說，如果您的MySQL資料庫下有三張表，即使Flink作業只涉及其中一張表的變更，Binlog也會包含這三張表的所有變更記錄。

  使用Flink CDC時，雖然底層Binlog包含整個MySQL執行個體的所有變更資料，Flink CDC可以通過配置只過濾並讀取特定表的變更記錄。這個過濾過程是在Debezium或Flink CDC連接器層面完成的，而不是在MySQL層面完成的。

• 解決方案

  雖然無法解決Binlog的資料變更儲存機制，但是可以通過Source複用避免更多的頻寬使用，詳情請參考開啟CDC Source複用。

使用MySQL CDC，增量階段讀取出來的timestamp欄位時區相差8小時，怎麼回事呢？

• 在解析Binlog資料中的timestamp欄位時，CDC作業裡配置server-time-zone參數，如果這個參數沒有和您的MySQL伺服器時區一致，就會出現這個問題。

• 在DataStream中使用了自訂序列化器，例如MyDeserializer implements DebeziumDeserializationSchema。當自訂序列化器解析timestamp類型的資料時，出現該問題。可以參考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支援監聽從庫嗎？從庫需要如何配置？

是的，為了支援MySQL CDC監聽從庫，需要對從庫進行如下配置。配置完成後，從庫在接收主庫同步過來的資料時，會將這些資料寫入從庫自身的Binlog檔案中。

log-slave-updates = 1

如果主庫啟用了GTID模式，那麼從庫也必須啟用GTID模式。對主從庫進行如下配置。

gtid_mode = on
enforce_gtid_consistency = on

怎麼擷取資料庫中的DDL事件？

使用社區版本的CDC連接器時，您可以通過DataStream API使用MySqlSource，配置includeSchemaChanges(true)參數來擷取DDL事件。擷取到DDL事件後，再編寫相應的代碼進行後續處理。程式碼範例如下。

MySqlSource<xxx> mySqlSource =
 MySqlSource.<xxx>builder()
 .hostname(...)
 .port(...)
 .databaseList("<databaseName>")
 .tableList("<databaseName>.<tableName>")
 .username(...)
 .password(...)
 .serverId(...)
 .deserializer(...)
 .includeSchemaChanges(true) // 配置擷取DDL事件的參數
 .build();
 ... // 其他處理邏輯 

Flink CDC支援MySQL整庫同步嗎？怎麼做？

支援的，Realtime ComputeFlink版提供了CTAS或CDAS文法來支援整庫同步，詳情請參見CREATE TABLE AS（CTAS）語句或CREATE DATABASE AS（CDAS）語句。

同一個執行個體下，某個庫的表無法同步增量資料，其他庫都可以，為什嗎？

因為MySQL伺服器可以配置Binlog過濾器，忽略了某些庫的Binlog。您可以通過show master status命令查看Binlog_Ignore_DB和Binlog_Do_DB。查看結果樣本如下。

mysql> show master status;
+------------------+----------+--------------+------------------+----------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |  Executed_Gtid_Set   |
+------------------+----------+--------------+------------------+----------------------+
| mysql-bin.000006 |     4594 |              |                  | xxx:1-15             |
+------------------+----------+--------------+------------------+----------------------+

使用DataStream API構建MySQL CDC Source時如何配置tableList選項？

tableList要求表名包含資料庫名，而不是DataStream API中的表名。對於MySQL CDC Source，可以配置tableList("yourDatabaseName.yourTableName")參數。​

MongoDB CDC全量讀取階段，作業失敗後，可以從checkpoint繼續讀取嗎？

在WITH參數中配置'scan.incremental.snapshot.enabled'= 'true'參數，可以從checkpoint恢複讀取資料。

MongoDB CDC支援全量+增量讀和唯讀增量嗎？

支援，預設為全量+增量讀取；在WITH參數中配置'scan.startup.mode' = 'latest-offset'參數將讀取資料模式變為唯讀增量。

MongoDB CDC支援訂閱多個集合嗎？

僅支援訂閱整個庫的集合，不支援篩選部分集合功能。例如，在WITH參數中設定'database' = 'mgdb'，並且'collection' = ''，則表示會訂閱mgdb資料庫下的所有集合。

MongoDB CDC支援設定多並發度讀取嗎？

如果啟用了scan.incremental.snapshot.enabled配置，則在初始快照集階段將支援並發讀取。

MongoDB CDC支援的MongoDB版本是哪些？

MongoDB CDC基於Change Stream特性實現，Change Stream是MongoDB 3.6新增的特性。MongoDB CDC理論上支援3.6及更高的版本，建議使用版本>=4.0。如果在低於3.6的版本上運行，可能會出現錯誤Unrecognized pipeline stage name: '$changeStream'。

MongoDB CDC支援的MongoDB運行模式是什麼樣的？

Change Stream需要MongoDB在複本集或分區叢集架構下運行，在本地測試時，可以使用單節點複本集架構，通過執行rs.initiate()命令來初始化。但需要注意，在單節點架構下執行CDC可能會出現錯誤The $changestage is only supported on replica sets。

MongoDB CDC是否支援Debezium相關的參數？

不支援的，因為MongoDB CDC連接器是在Flink CDC專案中獨立開發，並不依賴Debezium專案。

其他組件可以成功使用相同的使用者名稱和密碼進行串連，為何MongoDB CDC會報錯並提示使用者名稱密碼錯誤？

因為該使用者憑證是在所需串連的資料庫下建立的。如果需要正常訪問，需要在WITH參數裡添加 'connection.options' = 'authSource=使用者所在的DB'。

MongoDB CDC支援從Checkpoint恢複嗎？原理是怎麼樣的呢？

支援，checkpoint會記錄Change Stream的Resume Token，可以通過Resume Token重新恢複Change Stream。其中Resume Token對應oplog.rs（MongoDB變更日誌集合）的位置，oplog.rs是一個固定容量的集合。

當Resume Token對應的記錄在oplog.rs中不存在時，可能會出現無效Resume Token的異常，您可以設定合適oplog.rs的集合大小，避免oplog.rs保留時間過短，詳情請參見更改Oplog的大小。

另外，新達到的變更記錄和心跳記錄可以重新整理Resume Token。

MongoDB CDC支援輸出-U（update_before，更新前鏡像值）訊息嗎？

• 在MongoDB  6.0及以上版本中，若資料庫開啟了前像或後像功能，您可以在SQL作業中配置參數'scan.full-changelog' = 'true'，使得資料來源能夠輸出-U訊息，從而省去ChangelogNormalize。

• 在MongoDB 6.0以下版本中，由於MongoDB原始的oplog.rs包含INSERT、UPDATE、REPLACE和DELETE這四種操作類型，沒有保留更新前的資訊，因此無法直接輸出-U類型訊息。在Flink中，只能實現基於update的語義。使用MongoDBTableSource時，Flink planner會自動進行ChangelogNormalize最佳化，補齊缺失的-U訊息，輸出完整的+I、 -U、+U、-D四種訊息，ChangelogNormalize最佳化的代價是該節點會儲存之前所有key的狀態。如果是DataStream作業直接使用MongoDBSource，沒有Flink planner的最佳化，將不會自動進行ChangelogNormalize最佳化，所以不能直接擷取-U訊息。若想要擷取更新前鏡像值，您需要自己管理狀態。如果不希望自己管理狀態，您可以將MongoDBTableSource中原始的oplog.rs轉換為ChangelogStream或者RetractStream，並藉助Flink planner的最佳化能力補齊更新前的鏡像值，樣本如下。

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

如何配置參數以過濾作業中的非法日期髒資料？

可以在Postgres CDC的WITH參數中配置如下參數來過濾髒資料。

• 配置'debezium.event.deserialization.failure.handling.mode'='warn'參數，跳過髒資料，將髒資料列印到WARN日誌裡。

• 配置'debezium.event.deserialization.failure.handling.mode'='ignore'參數，跳過髒資料，不列印髒資料到日誌。

Postgres CDC提示未傳輸TOAST資料，是什麼原因？

請確保副本身份是完整的。TOAST資料相對較大，為了節省WAL的大小，如果TOAST資料沒有發生變化，您配置了'debezium.schema.refresh.mode'='columns_diff_exclude_unchanged_toast'參數，wal2json外掛程式不會將TOAST資料帶到更新後的資料中。

發現PG伺服器磁碟使用率高，WAL日誌不釋放是什麼原因？

Postgres CDC只會在checkpoint完成的時候更新Postgres slot中的LSN。如果發現磁碟使用率高的情況下，請先確認Postgres的checkpoint是否開啟並查看資料庫是否有其他未使用或同步延遲的slot。

Postgres CDC同步Postgres中DECIMAL類型資料精度超過最大精度時，會返回什麼結果？

Postgres CDC中如果收到DECIMAL類型資料的精度大於在Postgres CDC中聲明的類型的精度時，會將資料處理成NULL。此時，您可以配置'debezium.decimal.handling.mode' = 'string'參數，將讀取的資料用字串類型來進行處理。

在DataStream API中構建Postgres CDC Source時如何配置tableList選項？

tableList要求表名使用模式名，而不是DataStream API中的表名。對於Postgres CDC Source，tableList選項值為my_schema.my_table。

為什麼無法下載flink-sql-connector-mysql-cdc-2.2-SNAPSHOT.jar，Maven倉庫為什麼沒有xxx-SNAPSHOT依賴？

和主流的Maven專案版本管理相同，xxx-SNAPSHOT版本對應開發分支的代碼。如果需要使用這個版本，您需要下載源碼並編譯對應的JAR。您可以使用穩定版本，例如flink-sql-connector-mysql-cdc-2.1.0.jar，可以直接從Maven中心倉庫中擷取並使用。

使用flink-sql-connector-xxx.jar和使用flink-connector-xxx.jar有什麼區別?

Flink CDC各個連接器的包命名規則和Flink其他連接器的包命名規則是保持一致的。

• flink-sql-connector-xx是FAT JAR，除了連接器的代碼外，還將連接器依賴的所有第三方包shade後打入FAT JAR，提供給SQL作業使用，您只需要在lib目錄下添加該FAT JAR即可。

• flink-connector-xx只包含該連接器的代碼，不包含其所需的依賴，供DataStream作業使用，您需要自己管理所需的第三方包依賴，有衝突的依賴需要進行exclude和shade處理。

為什麼Maven倉庫裡找不到2.x版本？

Flink CDC專案從2.0.0版本將group id從com.alibaba.ververica改成com.ververica，所以在Maven倉庫找2.x版本的包時，路徑是/com/ververica。

DataStream API使用JsonDebeziumDeserializationSchema還原序列化器時，數實值型別顯示是一堆字串，怎麼辦？

因為Debezium在解析數實值型別時有不同的轉換方式，詳情請參見Debezium connector for MySQL。在Flink CDC配置的轉碼如下。

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);

報錯：Replication slot "xxxx" is active

• 報錯詳情

  當您的Postgres CDC作業結束後，可能會遇到slot未被正確釋放的情況。

• 解決方案

  您可以採用以下兩種方法釋放slot：

  • 在PostgreSQL中執行以下命令手動釋放slot。

    select pg_drop_replication_slot('rep_slot');

    如果遇到錯誤“ERROR: replication slot "rep_slot" is active for PID 162564”，則表示slot正在被進程（PID）佔用。您需要先終止該進程，再釋放slot。釋放命令如下所示。

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

  • 自動清理slot。在作業的Postgres Source配置中添加'debezium.slot.drop.on.stop' = 'true'參數，確保當CDC作業停止時，slot會被自動清理。

    警告

    如果開啟自動清理slot,  會導致Wal Log被回收，當作業再次啟動時，會導致資料丟失，無法保證At-Least Once語義。

報錯：Lock wait timeout exceeded; try restarting transaction

• 報錯詳情

  org.apache.kafka.connect.errors.ConnectException: Lock wait timeout exceeded; try restarting transaction Error code: 1205; SQLSTATE: 40001.
      at io.debezium.connector.mysql.AbstractReader.wrap(AbstractReader.java:241)
      at io.debezium.connector.mysql.AbstractReader.failed(AbstractReader.java:218)
      at io.debezium.connector.mysql.SnapshotReader.execute(SnapshotReader.java:857)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1147)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
      at java.lang.Thread.run(Thread.java:834)
  Caused by: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
      at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:123)
      at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
      at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
      at com.mysql.cj.jdbc.StatementImpl.executeQuery(StatementImpl.java:1200)
      at io.debezium.jdbc.JdbcConnection.query(JdbcConnection.java:554)
      at io.debezium.jdbc.JdbcConnection.query(JdbcConnection.java:497)
      at io.debezium.connector.mysql.SnapshotReader.readTableSchema(SnapshotReader.java:888)
      at io.debezium.connector.mysql.SnapshotReader.execute(SnapshotReader.java:550)
      ... 3 more

• 報錯原因

  當MySQL CDC源表不開啟增量快照讀取時，申請鎖時可能發生的逾時錯誤。

• 解決方案

  升級到VVR 4.0.8及以上版本即可，新版本預設使用無鎖演算法，不需要申請鎖。

報錯：Cause by：java.lang.ArrayIndexOutOfBoundsException

• 報錯詳情

• 報錯原因

  VVR 4.0.12以下版本依賴的Binlog讀取工具存在問題，導致報錯。

• 解決方案

  VVR 4.0.12及以上版本已修複此問題，建議升級版本解決。

報錯：Caused by: io.debezium.DebeziumException: Received DML 'xxx' for processing, binlog probably contains events generated with statement or mixed based replication format

• 報錯詳情

  Caused by: io.debezium.DebeziumException: Received DML 'insert into gd_chat_fetch_log (
  
  id,
  c_cursor,
  d_timestamp,
  msg_cnt,
  state,
  ext1,
  ext2,
  cost_time
  
  ) values (
  null,
  null,
  '2022-03-23 16:51:00.616',
  0,
  1,
  null,
  null,
  0
  )' for processing, binlog probably contains events generated with statement or mixed based replication format

• 報錯原因

  Binlog格式是Mixed導致報錯。MySQL CDC源表要求Binlog的格式為ROW。

• 解決方案

  1. 使用show global variables like "binlog_format"命令，查看Binlog的格式。

     說明

     該show variables like "binlog_format"命令只能查看當前的Binlog格式，具有局限性。

  2. 如果Binlog格式不是ROW，您需要在MySQL Server端將Binlog格式修改為ROW。詳情請參見Setting The Binary Log Format。

  3. 重啟作業。

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

• 報錯詳情

  202x-xx-xx xx:xx:xx,xxx ERROR io.debezium.connector.mysql.BinlogReader                     [] - Encountered change event 'Event{header=EventHeaderV4{timestamp=xxx, eventType=TABLE_MAP, serverId=xxx, headerLength=xxx, dataLength=xxx, nextPosition=xxx, flags=xxx}, data=TableMapEventData{tableId=xxx, database='xxx', table='xxx', columnTypes=xxx, xxx..., columnMetadata=xxx,xxx..., columnNullability={xxx,xxx...}, eventMetadata=null}}' at offset {ts_sec=xxx, file=mysql-bin.xxx, pos=xxx, gtids=xxx, server_id=xxx, event=xxx} for table xxx.xxx whose schema isn't known to this connector. One possible cause is an incomplete database history topic. Take a new snapshot in this case.
  Use the mysqlbinlog tool to view the problematic event: mysqlbinlog --start-position=30946 --stop-position=31028 --verbose mysql-bin.004419
  202x-xx-xx xx:xx:xx,xxx ERROR io.debezium.connector.mysql.BinlogReader                     [] - Error during binlog processing. Last offset stored = null, binlog reader near position = mysql-bin.xxx/xxx
  202x-xx-xx xx:xx:xx,xxx ERROR io.debezium.connector.mysql.BinlogReader                     [] - Failed due to error: Error processing binlog event
  org.apache.kafka.connect.errors.ConnectException: Encountered change event for table statistic.apk_info whose schema isn't known to this connector
      at io.debezium.connector.mysql.AbstractReader.wrap(AbstractReader.java:241) ~[ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at io.debezium.connector.mysql.AbstractReader.failed(AbstractReader.java:218) ~[ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at io.debezium.connector.mysql.BinlogReader.handleEvent(BinlogReader.java:607) ~[ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.notifyEventListeners(BinaryLogClient.java:1104) [ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:955) [ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:595) [ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:839) [ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at java.lang.Thread.run(Thread.java:834) [?:1.8.0_102]
  Caused by: org.apache.kafka.connect.errors.ConnectException: Encountered change event for table xxx.xxx whose schema isn't known to this connector
      at io.debezium.connector.mysql.BinlogReader.informAboutUnknownTableIfRequired(BinlogReader.java:875) ~[ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at io.debezium.connector.mysql.BinlogReader.handleUpdateTableMetadata(BinlogReader.java:849) ~[ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      at io.debezium.connector.mysql.BinlogReader.handleEvent(BinlogReader.java:590) ~[ververica-connector-mysql-1.12-vvr-3.0.0-SNAPSHOT-jar-with-dependencies.jar:1.12-vvr-3.0.0-SNAPSHOT]
      ... 5 more

• 報錯原因

  • 當作業中使用的某些資料庫，您沒有其對應的某些許可權時，可能出現該錯誤。

  • 當使用了'debezium.snapshot.mode'='never'時，可能出現該錯誤。因為這會導致從Binlog開頭讀取資料，但是Binlog開頭的變更事件對應的Table Schema和當前表的Schema可能不匹配，所以會報該錯誤。

  • 遇到Debezium解析不了的變更，例如Debezium無法解析`DEFAULT (now())`，可能出現該錯誤。

• 解決方案

  • 先確認您使用的資料庫使用者是否有對應作業中全部資料庫的相應許可權，詳細授權操作請參見配置MySQL。

  • 不建議使用'debezium.snapshot.mode'='never'，可以通過'debezium.inconsistent.schema.handling.mode' = 'warn'參數避免報錯。

  • 繼續觀察日誌，查詢io.debezium.connector.mysql.MySqlSchema WARN的log，會列印出具體無法解析的變更詳情，例如Debezium解析不了`DEFAULT (now())`。

報錯：org.apache.kafka.connect.errors.DataException: xxx is not a valid field name

• 報錯詳情

  org.apache.kafka.connect.errors.DataException: xxx is not a valid field name
      at org.apache.kafka.connect.data.Struct.lookupField(Struct.java:254)
      at org.apache.kafka.connect.data.Struct.get(Struct.java:74)
      at com.alibaba.ververica.cdc.debezium.table.RowDataDebeziumDeserializeSchema.lambdaşcreateRowConverter$508c5858$1(RowDataDebeziumDeserializeSchema.java:369)
      at com.alibaba.ververica.cdc.debezium.table.RowDataDebeziumDeserializeSchema.lambdaşwrapIntoNullableConverter$7b91dc26$1(RowDataDebeziumDeserializeSchema.java:394)
      at com.alibaba.ververica.cdc.debezium.table.RowDataDebeziumDeserializeSchema.extractAfterRow(RowDataDebeziumDeserializeSchema.java:127) 
      at com.alibaba.ververica.cdc.debezium.table.RowDataDebeziumDeserializeSchema.deserialize(RowDataDebeziumDeserializeSchema.java:102)
      at com.alibaba.ververica.cdc.debezium.internal.DebeziumChangeConsumer.handleBatch(DebeziumChangeConsumer.java:124)
      at io.debezium.embedded.ConvertingEngineBuilder.lambdaşnotifying$2(ConvertingEngineBuilder.java:82) 
      at io.debezium.embedded.EmbeddedEngine.run(EmbeddedEngine.java:812) 
      at io.debezium.embedded.ConvertingEngineBuilder$2.run(ConvertingEngineBuilder.java:171)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1147)
      at java.util.concurrent.ThreadPoolExecutorsWorker.run ThreadPoolExecutor.java:622) 
      at java.lang.Thread.run(Thread.java: 834)

• 報錯原因

  分庫分表中的某張物理表缺少了您在MySQL CDC表中定義的欄位，導致Schema不一致。

  例如您使用Regexmydb.users_\d{3}去監控mydb資料庫下users_001，users_002，……，users_999這些表，您在MySQL CDC表的DDL中聲明了user_name欄位，但如果users_002表中無user_name欄位，在解析到users_002表的Binlog時就會出現該異常。

• 解決方案

  針對分庫分表情境，分庫分表裡的每個表中必須包含MySQL CDC DDL中聲明的欄位。

  此外，您也可以將作業升級到VVR 6.0.2及以上版本，VVR 6.0.2及以上版本的MySQL CDC會自動使用分庫分表中最寬的Schema解決該問題。

報錯：Caused by: java.sql.SQLSyntaxErrorException: Unknown storage engine 'BLACKHOLE'

• 報錯詳情

• 報錯原因

  在解析MySQL 5.6的DDL時，存在不支援的文法導致報錯。

• 解決方案

  • 您可以在MySQL CDC表的WITH參數中加上'debezium.database.history.store.only.monitored.tables.ddl'='true'和'debezium.database.exclude.list'='mysql'兩個參數來避免報錯。

  • 您也可以將作業升級到VVR 6.0.2及以上版本，VVR 6.0.2及以上版本的MySQL CDC對DDL解析提供了更好的支援。

報錯：Caused by: org.apache.kafka.connect.errors.ConnectException: The connector is trying to read binlog starting at GTIDs ..., but this is no longer available on the server. Reconfigure the connector to use a snapshot when needed.

• 報錯詳情

  org.apache.kafka.connect.errors.ConnectException: The connector is trying to read binlog starting at GTIDs xxx and binlog file 'binlog.000064', pos=89887992, skipping 4 events plus 1 rows, but this is no longer available on the server. Reconfigure the connector to use a snapshot when needed
      at io.debezium.connector.mysql.MySqlConnectorTask.start(MySqlConnectorTask.java:133)
      at io.debezium.connector.common. BaseSourceTask.start (BaseSourceTask.java:106) 
      at io.debezium.embedded.EmbeddedEngine.run (EmbeddedEngine.java:758) 
      at io.debezium.embedded.ConvertingEngineBuilder$2.run(ConvertingEngineBuilder.java:171)
      at java.util.concurrent.ThreadPoolExecutor. runWorker(ThreadPoolExecutor.java:1147)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
      at java.lang.Thread.run(Thread.java:834)

• 報錯原因和解決方案

  報錯原因	解決方案
  作業正在讀取的Binlog檔案在MySQL伺服器已經被清理掉時，會出現該報錯。這種情況一般由於MySQL伺服器上Binlog的保留時間太短。	可以將Binlog的保留時間調大，比如7天。具體命令如下。 show variables like 'expire_logs_days'; set global expire_logs_days=7;
  MySQL CDC作業消費Binlog太慢，例如下遊的彙總運算元或者Sink運算元長時間出現反壓，反壓傳遞到source，導致source無法消費資料。	需要對作業資源調優，讓source恢複正常消費即可。
  阿里雲RDS MySQL的日誌保留原則一般有兩個條件：最長18個小時，最大佔用30%儲存空間。兩個條件滿足任何一個都會觸發清理刪除，如果寫入較多導致超過30%的儲存空間，可能導致Binlog清理而不可用。	需要調整RDS MySQL的Binlog到期策略，使得Binlog能正常被讀取。
  通過唯讀執行個體消費CDC資料時，RDS的唯讀執行個體不保證Binlog可用（本地最短可能只保留10秒，然後上傳OSS）。如果配置讀取唯讀執行個體，一旦作業Failover 10s內無法恢複，就會發生報錯。	不建議MySQL CDC源表讀取RDS的唯讀執行個體資料。 說明 是否是唯讀執行個體可以通過hostname區分，hostname為rr開頭的是唯讀執行個體，rm開頭的是正常的執行個體。
  RDS MySQL發生了內部遷移操作，導致報錯。	需要全新啟動作業，以重新讀取資料。

報錯：EventDataDeserializationException: Failed to deserialize data of EventHeaderV4.... Caused by: java.net.SocketException: Connection reset

• 報錯詳情

  EventDataDeserializationException: Failed to deserialize data of EventHeaderV4 .... Caused by: java.net.SocketException: Connection reset
      at com.github.shyiko.mysql.binlog.event.deserialization.EventDeserializer.deserializeEventData(EventDeserializer.java:304)
      at com.github.shyiko.mysql.binlog.event.deserialization.EventDeserializer.nextEvent(EventDeserializer.java:227)
      at io.debezium.connector.mysql.BinlogReader$1.nextEvent(BinlogReader.java:252)
      at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:934)
  ... 3 more
  Caused by: java.io.EOFException
      at com.github.shyiko.mysql.binlog.io.ByteArrayInputStream.read (ByteArrayInputStream.java:192)
      at java.io.InputSt ream.read (InputStream.java:170)
      at java.io.InputSt ream.skip (InputStream.java:224)
      at com.github.shyiko.mysql.binlog.event.deserialization.EventDeserializer.deserializeEventData(EventDeserializer.java:301)
  ...    6 more

• 報錯原因

  • 網路問題導致。

  • 作業反壓導致。

    當Flink作業存在反壓時，CDC Source中使用的Binlog Client會因為反壓的存在而無法繼續讀取資料。為了盡量減少資料庫上殘留的串連數，MySQL當某個Binlog Client串連不活躍時間超過資料庫上配置的逾時時間之後，會自動切斷串連，導致作業異常。

• 解決方案

  • 如果是網路問題導致的，可以嘗試在CDC Source上增加配置'debezium.connect.keep.alive.interval.ms' = '40000'來解決。

  • 如果是作業反壓問題導致的，需要調節作業解決反壓問題。

  • Realtime Compute引擎8.0.7及以上版本增加了該異常的重試，可以嘗試使用Realtime Compute引擎8.0.7及以上版本運行作業。

報錯：The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

• 報錯詳情

  org.apache.kafka.connect.errors.ConnectException: The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDS that the slave requires. Error code: 1236; SQLSTATE: HY000.
      at io.debezium.connector.mysql.AbstractReader.wrap(AbstractReader.java:241) 
      at io.debezium.connector.mysql.AbstractReader.failed(AbstractReader.java:207) 
      at io.debezium.connector.mysql.BinlogReadersReaderThreadLifecycleListener.onCommunicationFailure(BinlogReader.java:1142) 
      at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:962)
      at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:595)
      at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:839)
      at java.lang.Thread.run(Thread. java:834)
  Caused by: com.github.shyiko.mysql. binlog.network.ServerException: The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.
      at com.github.shyiko.mysql.binlog. BinaryLogClient.listenForEventPackets(BinaryLogClient.java:926) 
  ... 3 more

• 報錯原因

  全量階段讀取時間過長，導致全量階段結束開始讀Binlog時，之前記錄的Gtid位點已經被MySQL清理掉了。

• 解決方案

  建議延長Binlog的清理時間或調大Binlog檔案大小。調節清理時間的命令如下。

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

報錯：java.lang.IllegalStateException: The "before" field of UPDATE/DELETE message is null,please check the Postgres table has been set REPLICA IDENTITY to FULL level.

• 報錯詳情

  java.lang.IllegalStateException: The "before" feild of UPDATE/DELETE message is null,please check the Postgres table has been set REPLICA IDENTITY to FULL level. You can update the setting by running the command in Postgres 'ALTER TABLE xxx.xxx REPLICA IDENTITY FULL'. Please see more in Debezium documentation:https:debezium.io/documentation/reference/1.2/connectors/postresql.html#postgresql-replica-identity
      at com.alibaba.ververica.cdc.connectors.postgres.table.PostgresValueValidator.validate(PostgresValueValidator.java:46)
      at com.alibaba.ververica.cdc.debezium.table.RowDataDebeziumDeserializeSchema.deserialize(RowDataDebeziumDeserializeSchema.java:113)
      at com.alibaba.ververica.cdc.debezium.internal.DebeziumChangeConsumer.handleBatch(DebeziumChangeConsumer.java:158)
      at io.debezium.embedded.ConvertingEngineBuilder.lambdaşnotifying$2(ConvertingEngineBuilder.java:82)
      at io.debezium.embedded.EmbeddedEngine.run(EmbeddedEngine.java:812)
      at io.debezium.embedded.ConvertingEngineBuilder$2.run(ConvertingEngineBuilder.java:171) 
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1147)
      at java.util.concurrent.ThreadPoolExecutorSWorker.run(ThreadPoolExecutor.java:622)
      at java.lang.Thread.run(Thread.java:834)

• 報錯原因

  Postgres表的REPLICA IDENTITY不為FULL時，會出現該報錯。

• 解決方案

  根據提示執行ALTER TABLE yourTableName REPLICA IDENTITY FULL;，如果執行後作業重啟依舊報錯，可以嘗試加上'debezium.slot.drop.on.stop' = 'true'參數解決。

報錯：Caused by: java.lang.IllegalArgumentException: Can't find any matched tables, please check your configured database-name: xxx and table-name: xxxx

• 報錯原因

  • 配置的表名無法在資料庫中找到時，出現該報錯。

  • Flink作業裡包含不同資料庫的表，當使用的帳號沒有其中某些資料庫許可權時，出現該報錯。

• 解決方案

  1. 檢查對應表名是否在資料庫中存在。

  2. 為帳號添加作業中所有資料庫的對應許可權。

報錯：com.github.shyiko.mysql.binlog.network.ServerException

• 報錯詳情

  Caused by: com.github.shyiko.mysql.binlog.network.ServerException: The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

• 報錯原因

  MySQL CDC在啟動全量讀取之前記錄Binlog位點，等全量讀取結束後再從Binlog位點讀取增量資料。該報錯一般是因為全量讀取耗時太長，超過了MySQL Binlog的淘汰周期，導致MySQL Binlog位點的資料已經被MySQL清理掉了。

• 解決方案

  查看MySQL Binlog的清理規則，例如時間、儲存空間和檔案個數等，建議保留Binlog一天以上，RDS Binlog詳情請參見刪除本地日誌（Binlog）。

  說明

  ：VVR 4.0.8及以上版本，MySQL CDC支援並發讀取全量資料，可以提高全量資料的讀取速度，針對該問題會起到緩解作用。

報錯：The primary key is necessary when enable 'Key: 'scan.incremental.snapshot.enabled'

• 報錯詳情

  MySQL CDC源表在VVR 4.0.x版本語法檢查時報錯詳情如下。

  Caused by: org.apache.flink.table.api.ValidationException: The primary key is necessary when enable 'Key: 'scan.incremental.snapshot.enabled' , default: true (fallback keys: [])' to 'true'
      at com.alibaba.ververica.cdc.connectors.mysql.table.MySqlTableSourceFactory.validatePrimaryKeyIfEnableParallel(MySqlTableSourceFactory.java:186)
      at com.alibaba.ververica.cdc.connectors.mysql.table.MySqlTableSourceFactory.createDynamicTableSource(MySqlTableSourceFactory.java:85)
      at org.apache.flink.table.factories.FactoryUtil.createTableSource(FactoryUtil.java:134)
      ... 30 more

• 報錯原因

  在MySQL CDC DDL WITH參數中，您未設定主鍵（Primary Key）資訊。因為VVR 6.0.x版本和VVR 4.0.8及以上版本，新增支援按PK分區，進行多並發讀取資料的功能。

  重要

  VVR 4.0.8以下版本，MySQL CDC源表僅支援單並發讀取資料。

• 解決方案

  • VVR 6.0.x版本或VVR 4.0.8及以上版本，如果您需要多並發讀取MySQL資料，可以在DDL中添加PK資訊。

  • VVR 4.0.8以下版本，MySQL CDC源表不支援多並發讀取MySQL資料，需要在DDL中添加scan.incremental.snapshot.enabled參數，且把該參數值設定為false，無需設定PK資訊。

報錯：java.io.EOFException: SSL peer shut down incorrectly

• 報錯詳情

  Caused by: java.io.EOFException: SSL peer shut down incorrectly
      at sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:239) ~[?:1.8.0_302]
      at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:190) ~[?:1.8.0_302]
      at sun.security.ssl.SSLTransport.decode(SSLTransport.java:109) ~[?:1.8.0_302]
      at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1392) ~[?:1.8.0_302]
      at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1300) ~[?:1.8.0_302]
      at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:435) ~[?:1.8.0_302]
      at com.mysql.cj.protocol.ExportControlled.performTlsHandshake(ExportControlled.java:347) ~[?:?]
      at com.mysql.cj.protocol.StandardSocketFactory.performTlsHandshake(StandardSocketFactory.java:194) ~[?:?]
      at com.mysql.cj.protocol.a.NativeSocketConnection.performTlsHandshake(NativeSocketConnection.java:101) ~[?:?]
      at com.mysql.cj.protocol.a.NativeProtocol.negotiateSSLConnection(NativeProtocol.java:308) ~[?:?]
      at com.mysql.cj.protocol.a.NativeAuthenticationProvider.connect(NativeAuthenticationProvider.java:204) ~[?:?]
      at com.mysql.cj.protocol.a.NativeProtocol.connect(NativeProtocol.java:1369) ~[?:?]
      at com.mysql.cj.NativeSession.connect(NativeSession.java:133) ~[?:?]
      at com.mysql.cj.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:949) ~[?:?]
      at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:819) ~[?:?]
      at com.mysql.cj.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:449) ~[?:?]
      at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:242) ~[?:?]
      at com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:198) ~[?:?]
      at org.apache.flink.connector.jdbc.internal.connection.SimpleJdbcConnectionProvider.getOrEstablishConnection(SimpleJdbcConnectionProvider.java:128) ~[?:?]
      at org.apache.flink.connector.jdbc.internal.AbstractJdbcOutputFormat.open(AbstractJdbcOutputFormat.java:54) ~[?:?]
      ... 14 more

• 報錯原因

  在MySQL 8.0.27版本，MySQL資料庫預設串連需要使用SSL協議，但JDBC預設的訪問方式不通過SSL協議串連資料庫，導致報錯。

• 解決方案

  • 如果可以升級到VVR 6.0.2及以上版本，在MySQL CDC表的with參數中添加參數'jdbc.properties.useSSL'='false'可以解決該問題。

  • 如果聲明的表只是做維表，可以在MySQL表的WITH參數中將connector設定為rds，同時在URL參數中追加characterEncoding=utf-8&useSSL=false，例如：

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

報錯：com.github.shyiko.mysql.binlog.network.ServerException: A slave with the same server_uuid/server_id as this slave has connected to the master

• 報錯詳情

  Caused by: com.ververica.cdc.connectors.shaded.org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped.
      at io.debezium.pipeline.ErrorHandler.setProducerThrowable(ErrorHandler.java:42) ~[?:?]
      at io.debezium.connector.mysql.MySqlStreamingChangeEventSource$ReaderThreadLifecycleListener.onCommunicationFailure(MySqlStreamingChangeEventSource.java:1185) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:973) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:606) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:850) ~[?:?]
      ... 1 more
  Caused by: io.debezium.DebeziumException: A slave with the same server_uuid/server_id as this slave has connected to the master; the first event '' at 4, the last event read from '/home/mysql/dataxxx/mysql/mysql-bin.xxx' at xxx, the last byte read from '/home/mysql/dataxxx/mysql/mysql-bin.xxx' at xxx. Error code: 1236; SQLSTATE: HY000.
      at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.wrap(MySqlStreamingChangeEventSource.java:1146) ~[?:?]
      at io.debezium.connector.mysql.MySqlStreamingChangeEventSource$ReaderThreadLifecycleListener.onCommunicationFailure(MySqlStreamingChangeEventSource.java:1185) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:973) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:606) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:850) ~[?:?]
      ... 1 more
  Caused by: com.github.shyiko.mysql.binlog.network.ServerException: A slave with the same server_uuid/server_id as this slave has connected to the master; the first event '' at 4, the last event read from '/home/mysql/dataxxx/mysql/mysql-bin.xxx' at xxx, the last byte read from '/home/mysql/dataxxx/mysql/mysql-bin.xxx' at xxx.
      at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:937) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:606) ~[?:?]
      at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:850) ~[?:?]
      ... 1 more

• 報錯原因

  MySQL CDC源表讀取資料時，需要保證每個並行度有單獨的server-id，且每個server-id全域唯一。當使用的server-id與同一作業CDC源表、其他作業CDC源表或其他同步工具使用server-id衝突時，導致報錯。

• 解決方案

  需要為MySQL CDC源表的每個並行度配置全域唯一的server-id，詳細操作請參見MySQL CDC源表注意事項。

報錯：TableMapEventDataDeserializer.readMetadata的NullPointerException

• 報錯詳情

  Causedby:java.lang.NullPointerException
      atcom.github.shyiko.mysql.binlog.event.deserialization.TableMapEventDataDeserializer.readMetadata(TableMapEventDataDeserializer.java:81)
  atcom.github.shyiko.mysql.binlog.event.deserialization.TableMapEventDataDeserializer.deserialize(TableMapEventDataDeserializer.java:42)
  atcom.github.shyiko.mysql.binlog.event.deserialization.TableMapEventDataDeserializer.deserialize(TableMapEventDataDeserializer.java:27)
  atcom.github.shyiko.mysql.binlog.event.deserialization.EventDeserializer.deserializeEventData(EventDeserializer.java:303)
  atcom.github.shyiko.mysql.binlog.event.deserialization.EventDeserializer.deserializeTableMapEventData(EventDeserializer.java:281)
  atcom.github.shyiko.mysql.binlog.event.deserialization.EventDeserializer.nextEvent(EventDeserializer.java:228)
  atio.debezium.connector.mysql.MySqlStreamingChangeEventSource$1.nextEvent(MySqlStreamingChangeEventSource.java:259)
  atcom.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:952)
  ...3more

• 報錯原因

  8.0.18及以上版本MySQL新添加了一些資料類型，但是Flink解析Binlog部分沒有相容新的資料類型。

• 解決方案

  VVR 6.0.6及以上版本針對MySQL新增的資料類型進行了相容，您可以升級VVR版本解決。

MySQL全量過程中增加列後報錯NullPointerException

• 報錯詳情

  Caused by: org.apache.flink.util.FlinkRuntimeException: Read split MySqlSnapshotSplit{tableId=iplus.retail_detail, splitId='iplus.retail_detail:68', splitKeyType=[`id` BIGINT NOT NULL], splitStart=[212974500236****], splitEnd=[213118153601****], highWatermark=null} error due to java.lang.NullPointerException.
    at com.ververica.cdc.connectors.mysql.debezium.reader.SnapshotSplitReader.checkReadException(SnapshotSplitReader.java:361)
    at com.ververica.cdc.connectors.mysql.debezium.reader.SnapshotSplitReader.pollSplitRecords(SnapshotSplitReader.java:293)
    at com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader.pollSplitRecords(MySqlSplitReader.java:124)
    at com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader.fetch(MySqlSplitReader.java:86)
    at org.apache.flink.connector.base.source.reader.fetcher.FetchTask.run(FetchTask.java:58)
    at org.apache.flink.connector.base.source.reader.fetcher.SplitFetcher.runOnce(SplitFetcher.java:142)
    ... 6 more

• 報錯原因

  全量階段的表結構是在作業啟動的時候確定，且Schema會被記錄在系統檢查點中。如果在讀全量的過程中增加了列，Schema會無法匹配，就會拋出此異常。

• 解決方案

  停止作業並刪除同步的下遊表後，無狀態啟動該作業。

報錯 ：The connector is trying to read binlog starting at GTIDs xxx and binlog file 'binlog.000064', pos=89887992, skipping 4 events plus 1 rows, but this is no longer available on the server. Reconfigure the connector to use a snapshot when needed

• 報錯詳情

  出現該報錯表明CDC作業試圖讀取的Binlog檔案時，在MySQL伺服器上檔案已經被清理掉。

• 報錯原因

  • MySQL伺服器上設定的Binlog檔案到期時間太短導致檔案被自動清理。

  • CDC作業處理Binlog的速度過慢。

• 解決方案

  • 增加Binlog的保留時間可以避免檔案到期時間太短這個問題，例如，將其設定為保留7天。

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

  • 針對作業處理Binlog的速度過慢這個問題，可以分配更多資源給Flink作業協助加快處理速度。

報錯：Mysql8.0 Public Key Retrieval is not allowed

• 報錯原因

  因為使用者配置的MySQL使用者使用的是SHA256密碼認證方式，並且需要TLS等協議傳輸密碼。

• 解決方案

  允許MySQL使用者支援原始密碼方式訪問。更改驗證方式的命令如下。

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