已解决 canal1.1.4出现报错column size is not match for table

[yixi]

报错信息如下：

Caused by: com.alibaba.otter.canal.parse.exception.CanalParseException: parse row data failed.
Caused by: com.alibaba.otter.canal.parse.exception.CanalParseException: column size is not match for table:db.tb_order,17 vs 0
2019-11-15 12:05:18.237 [destination = bigdata36 , address = /192.168.112.36:3306 , EventParser] ERROR com.alibaba.otter.canal.common.alarm.LogAlarmHandler - destination:bigdata36[com.alibaba.otter.canal.parse.exception.CanalParseException: com.alibaba.otter.canal.parse.exception.CanalParseException: parse row data failed.
Caused by: com.alibaba.otter.canal.parse.exception.CanalParseException: parse row data failed.
Caused by: com.alibaba.otter.canal.parse.exception.CanalParseException: column size is not match for table:db.tb_order,17 vs 0
]

[CloudCanal-万少]

@yuanweikang2020 可能你碰到的例子和我不太一样。我这边大部分DDL同步是正常的，但是有时候有多条ddl一起执行后，在table meta处理的时候druid parser针对同一个table会做meta信息合并，我当时debug到我贴的这段代码这边，发现根据table取出来meta信息中列信息是错误的，是druid parser存储table meta的时候，针对单个表多条ddl变更时，最后记录的合并后的表结构有误。

[yuanweikang2020]

@cloudcanal-万少 这并不是druid 解析的bug导致获取table meta的问题，这是canal本身代码逻辑有bug
你的这种解决方式也是我之前的解决方式，但是每次用这种方式我就想骂人；后面我解决了这个bug，就再也没有出现了。解决方式很简单，忽略部分create ddl，代码如下：

if (StringUtils.contains(StringUtils.upperCase(queryString), “CREATE TABLE IF NOT EXISTS”)) {
    TableMeta tableMeta = getTableMeta(event.getDbName(),tableName, true, position);
   if (tableMeta != null) {
       logger.error(“ignore schema: {}, table: {}, ddl: {}”, event.getDbName(), tableName, queryString);
   }
} else {
      logger.error(“apply schema: {}, table: {}, ddl: {}”, event.getDbName(), tableName, queryString);
     // 使用新的表结构元数据管理方式
    tableMetaCache.apply(position, event.getDbName(), queryString, null);
}

[yuanweikang2020]

此回复已被删除！

[yuanweikang2020]

此回复已被删除！

[CloudCanal-万少]

canal处理tsdb的时候有依赖druid做sql解析与合并然后更新内存里面的meta cache。我遇到过的情况是druid 解析的bug导致获取table meta的信息不准确，从而导致匹配元数据的时候DDL里面的列信息和内存的table meta不一致就会有这个报错。如果本地可以调试，可以调试下MemoryTableMeta这个类里面如下的代码，看看输出的TableMeta信息与实际收到的DDL表结构信息是否一致：

如果只想简单的解决问题，可以考虑按照如下步骤操作：

1. 先停止任务
2. 关闭ddl的同步
3. 将tsdb数据库中关于这个destination的snapshot和history信息清除
4. 对端数据库手动执行DDL
5. 启动任务，等位点追上。
6. （可选）位点追上后可以考虑再开启ddl同步