1、造成串列的原因有几个:

1)、binlog的日志只是记录了列索引

2)、增删列都会改变列索引和列名的映射关系

3)、同步工具canal只在启动时dump table meta, 换句话说, 就是将列索引和列名映射缓存到内存里

4)、同步工具canal在解析binlog日志时并行的, 由于线程安全问题, 没有在遇到ddl语句时, 更新缓存中的 table meta.

性能和完全规避串列不可兼得, 一般的设计者认为 ddl 是不频繁的. 因此为了减少串列的发生, canal使用了时序表结构方案设计, 即TableMetaTSDB.

开启tsdb后, 当新增字段后, canal会抛出异常: column size is not match for table. 此时, 便需要手动重启canal. 但是binlog一旦出现堆积, 且新增的字段列不是在最后, 仍然会导致串列.

为了解决手动重启的问题, canal又提供了定时任务更新缓存里的table meta 和 table meta缓存过期机制. 为了减少串列的发生, 该定时任务的默认时间是24小时, 缓存过期时间是 360小时.

这就显得很鸡肋了.

下图是binlog的日志格式:

2、串列最终导致的结果

源库和目标库的数据不一致.

3、可能引起串列 或者 导致数据不一致 的几个操作:

1)、新增列的位置不在最后. 在操作新增列时, 一旦binlog数据堆积, 重启canal, 必然串列.

2)、新增列的位置在最后, 但是前面的列有删除. 在操作上述操作时, 一旦binlog数据堆积, 重启canal, 必然串列.

3)、删除列. 在操作删除列时, 一旦binlog数据堆积, 重启canal, 该部分binlog解析时可能提示列索引找不到对应列名而被丢弃, 最终导致数据不一致.

4、如何控制串列、 数据一致性、手动重启.

1)、控制串列可以从ddl审计流程上控制, 不允许删除列, 不允许在中间新增列.

2)、控制数据一致性, 从目前的监控手段来看, 只能对比到异构数据库的数据量, 无法对比源库和目标库所有的列值是否一致.

3)、在不串列的情况下, 不重启canal, 可以有以下操作保证:

a、binlog解析改为串行;

b、修改canal源代码 , 在处理ddl语句和抛异常时: column size is not match for table, 触发更新缓存中的 table meta;

c、串行性能出现瓶颈时, 针对出现性能瓶颈的表或者schema, 独享instance.

#头条家时光#?