全部产品

组件基本原理

本文为您介绍 OceanBase 迁移服务(OceanBase Migration Service,OMS)包含的组件。

OMS 内部主要包含以下组件:

结构迁移核心组件

OMS 结构迁移的核心组件(DBCat)作为 OceanBase 原生的 Schema 转换引擎,可以根据源端、目标端具体的数据源类型和字符编码类型,进行精确的数据类型映射或转换。OMS 的结构迁移组件支持转换、迁移数据库中的表、约束、索引和视图等多种对象。

同时,DBCat 可以严格对齐和兼容 OceanBase 的租户类型。例如,OceanBase 的某个版本暂时不支持源端数据库中的部分数据源类型,DBCat 会选择最接近且兼容度最高的数据类型进行转换映射。

全量数据流和数据校验组件

全量数据流模块(Dataflow)负责源库存量数据的迁移,以及迁移后的全字段校验。为了扩展灵活性和充分复用组件,Dataflow 自下而上分别是 Reader 模块、Writer 模块、Broker 模块和统一数据模型层:

  • Reader 模块:负责从源端读取数据,每一种数据库类型都有对应的 Reader 插件。Reader 插件根据统一数据模型层转换读取的记录后,将其放入 Broker 模块中,由其它模块消费。

  • Writer 模块:从 Broker 模块订阅某张表的记录,根据每个 Writer 插件的类型,将记录按照统一数据模型层转换为适配下游的插入语句后,写入下游。

  • Broker 模块:用于解耦 Reader、Writer 或其它模块,以提升性能。解藕后,上下游模块可以相互独立,便于维护和扩展。

  • 统一数据模型层:各组件间通过 Broker 要实现解藕,还需要有一层统一数据模型。数据从 Reader 写入 Broker 时需要先按统一数据模型转换,从 Broker 获取数据记录后,也需要由记录的统一数据模型转化为下游适配的对象或语句。

在上述底层模块的基础上,OMS 实现了数据的迁移、校验和订正。

迁移数据时,您需要在配置好源端、目标端、待迁移表和库表映射等关键信息后,为每张迁移表创建一条 Reader > Broker > Writer 的通道,再由上层迁移程序对每张表的迁移进行调度。您可以并发迁移多张表,在 Reader 和 Writer 组件中可以并发执行每张表的迁移。

进行数据校验和订正时,您需要在配置好源端、目标端、待迁移表和库表映射等关键信息后,为每张校验的表创建 SrcReader > Broker > DstReader 和 Broker > Verifier 的校验通道。

日志读取组件

不同类型数据库的日志读取模块(Store)的实现方式不同,例如 OceanBase Store 模块的实现方式是依赖于 OceanBase 的 Liboblog 工具。

Lliboblog 是 OceanBase 的增量数据同步工具,通过 RPC 方式拉取 OceanBase 各个分区的 Redo 日志后,结合各个表和列的 Schema 信息,转换 Redo 日志为中间定义的数据格式,最后以事务的方式输出修改的数据。

同步写入组件

同步写入模块包括 JDBCWriter 和 Connector:

  • 同步写入模块(JDBCWriter)是从日志读取模块(Store)拉取增量数据的同时,将其翻译为 INSERTUPDATEDELETE 等 SQL 语句写入数据至目标端的组件。

    Store 组件记录的是流式的增量数据,可以通过 Pipeline 保证数据的有序性。Writer 组件单线程顺序执行事务可以满足基本要求,但不能扩展性能,所以 OMS 引入并发写机制。

    在提升同步性能的同时,还需要保证数据的一致性,所以 OMS 引入冲突矩阵机制实现乱序并发写入,以确保每个事务的最终一致性。

    为了避免循环复制问题,所有通过 OMS 的 JDBCWriter 模块写入的数据都会在 Store 组件中进行打标处理,以确保不会再次被其它模块消费。

  • 同步写入模块(Connector)是将 JDBCWriter 的功能插件化,包括源端(Source) 和目标端(Sink) 插件。以同步 OceanBase 数据至 Kafka 为例,在数据同步过程中,OB-Store-Source 为源端插件,Kafka-Sink 为目标端插件。

    Connector 的优势如下:

    • 可扩展性强,源端和目标端可以进行组合。

    • 方便统一同步任务资源的管理、监控和运维。

    • 作为统一中间层,将不同源端的 Record 格式进行结构化,便于实现 Record 的 Filter 和 Transformer 等功能。