• 阿里巴巴开源canal 工具数据同步异常CanalParseException:parse row data failed,column size is not match for table......


    一、异常现象截图

     二、解决方式:

    1、背景

    早期的canal版本(<=1.0.24),在处理表结构的DDL变更时采用了一种简单的策略,在内存里维护了一个当前数据库内表结构的镜像(通过desc table获取)。

    这样的内存表结构镜像的维护存在问题,如果当前在处理的binlog为历史时间段T0,当前时间为T1,存在的一些异常分支情况:

    1. 假如在T0~T1的时间内,表结构A发生过增加列的DDL操作,那在处理T0时间段A表的binlog时,拿到的表结构为T1的镜像,就会出现列不匹配的情况. 比如之前的异常: column size is not match for table: xx , 12 vs 13
    2. 假如在T0~T1发生了增加 C1列、删除了C2列,此时拿到的列的总数还是和T0时保持一致,但是对应的列会错位
    3. 假如在T0~T1发生了drop table的DDL,此时拿表结构时会出现无法找到表的异常,一直阻塞整个binlog处理,比如not found [xx] in db

    补充一下MySQL binlog的一些技术背景:

    本文作者:张永清,转载请注明出处:https://www.cnblogs.com/laoqing/p/13187324.html

    • MySQL的在记录DML(INSERT/UPDATE/DELETE)的binlog时,会由一个当前表结构snapshot的TableMap binlog来描述,然后跟着一条DML的binlog image | center
    • TableMap对象里,会记录一些基本信息:列的数量、列类型精度、后续DML binlog里的数据存储格式等,但唯独没有记录列名信息、列编码、列类型,这也是大众业务理解binlog的基本诉求(但MySQL binlog只做同构重放,可以不关注这些),所以canal要做的一件事就是补全对应的列信息.

    ps. 针对复杂的一条update中包含多张表的更新时,大家可以观察一下Table_map的特殊情况,留待有兴趣的同学发挥

    2、方案

    扯了一堆的背景之后,再来看一下我们如何解决canal上一版本存在的表结构一致性的问题,这里会把我们的思考过程都记录出来,方便大家辩证的看一下方案.

    思考一

    解决这个问题,第一个最直接的思考:canal在订阅binlog时,尽可能保持准实时,不做延迟回溯消费. 这样的方式会有对应的优点和缺点:

    1. canal要做准实时解析,业务上可能有failover的需求,假如在业务处理离线时,原本canal基于内存ringBuffer的模型,会出现延迟解析,如果要解决这个问题,必须在canal store上支持了持久化存储的能力,比如实现或者转存到kafka/rocketmq等.
    2. canal准实时解析,如果遇到canal本身的failover,比如zookeeper挂、网络异常,出现分钟级别以上的延迟,DDL变化的概率会比较高,此时就会陷入之前一样的表结构一致性的问题

    整个方案上,基本是想避开表结构的问题,在遇到一些容灾场景下一定也会遇上,不是一个技术解决的方案,废弃.

    思考二

    经过了第一轮辩证的思考,基本确定想通过迂回的方式,简单绕过一致性的问题不是正解,所以这次的思考主要就是如何正面解决一致性的问题. 基本思路:基于binlog中DDL的变化,来动态维护一份表结构,比如DDL中增加一个列,在本地表结构中也动态增加一列,解析binlog时都从本地表结构中获取

    实现方案:

    1. 本地表结构的维护,每个canal进程可以带着一个二进制的MySQL版本,把收到的每条DDL,在本地MySQL中进行重放,从而维护一个本地的MySQL表结构
    2. 每个canal第一次订阅或者回滚到指定位点,刚启动时需要拉取一份表结构基线,存入本地表结构MySQL库,然后在步骤1的方案上维护一个增量DDL.

    整个方案上,可以绝大部分的解决DDL的问题,但也存在一些缺点:

    1. 每个canal进程,维护一个隔离的MySQL实例。不论是资源成本、运维成本上都有一些瑕疵,更像是一个工程的解决方案,不是一个开源+技术产品的解决方案
    2. 位点如果存在相对高频的位点回溯,每次都需要重新做表结构基线,做表结构基线也会概率遇上表结构一致性问题

    思考三

    有了之前的两次思考,思路基本明确了,在一次偶然的机会中和alibaba Druid的作者高铁,交流中得到了一些灵感,是否可以基于Druid对DDL的支持能力,来构建一份动态的表结构.

    大致思路:

    1. 首先准备一份表结构基线数据,每条建表语句传入druid的SchemaRepository.console(),构建一份druid的初始表结构
    2. 之后在收到每条DDL变更时,把alter table add/drop column等,全部传递给druid,由druid识别ddl语句并在内存里执行具体的add/drop column的行为,维护一份最终的表结构
    3. 定时把druid的内存表结构,做一份checkpoint,之后的位点回溯,可以是checkpoint + 增量DDL重放的方式来快速构建任意时间点的表结构

    最终方案示意图

    1. C0为初始化的checkpoint,拿到所有满足订阅条件的表结构
    2. D1为binlog日志流中的DDL,它会有时间戳T的标签,用于记录不同D1/D2之间的先后关系
    3. 定时产生一个checkpoint cm,并保存对应的checkpoint时间戳
    4. 用户如果回溯位点到任意时间点Tx,对应的表结构就是 checkpoint + ddl增量的结合

    接口设计:

    public interface TableMetaTSDB {
    
        /**
         * 初始化
         */
        public boolean init(String destination);
    
        /**
         * 获取当前的表结构
         */
        public TableMeta find(String schema, String table);
    
        /**
         * 添加ddl到时间表结构库中
         */
        public boolean apply(BinlogPosition position, String schema, String ddl, String extra);
    
        /**
         * 回滚到指定位点的表结构
         */
        public boolean rollback(BinlogPosition position);
    
        /**
         * 生成快照内容
         */
        public Map<String/* schema */, String> snapshot();
    }

    1. 依赖了alibaba druid的DDL SQL解析能力,维护一份MemoryTableMeta,实时内存表结构
    2. 依赖DAO持久化存储的能力,记录WAL结果(每条DDL) + checkpoint

    持久化存储的思考:

    1. 本地嵌入式实现(H2):提供最小化的依赖,完成时序表结构管理的能力。基于磁盘的模式,可以结合存储计算分离的技术,canal failover之后只要在另一个计算节点上拉起,并加载云盘上的DB数据,做到多机冷备。
    2. 中心管控存储实现(MySQL): 一般结合于规模化的管控系统,允许将DDL数据录入到中心MySQL进行统一运维。

    canal中如何使用

    1. 打开conf/canal.properties,选择持久化存储的方案,默认为H2
    canal.instance.tsdb.spring.xml=classpath:spring/tsdb/h2-tsdb.xml
    #canal.instance.tsdb.spring.xml=classpath:spring/tsdb/mysql-tsdb.xml
    
    1. 打开instance下的instance.properties,修改对应的参数
    参数名默认值描述
    canal.instance.tsdb.enable true 是否开启时序表结构的能力
    canal.instance.tsdb.dir ${canal.file.data.dir:../conf}/${canal.instance.destination:} 默认存储到conf/$instance
    canal.instance.tsdb.url jdbc:h2:${canal.instance.tsdb.dir}/h2;CACHE_SIZE=1000;MODE=MYSQL; jdbc链接串
    canal.instance.tsdb.dbUsername canal jdbc用户名,因为有自动创建表的能力,所以对该用户需要有create table的权限
    canal.instance.tsdb.dbPassword canal jdbc密码

    例子:

    # table meta tsdb info
    canal.instance.tsdb.enable=true
    canal.instance.tsdb.dir=${canal.file.data.dir:../conf}/${canal.instance.destination:}
    canal.instance.tsdb.url=jdbc:h2:${canal.instance.tsdb.dir}/h2;CACHE_SIZE=1000;MODE=MYSQL;
    #canal.instance.tsdb.url=jdbc:mysql://127.0.0.1:3306/canal_tsdb
    canal.instance.tsdb.dbUsername=canal
    canal.instance.tsdb.dbPassword=canal

    三、最后

    目前canal 1.0.26最新版已经默认开启了时序表结构的能力,just have fun !

  • 相关阅读:
    SOJ 2785_Binary Partitions
    Codeforces Round #328 (Div. 2)
    C++ fill 和memset
    SOJ 2749_The Fewest Coins
    Codeforces Round #327 (Div. 2)
    TYVJ P1013 找啊找啊找GF Label:动态规划
    TYVJ 1014 乘法游戏
    TYVJ 1011 NOIP 2008&&NOIP 2000 传纸条&&方格取数 Label:多线程dp
    错误集合
    TYVJ P1038/P1039 忠诚 标签:线段树
  • 原文地址:https://www.cnblogs.com/laoqing/p/13187324.html
Copyright © 2020-2023  润新知