Binlog 服务介绍

Binlog 服务能收集 OceanBase 数据库的事务日志，并将其转换为 MySQL Binlog，主要用于实时数据订阅等场景。

背景信息

在 MySQL 中，Binlog 作为实现数据订阅的起点，用户可以以较低的性能消耗来开启 Binlog 日志，从而实现诸多的下游业务场景。

OceanBase 数据库 Binlog 服务兼容 MySQL Binlog，因此支持用户复用现有的针对 MySQL Binlog 的增量解析系统来同步 OceanBase 数据库 MySQL 模式的增量数据，无需做二次开发或搭建一套新环境。Binlog 服务与 MySQL Binlog V4 版本协议保持对齐，具备同样的功能（如支持多个订阅连接）、特性（如支持 GTID 拉取模式），以及保障 Binlog 日志中数据的唯一性。您可以无缝使用原本基于 MySQL 的增量数据订阅方案，并切换到 OceanBase 数据库上来。

产品须知

涉及组件

OceanBase Binlog 服务主要由以下三部分组成：

• OceanBase 数据库：需要生成 Binlog 日志的业务数据库。
• OceanBase 数据库代理：业务数据库的 ODP（也称 OBProxy），由它为订阅 Binlog 的客户端提供连接服务。
• OceanBase Binlog 工具：OceanBase Binlog 服务的核心组件 obbinlog（原 oblogproxy），由它完成拉取 clog 和生成 Binlog 日志的操作。

在本产品文档中，将使用 Binlog 服务指代整个 OceanBase Binlog 服务整体，以 obbinlog 指代 OceanBase Binlog 工具。

企业版与社区版

OceanBase Binlog 服务有企业版和社区版，两者在整体架构和功能实现上几乎没有差别，因此本产品文档涉及的 MySQL 兼容性、命令操作和监控指标等内容，对于 Binlog 服务的企业版和社区版两者都适用。区别只在于两点：

1. Binlog 服务企业版只能用于企业版的 OceanBase 数据库，Binlog 服务社区版也只能用于社区版的 OceanBase 数据库。
2. Binlog 服务企业版在公有云环境主要以云服务的形式提供给公有云 OceanBase 数据库的客户，其他环境需要联系 OceanBase 支持人员获取程序包进行安装部署。Binlog 服务社区版完全依托于开源组件，用户可以自主下载程序包进行安装部署。

如果您是 OceanBase 数据库企业版的用户，请您根据实际情况获取相应的支持：

• 公有云环境：请参考文档 Binlog 服务 开通和使用 Binlog 服务。
• 专有云等其他环境：请联系 OceanBase 技术支持人员。

版本适配

当前 obbinlog 社区版的版本适配情况见 版本发布记录。

架构介绍

基本概念

Binlog 集群

Binlog 集群是由一个或多个 Binlog Server 组成的统一的对外服务，在 Binlog 集群中存在多台 Binlog Server 的场景下，租户 Binlog 服务启动时，将根据负载均衡的逻辑选择合适的 Binlog Server；当任意一台 Binlog Server 故障时，将由其他正常的 Binlog Server 接管其 Binlog 服务。

Binlog Server

Binlog Server 即一个 Binlog 服务节点，其主进程（对应架构图中的 OBM）主要负责处理 SQL 请求和管理节点上 Binlog Instance。多个 Binlog Server 间经由 MetaDB 实现信息共享。

Binlog Instance

Binlog Instance 是租户粒度的 Binlog 实例（对应架构图中的 OBI），负责生成 Binlog 日志以及发送 Binlog 日志，同时根据 MySQL 协议开启 TCP 监控处理 SQL 请求。一个 OceanBase 数据库 Binlog 实例可类比于一个 MySQL 实例，同一租户的多个 OceanBase 数据库 Binlog 实例可类比于 MySQL 主备实例，支持处理 MySQL Binlog 相关的 SQL、协议和变量，例如 SHOW MASTER STATUS 等。

集群高可用

Binlog 服务在创建 Binlog 实例时，会根据 Binlog Server 节点的负载以及创建语句中的配置来选择出一个 Binlog Server 节点，将该创建任务交由该节点完成。选择逻辑如下图所示

该策略的目的是尽量保证租户的多 OBI 实例负载到不同节点上。要点包括：

• 如果用户的创建命令中指定了 IP、Zone 或 Group，Binlog 集群会将会将 OBI 实例负载到此类节点上。

• 打散 OBI 实例到不同节点上，优先选择无 OBI 实例的可用区与节点。

• 对节点的资源水位进行检查：CPU、内存与磁盘小于阈值要求，同时满足最小内存与磁盘要求。

为了降低故障恢复的时间，我们建议用户在创建 OBI 时，将实例副本数指定为大于或等于 2，这样在新建 Binlog 任务时，集群在启动主 OBI 之外，还会同时启动至少 1 个冗余 OBI。根据负载均衡策略，这些 OBI 会优先打散到不同节点上。当有 OBI 发生故障时，系统自动尝试恢复该 OBI。如果故障发生在主 OBI，系统会在恢复的同时，选择一个冗余 OBI 为新的主 OBI，并将后续的会话切换到新的主 OBI 上。

功能说明

OceanBase 数据库 MySQL 模式的 Binlog 协议与 MySQL Binlog V4 版本协议基本保持一致，因此其基础特性与 MySQL Binlog 协议相差无几，具体说明如下：

• 仅支持生成 Row-based Replication（RBR）格式的 Binlog 日志。

• 根据 OceanBase 数据库 MySQL 模式租户的租户级 clog 来生成 Binlog 日志。

• 仅支持生成部分和记录变更有关的 Binlog event 而非所有的 Binlog event 都支持，即 Format_desc、Previous_gtids、Rotate、Gtid、Query、Table_map、Write_rows、Update_rows、Delete_rows 事件类型。

• 支持 GTID 模式。

• 支持 Binlog 事件断点续传，保证无重复无丢失。

• 支持将 OceanBase 数据库增量 DDL 转换为 MySQL 原生语法。

限制说明

兼容性

Binlog 服务对 MySQL 的兼容情况，请参考 兼容性说明。

性能

Binlog 的转换服务的性能受资源配置和 clog 解析能力的限制，目前测试得到的数据如下：

• Binlog 支持的 clog 日志解析最大性能为 25MiB/s

• Binlog 每秒转换率（RPS）的上限约为 50,000

如果订阅的数据源的业务流量超过这些限制，可能会导致 Binlog 转换服务的延迟增加。

在业务压力可控的情况下，Binlog 转换服务的延迟通常可以维持在 1 秒以内。然而，在特殊情况下，如数据库存在频繁的数据定义语言（DDL）操作或大型事务，无法保证绝对的秒级转换延迟。

下游生态对接现状

存量数据同步说明

Binlog Service 只提供增量数据同步服务，但 OceanBase 数据库 MySQL 模式的数据同步到下游，可能也会涉及到存量数据的同步。下述对存量同步阶段的一些常见项进行说明：

• 只支持增量快照读的方式。

• 不支持锁表快照表、FLUSH TABLES WITH READ LOCK。

• 支持设置 MySQL 类型 interactive_timeout、warning_count 超时时间参数。

• 支持设置 heart.interval 心跳超时参数。

• 支持并行拉取存量数据，若 MySQL 同步组件具备该能力。

下游生态对接工具说明

支持主流的 MySQL Binlog 解析生态工具（例如 Flink MySQL CDC、Canal、MaxWell）对接 Binlog 服务。