基于日志增量订阅和消费的业务包括
- 数据库镜像
- 数据库实时备份
- 索引构建和实时维护(拆分异构索引、倒排索引等)
- 业务 cache 刷新
- 带业务逻辑的增量数据处理
当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x
工作原理
MySQL主备复制原理
- MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
- MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
- MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据
canal 工作原理
- canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
- MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
- canal 解析 binary log 对象(原始为 byte 流)
迁移方案分析
数据迁移的方案从业务层到数据库层各有不同的迁移方案, 我们先列举一些进行比对:
业务层: 在业务层进行硬编码, 数据双写, 以某个时间点进行划分, 新产生的数据同时写入新表, 运行一段时间后将旧数据迁移至新表. 成本极高, 与业务耦合严重, 不考虑.
连接层: 是方案1的进阶版, 在连接层拦截SQL进行双写, 与业务解耦, 但与1有着同样的一个问题: 周期较长, 要确保旧数据不会产生变更才能进行迁移.
触发器: 通过触发器将新产生的数据同步到新表, 本质上与2差不多.
数据库日志: 从某一时间点T备份数据库, 将备份库的数据迁移至新表, 从时间点T读取日志, 恢复到新表, 并持续写入. 待两份数据保持同步后, 上线新代码.
伪装从库: 相对于方案4的优势是不需要直接去读取日志, 解决了数据库在云上不方便直接读取日志的问题.
相比较之下, 方案4和5都是可选的, 因数据库在云上, 直接读取日志不方便, 且方案5有成熟的开源中间件canal可用, 故笔者选择了方案5.
Canal文档地址: https://github.com/alibaba/canal/wiki
回退方案分析
新代码上线后, 谁也不能确保百分百没问题. 若迁移失败, 必须要进行回滚. 所以, 需要保证原数据和新数据的同步.
所以, 在前一小节方案5的基础上, 切流量到新集群后, 我们停止数据同步, 从切流量时刻开始同步新表数据到旧表, 方案也是伪装从库. 如此就能保证新旧表的数据同步, 如果上线后发生了异常, 将流量切回旧集群即可.
整体方案设计
备份源数据
执行flush logs: 生成新的binlog, 恢复数据将从这里开始.
备份数据表(order_{0~19}): 将源(旧)数据表从主库A复制到备份库B
恢复并同步数据
在主库A创建足够的新表, order新表按照月进行分表.
写脚本读取备份库B中的order表, 写入主库A的order新表.
通过canal开始同步旧表数据到新表, 命名为[同步过程-a].
上线
编译新代码并弹一个新的集群, 确认完全启动完成.
执行flush logs生成新的binlog, 新表向旧表同步数据将从这里开始.
流量切到新集群.
停止[同步过程-a].
开始从新表向旧表同步数据.
回退
上线后应及时进行测试, 一旦发现严重的异常就立即将流量切回旧集群.
结语
flash logs要先于备份源数据表, 即使中间有些许时间间隔也不会影响数据的最终一致 (听binlog的总没错).
数据无价, 谨慎操作.
