問題描述

新增Mysql數據時，ES、Hbase數據會同步成功；當刪除Mysql數據，或者修改Mysql數據時同步ES、Hbase數據無變化(PS:修改和刪除加上LIMIT xxx 就可以成功。)

問題分析

通過查看日志發現新增和刪除記錄的日志區別：新增data有數據，修改、刪除 data為空

2021-09-22 10:29:03.551 [pool-1-thread-1] DEBUG c.a.o.c.client.adapter.hbase.service.HbaseSyncService - DML: {"data":[{"id":"d9a63f30-1b4c-11ec-99c4-708cb6f5eaa6","name":"aaabbbcccc","age":null,"age_2":null,"message":null,"insert_time":null}],"database":"test2","destination":"example","es":1632277742000,"groupId":"g1","isDdl":false,"old":null,"pkNames":["id"],"sql":"","table":"testsync","ts":1632277743140,"type":"INSERT"} 2021-09-22 10:19:36.703 [pool-1-thread-1] DEBUG c.a.o.c.client.adapter.hbase.service.HbaseSyncService - DML: {"data":null,"database":"test2","destination":"example","es":1632277176000,"groupId":"g1","isDdl":false,"old":null,"pkNames":[],"sql":"DELETE FROM testsync where name = 'aaabbbcccc'","table":"testsync","ts":1632277176566,"type":"DELETE"} 2021-09-22 10:19:36.704 [pool-1-thread-1] DEBUG c.a.o.canal.client.adapter.es.core.service.ESSyncService - DML: {"data":null,"database":"test2","destination":"example","es":1632277176000,"groupId":"g1","isDdl":false,"old":null,"pkNames":[],"sql":"DELETE FROM testsync where name = 'aaabbbcccc'","table":"testsync","ts":1632277176566,"type":"DELETE"}

通過查看源碼我們發現,當data為null時，直接return，不進行下一步操作

/*** 更新操作dml** @param config es配置* @param dml dml數據*/private void update(ESSyncConfig config, Dml dml) {List<Map<String, Object>> dataList = dml.getData();List<Map<String, Object>> oldList = dml.getOld();if (dataList == null || dataList.isEmpty() || oldList == null || oldList.isEmpty()) {return;}....

問題找到，原因就是我們沒有記錄修改的數據。
再次查看源碼，找一下是從什么時候data沒有的。
發現在MessageUtil中有數據轉換，加入日志，重新打包將 connector.core-1.1.5.jar 替換掉，重啟服務，我們查看下從數據接收進來是不是就已經沒有了

/*** Message對象解析工具類** @author rewerma 2018-8-19 下午06:14:23* @version 1.0.0*/ public class MessageUtil {private static final Logger logger = LoggerFactory.getLogger(MessageUtil.class);public static List<CommonMessage> convert(Message message) {if (message == null) {return null;}List<CanalEntry.Entry> entries = message.getEntries();List<CommonMessage> msgs = new ArrayList<>(entries.size());for (CanalEntry.Entry entry : entries) {if (entry.getEntryType() == CanalEntry.EntryType.TRANSACTIONBEGIN|| entry.getEntryType() == CanalEntry.EntryType.TRANSACTIONEND) {continue;}CanalEntry.RowChange rowChange;try {rowChange = CanalEntry.RowChange.parseFrom(entry.getStoreValue());} catch (Exception e) {throw new RuntimeException("ERROR ## parser of eromanga-event has an error , data:" + entry.toString(),e);}// 加入日志，重新打包將 connector.core-1.1.5.jar 替換掉，重啟服務，我們查看下從數據接收進來是不是就已經沒有了logger.info("row:{}",rowChange.getRowDatasList());....

重啟后在adapter日志中發現，在接收數據時已經沒有了。

隨后我們從 Mysql方面分析，根據Mysql Binlog三種格式我們知道，當類型設置Statement或者Mixed時會導致數據記錄不是全部列。

這里簡單介紹下三種區別

MySQL 5.5 中對于二進制日志 (binlog) 有 3 種不同的格式可選：Mixed,Statement,Row，默認格式是 Statement?？偨Y一下這三種格式日志的優缺點。MySQL Replication 復制可以是基于一條語句 (Statement Level) ，也可以是基于一條記錄 (Row Level)，可以在 MySQL 的配置參數中設定這個復制級別，不同復制級別的設置會影響到 Master 端的 bin-log 日志格式。1. Row 日志中會記錄成每一行數據被修改的形式，然后在 slave 端再對相同的數據進行修改。優點：在 row 模式下，bin-log 中可以不記錄執行的 SQL 語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以 row 的日志內容會非常清楚的記錄下每一行數據修改的細節，非常容易理解。而且不會出現某些特定情況下的存儲過程或 function ，以及 trigger 的調用和觸發無法被正確復制的問題。缺點：在 row 模式下，所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容，比如有這樣一條 update 語句：UPDATE product SET owner_member_id = 'b' WHERE owner_member_id = 'a' 執行之后，日志中記錄的不是這條 update 語句所對應的事件 (MySQL 以事件的形式來記錄 bin-log 日志) ，而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，bin-log 日志的量就會很大。尤其是當執行 alter table 之類的語句的時候，產生的日志量是驚人的。因為 MySQL 對于 alter table 之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動，實際上就是重建了整個表。那么該表的每一條記錄都會被記錄到日志中。2. Statement 每一條會修改數據的 SQL 都會記錄到 master 的 bin-log 中。slave 在復制的時候 SQL 進程會解析成和原來 master 端執行過的相同的 SQL 再次執行。優點：在 statement 模式下，首先就是解決了 row 模式的缺點，不需要記錄每一行數據的變化，減少了 bin-log 日志量，節省 I/O 以及存儲資源，提高性能。因為他只需要記錄在 master 上所執行的語句的細節，以及執行語句時候的上下文的信息。缺點：在 statement 模式下，由于他是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那么他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證所有語句在 slave 端杯執行的時候能夠得到和在 master 端執行時候相同的結果。另外就是，由于 MySQL 現在發展比較快，很多的新功能不斷的加入，使 MySQL 的復制遇到了不小的挑戰，自然復制的時候涉及到越復雜的內容，bug 也就越容易出現。在 statement 中，目前已經發現的就有不少情況會造成 MySQL 的復制出現問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，比如：sleep() 函數在有些版本中就不能被正確復制，在存儲過程中使用了 last_insert_id() 函數，可能會使 slave 和 master 上得到不一致的 id 等等。由于 row 是基于每一行來記錄的變化，所以不會出現類似的問題。3. Mixed 從官方文檔中看到，之前的 MySQL 一直都只有基于 statement 的復制模式，直到 5.1.5 版本的 MySQL 才開始支持 row 復制。從 5.0 開始，MySQL 的復制已經解決了大量老版本中出現的無法正確復制的問題。但是由于存儲過程的出現，給 MySQL Replication 又帶來了更大的新挑戰。另外，看到官方文檔說，從 5.1.8 版本開始，MySQL 提供了除 Statement 和 Row 之外的第三種復制模式：Mixed，實際上就是前兩種模式的結合。在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日志形式，也就是在 statement 和 row 之間選擇一種。新版本中的 statment 還是和以前一樣，僅僅記錄執行的語句。而新版本的 MySQL 中對 row 模式也被做了優化，并不是所有的修改都會以 row 模式來記錄，比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 語句確實就是 update 或者 delete 等修改數據的語句，那么還是會記錄所有行的變更。

最后去查看我們配置文件，發現我們的配置文件設置了兩個 binlog_format （復制之前的配置文件，在上面加了一個 binlog_format=ROW，但是未生效，被下面的覆蓋了。。。。。）

最終刪除

log_bin = mysql-bin binlog_format = mixed

保留

log_bin=mysql-bin # 開啟 binlog binlog_format=ROW # 選擇 ROW 模式 binlog_row_image=FULL

重啟Mysql、canal 再次執行修改刪除，data中已經有記錄

2021-09-22 11:20:45.456 [pool-1-thread-1] DEBUG c.a.o.c.client.adapter.hbase.service.HbaseSyncService - DML: {"data":[{"id":"10d7e4b8-1b54-11ec-8673-708cb6f5eaa6","name":"bbb","age":null,"age_2":null,"message":null,"insert_time":1632280844000}],"database":"test2","destination":"example","es":1632280844000,"groupId":"g1","isDdl":false,"old":[{"name":"aaabbbcccc","insert_time":null}],"pkNames":["id"],"sql":"","table":"testsync","ts":1632280845389,"type":"UPDATE"} 2021-09-22 11:20:45.517 [pool-1-thread-1] DEBUG c.a.o.canal.client.adapter.es.core.service.ESSyncService - DML: {"data":[{"id":"10d7e4b8-1b54-11ec-8673-708cb6f5eaa6","name":"bbb","age":null,"age_2":null,"message":null,"insert_time":1632280844000}],"database":"test2","destination":"example","es":1632280844000,"groupId":"g1","isDdl":false,"old":[{"name":"aaabbbcccc","insert_time":null}],"pkNames":["id"],"sql":"","table":"testsync","ts":1632280845389,"type":"UPDATE"}

文章開頭有說：PS:修改和刪除加上LIMIT xxx 就可以成功。原因就是ROW和mixed的區別。

其他類似問題

當為mixed時，在Navicat直接點+新增數據時data也同樣為空。改為ROW即可

總結

以上是生活随笔為你收集整理的Canal Mysql同步至ES/Hbase只有新增时生效，修改删除不生效的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。