乐趣区

关于数据库:Oracle数据同步的思考与优化CloudCanal核心技术揭秘

jiezi

为什么咱们要重构 Oracle 源端数据同步？

CloudCanal 晚期版本即反对了 Oracle 数据库，围绕 构造迁徙 、 全量迁徙 、 增量同步 三个外围步骤，构建了以 Oracle 数据库为源端的实时数据体系。

但之前的版本，也存在着不少问题，性能、性能、对数据库权限的挑战等方面都有所波及，成了 CloudCanal 产品的一个痛点，看着 MySQL 源端在线数据体系一直狂奔，未免有点落寞。

再者，市场的需要层出不穷

  • “CloudCanal 是否把 Oracle 数据同步到 Kafka?”
  • “CloudCanal 是否把 Oracle 数据同步到 ElasticSearch？”
  • “咱们在做业务重构，你们能做 Oracle 到 Oracle 的数据同步么？”
  • …

为此，咱们下定决心，决定在春夏之交，给 CloudCanal Oracle 源端动一场大手术。

如何优化？

两种实现形式的抉择

最无力的扭转往往来自于某一个特定方向的深刻开掘。

对于老版本 Oracle 源端增量实现的 物化视图 形式（类 trigger）和 LogMiner (Redo 日志解析) , 咱们抉择深度优化 LogMiner，理由有三

  • LogMiner 为 Oracle 官网提供 Redo 日志解析，形式绝对牢靠
  • CloudCanal 实现的 MySQL / PostgreSQL / MongoDB 源端增量都偏差于 操作日志解析，格调统一，组件可共用性概率高
  • 从业界的调研来看，LogMiner 在落地 Oracle 严格 CDC 场景下，体现可圈可点

确定咱们外围谋求的成果

“可继续稳固运行”成为咱们优化的次要指标，这句话的含意可能并非字面所了解，理论蕴含以下几个问题的解决

  • 是否在突发压力下（5000 条数据 / 秒）稳固运行？
  • 是否在超级大事务下 (>1000 万条数据数据勘误) 稳固运行？
  • 是否不中断工作 平滑新增表、缩小表？
  • 是否主动解决源端罕用 DDL 同步 ( 加列 / 改列 / 减列)？
  • 是否反复生产一段时间的增量数据 ( 回拉位点)？

咱们做了哪些事件？

确定了优化方向和指标，接下来事件就绝对好办，咱们从 内核外围逻辑优化 和 产品层面优化 两个方面进行改良。

内核外围逻辑优化

ADD_FILE 模式和 CONTINUOUS_MINE 模式反对

Oracle LogMiner 自身并不是专门为实时 CDC 所设计，商业方向由其商业产品 GoldenGate 扛旗，收费工具层面又有 Oracle CDC 专用组件，然而 LogMiner 次要胜在其被许多前辈所验证，古老且稳固，所以被抉择演变为 Oracle 次要的实时同步组件也并不奇怪。

LogMiner 最原始的应用形式蕴含以下几个步骤

  • DBMS_LOGMNR_D.BUILD (构建解析的字典，可选)
  • DBMS_LOGMNR.ADD_LOGFILE (增加须要解析的 redo 日志)
  • DBMS_LOGMNR.START_LOGMNR (开始解析增量日志)
  • V$LOGMNR_CONTENTS (从此视图中查问解析的增量日志)
  • DBMS_LOGMNR.END_LOGMNR (完结解析)

事实上，这几个命令通过扭转应用组合，增删具体的参数，即可达成增量日志成果，通用的模式即 ADD_FILE 模式，CloudCanal 对这种模式做了大量优化与验证，形成其 Oracle 源端增量同步的 根本盘。

然而上述步骤中，DBMS_LOGMNR.ADD_LOGFILE (增加须要解析的 redo 日志) 因为 Oracle 的日志构造形成，对于细节解决要求较高，如果没解决好，在某些场景下，容易失落数据。

Oracle Redo 日志如下构造

  • online redo log (在线日志)

    • redo04
    • redo05
    • redo06

  • archieved redo log (归档日志)

    • redo log with dictionary start
    • redo log with dictionary end
    • redo log with both dictionary start and end
    • redo log without dirctionary

其中 在线日志 有 2 + 个组 (齐全镜像)，每一个组外面 2/3 个文件进行轮换，在线文件会归档到 归档日志，所有文件通过递增 sequence 维持程序。

请问怎么样往 LogMiner 增加文件不会丢数据也不会反复解析日志？为了简化这个问题，Oracle 为 LogMiner 推出了 CONTINUOUS_MINE，也就是不须要指定日志文件，主动帮你增加，一直吐出新的变更。

不过遗憾的是, Oracle 12.2 deprecated 此项个性，19c 间接去掉了这项能力。

但咱们还是反对了这个能力，在 11 / 12 局部版本可能抉择应用该项能力。

更加实时

两种模式的反对过程中，咱们大大 放大老版本解析 redo 日志的范畴 ，通过位点治理的重构， 杜绝可能的反复增加 已解析过日志文件，另外为了不便运维，DBA 同学可抉择 CloudCanal 定时或相隔时间段构建字典 的能力。

Read Commited 级别可见性

关系型数据库 Redo 文件蕴含简直所有的操作，所以也隐含了数据库对外可见性在日志中，LogMiner 反对只吐出已提交 (commited) 的日志，然而咱们并没有抉择这种形式，起因有四

  • V$LOGMNR_CONTENTS 是一个视图，会话级别，一个大型数据变更，抉择 commited 数据生产将会影响 Oracle 稳定性
  • 一个大型的数据变更，Oracle 期待 commit 再生产会导致大的数据提早
  • CloudCanal 对于超级大事务有刷盘机制，LogMiner 边吐日志边解决，平安且高效
  • 此种机制不阻塞在超级大事务之间并发执行的小事务提交

当日志一直从 LogMiner 后果视图查问进去时，CloudCanal 的内存构造完满重现了一遍 Oracle Read Commit 级别的操作。

大事务反对

CloudCanal 新版本对于源端大事务做了充沛的反对，当单个事务变更数小于固定值 (默认 512 个)，则 全内存操作 ，一旦超过此数值，即 开始刷盘，直到 commit 或 rollback 操作产生，进行后续的生产或者抛弃。

长久化变更操作到硬盘时，咱们采纳了 kyro 序列化 工具晋升压缩比和 cpu 编解码效率，为了让数据序列化 / 反序列化可控，咱们采纳了最牢靠的 自定义序列化器 形式，避免 kryo 通过反射制作各种惨案，将序列化类型 限定在 java 最根底的几种类型 上，让这块代码坚若磐石。

可抉择的字典（ONLINE or IN_REDO）

LogMiner 剖析的 Redo 时，必须蕴含日志的字典信息，否则解析进去的数据相当于乱码，无奈辨认，导致丢数据。可抉择的两种字典类型，存在以下区别。

  • ONLINE : 即以后字典，无奈配置 DDL 参数 DDL_DICT_TRACKING进行历史日志剖析（比方做了 DDL 在表两头加了一个列，DDL 之后的变更能够解析，然而之前的变更可能解析失败）
  • IN_REDO：即以归档日志中存在的字典作为基准，配合 DDL_DICT_TRACKING构建演进的字典，即可做历史日志的解析（无论产生多少个 DDL，每一个事件都能获取到准确的元信息）

CloudCanal 新版本默认采纳 IN_REDO 模式的元数据（依赖字典数据构建），然而也提供了 ONLINE 模式的字典，让增量工作启动更加顺畅(无前置构建字典必要)

更好的 redo 解析器

LogMiner 解析日志生成的外围数据 redo / undo SQL，如果须要失去结构化数据，必须应用 SQL 解析，计划个别有三种

  • Antlr 解析(自定义文法)
  • 纯字符串解析
  • 其余成熟工具解析(如阿里 Druid)

是的，因为老版本代码这部分有参考某驰名开源产品 , 所以咱们应用的是纯字符串解析，痛快没多久，惨案便产生，对于 redo sql 中，业务数据值的变幻无穷，手工解析无疑是一个定时炸弹，所以咱们决定应用 Druid 的 SQL 解析器，起因有三

  • 咱们其余性能有应用 Druid 和她的 SQL 解析器，摸透了她的特点
  • 能找到作者，而且作者 人很 nice
  • 即便最初咱们须要本人保护，难度层面齐全能够承受

常见 DDL 同步反对

对于 DDL 同步，特地是 Oracle 数据库源端增量同步 DDL，国内有一个驰名通信公司共事和咱们说，如果你们反对，咱们就买，因为太烦太痛。
数据同步工具对于 DDL 事件的解决，实际上分为两个局部

  • 更新表元数据，以解析新事件
  • 同步到对端，让源和对端构造保持一致

对于第一项，是肯定要做的事件，否则同步可能中断以及解析增量数据可能出错。对于第二项，咱们的倡议是通过 对立的平台 来做(比方咱们的 CloudDM )，而这个并不是咱们不想或不能，而是因为历史 / 技术的局限性，对端数据库无奈做到疾速的 DDL 变更，导致同步提早或加大同步链路稳定性问题（长时间延迟可能呈现各种不确定事件）。

不过应最终客户的需要，咱们在 CloudCanal 新版本中做到了这两项。其中对端同步到 MySQL 咱们反对

  • ALTER TABLE xxx ADD xxx ;
  • ALTER TABLE xxx DROP COLUMN xxx;
  • ALTER TABLE xxx MODIFY xxx;

搭好了舞台，开了一个好头，后续不断完善。

多版本 schema 以反对位点回拉

对于关系型数据库同步工具而言，增量数据自身往往和元数据拆散，也就是生产到的增量数据和即时从数据库外面获取的元数据不肯定匹配（两个工夫点之间有 DDL)。故维持一个多版本的元数据以应答增量数据解析是刚需。

CloudCanal 以每天的 schema dump 为基准，辅以到以后位点的 DDL 语句列表，可构建出任何工夫点的元数据 (实际上是更加准确的 scn 位点)。单个 DDL 前后的数据变更事件， 可能准确匹配到绝对应的元数据 ，进行解析。所以 CloudCanal 才有可能在此版本产品上提供了 回拉位点反复生产一段时间增量数据 的能力。

更加高效的数据结构

CloudCanal 新版本参考 MySQL 源端增量，将 多个已提交事务批量交付 给写入端进行写入，而针对大事务，提交后 依照参数进行拆分 ，一边从硬盘上 流式读取数据，一边写入对端，平安又高效。

更加正当的存取构造，将数据同步性能由原来的 几百 rps 晋升到 5000+ rps，满足业务突发流量的实时同步需要。

产品层面优化

反对全量数据校验

同步工具如果没有数据校验能力，往往会存在失落数据的危险。显性层面 体现为是否有 数据校验性能 ，而 隐性层面 体现为是否做过 多样化数据场景构建和数据校验。

  • 测试的时候有多少张表？
  • 单表并发多少？
  • 单事务操作数多少？
  • 操作品种和比例多少？
  • 跑了多长时间？
  • 有没有暴力 kill ?
  • 极限硬件测试(资源无限，压力大)?

CloudCanal 新版本对于 Oracle 源端链路补足了此项能力，几百万、上千万条数据中，一条脱漏、一个字段不统一都逃不过 数据校验。在交付用户 / 客户应用前，咱们曾经做了这些事件。

反对 Oracle 源端的工作编辑

业务方 a 给 DBA 提了一个需要，心愿把数据库 A 中表 1、2、3 配置同步到 Kafka 中，DBA 同学顺利完成工作。过了一些天，业务方 b 又给 DBA 提了另外一个需要，将数据库 A 中表 4、5、6 配置同步到 Kafka 中。这个时候，DBA 有两种抉择

  • 编辑下业务方 a 的工作，加 4、5、6 表进去，历史数据怎么办？
  • 新开一个工作，占新机器资源、占新数据连贯、一直减少的运维老本？

CloudCanal 提供了 平滑编辑订阅 的能力，如新增表，则 生成子工作，可抉择做全量迁徙，待增量追上主动合并到主工作一起同步。

反对 Oracle 源端心跳工作

当 Oracle 一段时间齐全没有变更，如何确定是工作真的提早还是没有流量？CloudCanal 新版本参考 MySQL 源端，通过参数配置，关上心跳开关，配置好变更语句和执行距离，即可主动进行定时变更。精确辨认提早是因为上游不行还是 Oracle 没量。

更加清晰的监控指标

新版本的 CloudCanal 对于 Oracle 源端新增了两个监控指标，V$LOGMNR_CONTENTS 查问速率 能精确察看 LogMiner 解析效率，内存中未提交事务数 能扼要判断后端生产和解析的压力，某些状况下还能准确断定 LogMiner 否吐完数据。

放大的数据库权限要求

CloudCanal 对 Oracle 数据库的高权限要求，次要来自两个面向 DBA 的操作，主动构建字典 和 主动切换归档日志 , 这两个操作初心比较简单，让用户应用更加自动化和便当，然而问题也比拟显著，对数据库运维规范严苛的客户来说，这些操作在某些状况下是不可承受的。
所以新版本 CloudCanal，通过参数配置，反对了 敞开主动字典构建能力（默认关上）和 敞开主动切换归档日志能力（默认敞开）。用户在敞开这些性能时，可能晓得必须辅以哪些运维操作，能力让 CloudCanal 失常运行。

其余的性能和修复

通用能力方面，咱们此次关上了创立 Oracle 源端工作 反对数据过滤条件 的性能，然而语法仍然仅限于 SQL92 的无限语法范畴内，和 MySQL 等其余源端数据源共用一套数据过滤零碎。

自定义代码能力 对于业务重构、新老零碎替换是神器，新版本 CloudCanal 将这个能力关上，它仍然和 MySQL 作为源端、PostgreSQL 作为源端，放弃能力的一致性，数据过滤、打宽表、字段值变换、操作变动一样不少。
BUG 修复层面，新版本 修复了 Oracle 远端全量迁徙进度不准问题 ， 构造迁徙类型映射不精确问题。

“术后”成果如何？

“术后”成果，咱们须要答复文章开始之时提出的一些问题。

  • 对于是否在突发压力下（5000 条数据 / 秒 ）稳固运行？咱们通过 高效的数据结构 ， 可调整内存参数阈值 优化，根本达到目标（还有晋升空间）。
  • 对于是否在超级大事务下 (>1000 万条数据数据勘误) 稳固运行？咱们通过 非 commit 数据接管模式 ， 大事务反对 ， 边获取边写入 三个办法解决问题。
  • 对于是否不中断工作 平滑新增表、缩小表 ？咱们通过反对 编辑订阅 达到目标。
  • 对于是否主动解决源端罕用 DDL 同步 ( 加列 / 改列 / 减列 )？咱们通过 多版本 schema 治理，DDL 转换与同步 两个办法联合解决。
  • 对于是否反复生产一段时间的增量数据 ( 回拉位点 )？咱们通过反对 多版本 schema 治理 ， 页面位点重溯性能 解决。

咱们还将会围绕 Oracle 做些什么？

更多的对端数据源

目前 CloudCanal 源端为 Oracle , 则对端反对 PostgreSQL、Greenplum、MySQL、TiDB、Oracle、Kudu、StarRocks、OceanBase、Kafka 数据源，咱们在期待解决这些链路可能存在的问题同时，也心愿反对更多对 Oracle 在线数据生态无益的对端数据源，比方 ElasticSearch、ClickHouse、MongoDB 等

摸索和其余数据源（如 MySQL）的双向同步可能性

Oracle 是否存在双向同步的可能性，对于很多业务来说，具备很强的实用性，咱们心愿可能摸索出一条成熟相似 MySQL<->MySQL 之间双向同步的计划。Oracle <-> MySQL（Oracle）双向同步，咱们置信对很多用户来说很香。

物化视图（trigger 形式）优化

CloudCanal 目前另外一种 Oracle 增量计划 - 物化视图，是一种 权限要求低 、 版本覆盖度好 的解决方案，在此次优化中，咱们并没有把它列入优化能力点，在后续的一些我的项目中，咱们心愿可能将此计划也可能优化好，具备不错的场景适用性。

问题修复

问题修复是咱们始终要做的工作，也凭仗各位用户 / 客户宽泛 流传 、 应用 、 反馈。积淀到咱们的社区论坛 /issue 中，咱们将会一轮一轮优化，将产品推向极致。

总结

Oracle 迁徙同步，用 CloudCanal 就够了。如果你心愿更加深刻理解 CloudCanal 也能够通过官网分割咱们，退出咱们的社区群，独特构建弱小的在线数据生态网络。

退出 CloudCanal 粉丝群把握一手音讯和获取更多福利，请增加咱们小助手微信：suhuayue001
CloudCanal- 收费好用的企业级数据同步工具，欢送品鉴。
理解更多产品能够查看官方网站：http://www.clougence.com
CloudCanal 社区：https://www.askcug.com/

退出移动版