关于数据库:CloudCanal对Online-DDL-工具-GHOST-和-PTOSC-的支持

46次阅读

共计 4140 个字符，预计需要花费 11 分钟才能阅读完成。

简介

CloudCanal 实现了对 Online DDL 工具如 GH-OST 和 PT-OSC 的反对，保障了对端实时同步源端的 Online DDL 操作。

本文以 MySQL -> MySQL 同步链路应用 GH-OST 为例，介绍 CloudCanal 是如何反对实时同步 GH-OST 产生的 DDL 的。

Online DDL 技术背景

市面上罕用的两款 MySQL Online DDL 工具别离是 GH-OST 和 PT-OSC，CloudCanal 对他们都做了兼容解决使得用户能够实时同步 Online DDL 工具产生的 DDL。上面简略介绍下他们的工作流程，以便于读者了解后续章节的内容。

Online DDL 工具 PT-OSC 原理

PT-OSC 是较为罕用的 Online DDL 工具，通过触发器来同步增量数据，相较于 MySQL 原生的 Online DDL 性能失去了极大的进步，原理如下：

  • 对源表进行查看
  • 创立一个与源表（origin）构造统一的空表，命名为 _origin_new
  • 依据 alter 参数批改新表的表构造
  • 在源表中创立三个触发器：Delete / Update / Insert，将源表中的增删改语句同步执行到新表中，同时将源表中的数据以数据块的模式 copy 到新表
  • 将源表（origin）rename 为 _origin_old，将 _origin_new rename 为 origin，而后删除旧表（可选）
  • 删除触发器

总结 ：PT-OSC 是通过创立长期表，并用触发器将增量数据同步到新表，通过以后读和事务来实现增量与全量的有序，不会阻塞读写操作，但 运行过程中出现异常，无奈从上一个地位持续进行，须要从头开始。

Online DDL 工具 GH-OST 原理

GH-OST 也是一款罕用的 Online DDL 工具，采纳读取 binlog 日志的形式来同步增量数据，原理如下：

  • 对源表（origin）进行查看
  • 在主 / 从节点中增加 binlog 日志监听
  • 创立日志记录表（_origin_ghc）和与源表构造统一的影子表（_origin_gho）
  • 依据 alter 参数批改影子表的表构造
  • 全量拷贝源表数据同时拷贝源表增量数据到影子表中，并记录日志到日志记录表中
  • 删除日志记录表，将源表改名为 _origin_del, 将影子表改名为 origin，_origin_del 可选删除

总结： GH-OST 的性能与 PT-OSC 相近，相较于 PT-OSC 的长处就在于其是不应用触发器的，只异步读取二进制日志，因而批改表定义的负载和失常的业务负载解耦开了，它不须要思考被批改的表上的并发操作和竞争等，并且相较于 PT-OSC 的中断从头开始，GH-OST 能够从心跳日志中复原到指定地位。

CloudCanal 技术点

前文中对 Online DDL 工具的原理中咱们晓得，无论采纳哪种 Online DDL 工具，源端都会产生一些长期表的创立和数据写入，如果不做任何兼容解决，这会影响失常的迁徙同步链路。

因而为了反对 GH-OST 和 PT-OSC 工具的应用，CloudCanal 在 MySQL 源端做了大量优化，完满的适配并优化了 GH-OST 和 PT-OSC 的 Online DDL 能力

同步长期表数据

GH-OST 和 PT-OSC 工具都有一个独特的特点，其原理都是采纳长期表的形式来保障 DDL 与 DML 的并发操作。

CloudCanal 默认的表订阅模式是只订阅原表，不订阅与原表相干的长期表（订阅表即同步该表的 DDL 与 DML 语句），而 CloudCanal 为了满足对 Online DDL 工具的反对，在源数据端配置上新增了 extraDDL 参数来实现对长期表的订阅。

  • extraDDL 参数：

    • 可选参数：NONE / GHOST / PT
    • 作用：抉择 NONE 则不订阅任何长期表，抉择 GHOST / PT 则订阅相应的默认长期表

CloudCanal 针对长期表订阅采纳的是两种模式：主动订阅长期表模式和主动同步元数据模式

  • 主动订阅长期表：CloudCanal 会主动依据 extraDDL 参数将默认的长期表退出到订阅表汇合中，随后读取 binlog 日志时将不会过滤掉长期表的所有变更事件，保障了对端数据源表构造与数据的最终一致性
  • 主动同步元数据：CloudCanal 会主动过滤长期表，在读取 binlog 日志时不会执行 Online DDL 的操作，在 Online DDL 执行结束后发送最新的表构造，期间的 DML 语句也会同步发送到对端，保障对端数据源表构造与数据的最终一致性

因为各数据源对同步数据的生产并不相同，如音讯队列只须要解析 Online DDL 后的表构造即可，无需订阅长期表，因而咱们须要依据对端数据源的生产模式做出不同的解决。

DDL 解析与转换

不同数据源的 DDL 语句会有所差别，CloudCanal 对不同数据源 DDL 语句的解析和转换做了大量的优化。

  1. 解析：将 DDL 语句解析为操作类型，如 CREATE，DROP，ALTER 等
  2. 拆分过滤：若 DDL 语句不为单条操作，则拆分为多条 DDL 语句，依据订阅表汇合和 binlog 位点记录过滤反复执行的 DDL 语句与去除无需同步的语句后，从新合成新的 DDL 语句
  3. 转换：将过滤好的 DDL 语句转换为对端数据源的方言

下图演示了 CloudCanal 对 DDL 语句的一些解决:

容错机制

当 CloudCanal 在同步 Online DDL 时，工作有可能在两个层面上被中断：Online DDL 工具层面和 CloudCanal 工作层面

  • Online DDL 工具中断：因为 PT-OSC 和 GH-OST 的原理不同，Online DDL 过程中断的复原计划也有所不同

    • PT-OSC：Online DDL 过程中呈现异常中断，从新执行 Online DDL 操作会抛弃之前的所有操作，从头开始再次执行
    • GH-OST：Online DDL 过程中呈现异常中断，从新执行 Online DDL 操作会读取 ghc 日志心跳表，从日志中的未实现位点开始继续执行。在此过程中，CloudCanal 只需读取 binlog 日志，照常执行 Online DDL 的所有操作即可保证数据的最终一致性
  • CloudCanal 工作中断：因为 CloudCanal 良好的异步生产个性，CloudCanal 的工作中断与 Online DDL 的执行并不相干。当 CloudCanal 工作中断后，重启工作会依据位点记录继续执行 binlog 日志中的事件，保障了数据的最终一致性。

应用示例

前置条件

  • 装置 GH-OST
  • 登入 CloudCanal SaaS 版，应用参见 疾速上手文档
  • 筹备一个 MySQL 数据库，对端数据库（以 MySQL -> MySQL 为例）
CREATE TABLE `ghost_test`.`abc` (
  `id` int NOT NULL,
  `name` varchar(30) DEFAULT NULL,
  `cdata` datetime DEFAULT NULL,
  `udata` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
  • 登录 CloudCanal 平台，增加源端与指标端数据源

工作创立

  • 工作治理 -> 工作创立。
  • 测试连贯 并抉择 源 和 指标 数据库。
  • 抉择增量同步工作和须要订阅的表与字段，并创立工作
  • 增量工作中，性能列表 -> 参数批改 -> 源数据源配置 -> 参数 extraDDL 设置为 GHOST

创立并且启动工作，当工作失常执行到增量阶段时，此时咱们能够利用数据生成工具和 Online DDL 工具对源端数据库触发一些增量 DML 变更和 DDL 变更，而后查看 CloudCanal 是否能失常实时同步这些 DML 和 DDL 事件。

应用 Online DDL 工具批改表构造

  • 首先应用数据生成工具实时随机生成数据，增删改比例为（4：4：3）
  • 在大量写入数据的同时，应用 GH-OST 工具执行 DDL 语句：ALTER TABLE ADD COLUMN aaa VARCHAR(30) NOT NULL AFTER id。在咱们的测试例子中，有 DML 语句的同时应用 GH-OST 执行 DDL 语句，源端总计写入 14147 条数据和 1 条 DDL。
[root@zjx local] ./gh-ost --debug --user="{数据库用户名}" --password="{数据库明码}" --host="{数据库主机 IP}" --port="{数据库端口号}" --database="ghost_test" --table="abc" --initially-drop-ghost-table --initially-drop-old-table --allow-on-master --alter="ADD COLUMN aaa varchar(30) NOT NULL AFTER id" --execute

确认同步后果

CloudCanal 会主动实现源端实时 DML 和 DDL 事件的同步，在执行完源端事件写入之后，咱们确认下同步后果。

  • 更改后的源对端 表构造统一

  • 源对端进行数据校验 数据统一

总结：由上可知，在 CloudCanal 中应用 GH-OST 工具执行 Online DDL 指令，源表实现表构造批改后，CloudCanal 将源表的表构造胜利同步到了指标端数据表中。

常见问题

CloudCanal 反对的同步链路

目前 CloudCanal 反对应用 Online DDL 工具的链路为：

  • MySQL -> MySQL
  • MySQL -> PostgreSQL
  • MySQL -> Greenplum
  • MySQL -> Kafka
  • MySQL -> RocketMQ
  • MySQL -> RabbitMQ

不反对同步的 DDL 语句

应用 Online DDL 工具执行的 DDL 语句中 不反对 RENAME 原表与长期表的操作，如上述用例中，ALTER 语句若改为 RENAME TABLE ghost_test.abc TO ghost_test.ccc，那么 Online DDL 工具后续的 RENAME TABLE ghost_test.abc TO ghost_test._abc_del, ghost_test._abc_gho TO ghost_test.abc 操作就会失败，以致 Online DDL 操作失败。

总结

本文次要介绍了 Online DDL 工具的应用并展现了 CloudCanal 对 Online DDL 工具的实时同步能力，得益于 GH-OST、PT-OSC 优良的表构造批改性能和 CloudCanal 弱小的同步能力，根本能满足企业在日常执行 DDL 的业务中，数据表的 DML 执行和数据同步性能要求

正文完
数据库
发表至： 数据库
2022-12-30
 0
关于存储:Nacos配置安全最佳实践
关于数据库:KaiwuDB-荣获稀土掘金引力榜年度最佳实践案例
关于数据库:十二载征程犹未止看今朝星光尽闪耀丨万字长文回顾2023数据技术嘉年华
关于数据库:程序员科普时间Kafka-不是数据库