OBLogProxy 在 Binlog 模式下的故障案例解析
OBLogProxy 在 Binlog 模式下的故障案例解析
爱可生开源社区
发布于 2025-03-06 23:15:09
发布于 2025-03-06 23:15:09
代码可运行
运行总次数：0
代码可运行
作者：郑增权，爱可生 DBA 团队成员，OceanBase 和 MySQL 数据库技术爱好者。
爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
本文约 1600 字，预计阅读需要 6 分钟。
1背景
某客户原有数据分析系统链路如下：
XXDB -> Flink CDC -> Doris
在客户明确仅替换数据源的前提下，将 XXDB 替换为 OceanBase（社区版），改造链路如下：
OceanBase -> OBLogProxy -> Flink CDC -> Doris
- OceanBase（数据源）：作为原生分布式数据库，解决传统数据库单机容量限制问题。其数据变更日志（如DDL/DML）由 OBLogProxy 组件捕获，为下游增量同步提供基础。
- OBLogProxy（日志代理服务）：OceanBase 的日志代理组件，负责从 OceanBase 集群拉取增量日志（如事务日志、Binlog），并将其转化为有序的变更数据流。
- Flink CDC（实时数据同步）：通过 Flink CDC Connector 连接 OBLogProxy，实现全量+增量数据的一体化同步。
- Doris（实时分析数据库）：通过 Flink 的 Doris Connector 将处理后的数据流写入 Doris 表，完成 AP 任务。
注意版本兼容性：需确保 OceanBase、OBLogProxy、Flink CDC 的版本匹配。
OBLogProxy 的 Binlog 模式
Binlog 模式[1] 为兼容 MySQL binlog 而诞生，支持现有的 MySQL binlog 生态工具来同步 OceanBase。现有的 MySQL binlog 生态工具可以平滑切换至 OceanBase 数据库。
由下图可以看出，Binlog 模式需要与 OceanBase 数据库（需配置 obconfig_url）和 OBProxy 来一起配合使用，具体步骤请参考官方文档。
OBLogProxy 的 Binlog 模式工作流程
改造完成后，业务人员开始进行链路使用测试。发现链路下游无法读取新增数据，怀疑是 OBLogProxy 存在问题。
2排查过程
- 查看 oblogproxy 查看状态，登录后确认为异常状态（后续观察得知是安装的虚拟机配置过低导致）。
MySQL [(none)]> show binlog instances\G
*************************** 1. row ***************************
name: evan_cluster#tenant_evan
ob_cluster: evan_cluster
ob_tenant: tenant_evan
ip: 10.186.64.164
port: 2983
zone:
region:
group:
running: No
state: Running
obcdc_running: No
obcdc_state: Running
service_mode: disabled
convert_running: No
convert_delay: NULL
convert_rps: NULL
convert_eps: NULL
convert_iops: NULL
odp_addr: NULL
1 row in set (0.00 sec)
- 启动 oblogproxy 进程，状态正常。
[root@oblogproxy-server oblogproxy]# ./run.sh start
MySQL [(none)]> show binlog instances\G
*************************** 1. row ***************************
name: evan_cluster#tenant_evan
ob_cluster: evan_cluster
ob_tenant: tenant_evan
ip: 10.186.64.164
port: 2983
zone:
region:
group:
running: Yes
state: Running
obcdc_running: Yes
obcdc_state: Running
service_mode: enabled
convert_running: Yes
convert_delay: NULL
convert_rps: NULL
convert_eps: NULL
convert_iops: NULL
odp_addr: NULL
1 row in set (0.00 sec)
- 进入 binlog 存放目录，确认产生了新的 binlog 文件。
此时，开发人员反馈，还是无法读取到新增的数据，继续排查。
- 登录 OceanBase 的 MySQL 业务租户，手动建表并插入几条数据。
MySQL [evan_db]> CREATE TABLE `evan_test` (
-> `id` int(11) NOT NULL,
-> `name` varchar(10) DEFAULT NULL,
-> `country` varchar(100) DEFAULT NULL,
-> `age` int(10) DEFAULT NULL,
-> PRIMARY KEY (`id`)
-> ) ;
Query OK, 0 rows affected (0.05 sec)
MySQL [evan_db]> INSERT INTO evan_db.evan_test (id,name,country,age) VALUES (1,'test','China', 18);
Query OK, 1 row affected (0.01 sec)
MySQL [evan_db]> INSERT INTO evan_db.evan_test (id,name,country,age) VALUES (2,'test','China', 19);
Query OK, 1 row affected (0.00 sec)
MySQL [evan_db]> INSERT INTO evan_db.evan_test (id,name,country,age) VALUES (3,'test','China', 20);
Query OK, 1 row affected (0.00 sec)
MySQL [evan_db]> INSERT INTO evan_db.evan_test (id,name,country,age) VALUES (4,'test','China', 21);
Query OK, 1 row affected (0.00 sec)
- 执行
show master status，显示当前的 binlog 文件号是mysql-bin.000227。 - 在 mysql-bin.000227 文件中检索关于表
evan_test的信息，结果为空。 - 解析 mysql-bin.000227 文件的起始时间为
250124 15:39:07 ～ 250206 6:42:49，我们执行 SQL 的时间大约是250219 17:46。
[root@oblogproxy-server data]# mysqlbinlog -vv mysql-bin.000227 | head | grep '#'
# at 4
#250124 15:39:07 server id 1147473732 end_log_pos 123 CRC32 0xc09acde6 Start: binlog v 4, server v 5.7.38 created 250124 15:39:07 at startup
[root@oblogproxy-server data]#
[root@oblogproxy-server data]# mysqlbinlog -vv mysql-bin.000227 | tail | grep '#'
# at 268435740
#250206 6:42:49 server id 1147473732 end_log_pos 268435771 CRC32 0x9d678efb Xid = 245853
# at 268435771
#250206 6:42:49 server id 1147473732 end_log_pos 268435818 CRC32 0xe056957f Rotate to mysql-bin.000228 pos: 4
# End of log file
- 查看 binlog 文件连续性。
mysql-bin.000110 的生成日期是 Dec 3 （2024-12-03），而 mysql-bin.000111 的生成日期是 Feb 19 （2025-02-19）。可知 binlog 生成的时间存在断档。
-rw-r--r--. 1 root root 524336507 Dec 3 13:02 mysql-bin.000109
-rw-r--r--. 1 root root 524288421 Dec 3 16:48 mysql-bin.000110
-rw-r--r--. 1 root root 287303474 Feb 19 13:59 mysql-bin.000111
-rw-r--r--. 1 root root 524308964 Feb 19 14:00 mysql-bin.000112
查看 mysql-bin.000111 文件可知，该 binlog 开始时间是 241203 16:48:57。换言之，2025-02-19 启动 OBLogProxy 之后，bc 子模块接着将 241203 异常中断的 redo log 解析为 binlog。此时我们看到的 binlog 并不是最新的 binlog，而是在持续解析之前积压的 redo log。
[root@oblogproxy-server data]# mysqlbinlog -vv mysql-bin.000111 | head
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#241203 16:48:57 server id 1147473732 end_log_pos 123 CRC32 0x5624326b Start: binlog v 4, server v 5.7.38 created 241203 16:48:57 at startup
我们需要先等待其持续转换。
- 次日，查看最新的 binlog 已是当前对应的时间，且包含昨日对
evan_test表测试的时间点。
[root@oblogproxy-server data]# mysqlbinlog -vv mysql-bin.000232 | head | grep '#'
# at 4
#250219 5:34:39 server id 1147473732 end_log_pos 123 CRC32 0x93f94d4d Start: binlog v 4, server v 5.7.38 created 250219 5:34:39 at startup
# Warning: this binlog is either in use or was not closed properly.
[root@oblogproxy-server data]#
[root@oblogproxy-server data]# mysqlbinlog -vv mysql-bin.000232 | tail | grep '#'
### @12=NULL /* VARSTRING(256) meta=256 nullable=1 is_null=1 */
### @13=NULL /* VARSTRING(256) meta=256 nullable=1 is_null=1 */
# at 82580399
#250220 14:44:57 server id 1147473732 end_log_pos 82580430 CRC32 0xdd27266f Xid = 666001
# End of log file
- 在最新的 binlog 中再次检索昨日插入的关于
evan_test的信息，可查到昨日插入的几条新数据。
[root@oblogproxy-server data]# mysqlbinlog -vv mysql-bin.000232 | grep -i "evan_test"
CREATE TABLE `evan_test`(
#250219 17:46:16 server id 1147473732 end_log_pos 26518460 CRC32 0x6c4f4ad0 Table_map: `evan_db`.`evan_test` mapped to number 127
### INSERT INTO `evan_db`.`evan_test`
#250219 18:10:14 server id 1147473732 end_log_pos 28283904 CRC32 0xc16b1f30 Table_map: `evan_db`.`evan_test` mapped to number 127
### INSERT INTO `evan_db`.`evan_test`
#250219 18:10:20 server id 1147473732 end_log_pos 28290056 CRC32 0xcf0ed889 Table_map: `evan_db`.`evan_test` mapped to number 127
### INSERT INTO `evan_db`.`evan_test`
#250219 18:10:25 server id 1147473732 end_log_pos 28290674 CRC32 0x71220455 Table_map: `evan_db`.`evan_test` mapped to number 127
### INSERT INTO `evan_db`.`evan_test`
通知业务人员测试，反馈已经可以正常读取增量数据。
3结论
造成下游读取增量数据失败的原因是 OBLogProxy 异常导致了解析 clog 的进程中断。启动 OBLogProxy 后需要时间拉取此前未解析的 clog 并将其解析为 binlog，这期间下游无法及时读取当前最新变更的数据。
4优化措施
配置关于 OBLogProxy 状态的监控和告警，以便及时发现并处理问题。
参考资料
[1]
Binlog 模式: https://www.oceanbase.com/docs/community-oblogproxy-doc-1000000000861455
本文关键字：#OceanBase# #OBLogProxy# #binlog#
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2025-03-04，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录
腾讯云开发者
