文章/答案/技术大牛

发布

社区首页 >专栏 >带宽被 OBServer 备份 “榨干”，集群陷入 “无主” 危机

带宽被 OBServer 备份 “榨干”，集群陷入 “无主” 危机

爱可生开源社区

发布于 2025-03-12 07:50:05

3700

代码可运行

文章被收录于专栏：爱可生开源社区爱可生开源社区

运行总次数：0

代码可运行

作者：何文超，爱可生南区交付服务部 DBA 团队成员。主要负责 MySQL 故障处理，MySQL 高可用架构改造，OceanBase 相关技术支持。爱好足球，羽毛球。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 800 字，预计阅读需要 3 分钟。

1问题描述

近期，一套 OceanBase 生产环境集群，每天早七点左右都会出现无主告警。同时，业务人员反馈同一时间，业务接口会出现短暂超时的情况。

OCP 告警关键字：“eg leader lease is expired”。

2分析过程

2.1 集群无主常见排查思路

在进行问题排查时（参考 官方文档[1] ），首先要确认当前确实有副本存在无主状态；然后根据如下几种情况进行详细的问题排查：

observer.log 日志有明显的报错信息
时钟偏差
有租户、表或分区被删除
多数派副本宕机
网络问题
Clog 模块恢复日志失败
Load 过高
Clog 盘满

2.2 查看 RS 日志

在 Root Service 日志（RS 节点的 rootservice 日志）中，搜索日志关键字“clock between rs and server not sync”，执行命令：

grep "clock between rs and server not sync" rootservice.log.20240613072655

得到如下结果：

[2024-06-13 07:02:48 575664] WARN [Rs] receive hb (ob server manager.cpp:1045) [71476][640][YB42B6B4E79D-0005EE52EC5FBCAC] [Lt=12] [dc=0] clock between rs and server not sync(ret=-4016, lease request={version:1, zone:"zone2", server:"11.180.231.158:2882",inner_port:2881, build_version:"202207271916220f70bf071、Jcd9399683218b6d9e15a3b530ec(Jul 27 2022 19:47:54)",resource unfo:{cpu: "1.600000000000000000e+02",mem in use:0,al:454190471577, disk_in_use:1227475648512, disk_totat:4648387739648,partit ion_cnt:4711, report_cpu_assigned:"1, 500000000000000000e+02",rep max assianed:"1.500000000000000000e+02",report mem assigned:375809638400, report mem max ass igned:375809638400},start service time:166367153,current server time:1718233366421693,round_trip_time:276, tenant_config_version:[[1,1657331710092989],[1001,1659506961396140]],ssl_kred tume:0, t umeout_partition:0, tenant_max flushed key_vers ion:[], request_lease_time:0}, current_rs_time=1718233368575271))

通过计算时间戳可知，RS 节点和当前节点时钟存在差异：

MySQL [(none)]> select usec_to_time(1718233366421693);
+--------------------------+
| usec_to_time(1718233366421693) |
+--------------------------+
| 2024-06-13 07:02:46.421693 |
+--------------------------+
1 row in set (0.00 sec)

MySQL [(none)]> select usec_to_t ime(1718233368575271);
+--------------------------+
| usec_to_time(1718233368575271) |
+--------------------------+
| 2024-06-13 07:02:48.575271 |
+--------------------------+
1 row in set (0.00 sec)

2.3 查看 observer 日志

查看 observer.log 印证时钟不同步。

grep -i "clock diff time is too large" observer.log.20240613070304

得到如下结果：

[2024-06-13 07:02:10.698178] WARN [SHARE] operator() (ob server b[ackl ist.cpp:106)[16303][2584][YB42B6B4E79D-0005EE5618DF3FA1] [lt=18] [dc=0] [SERVER BLACKLIst] clock diff time is too large, attention!(clockdiff_time=804075, member={server:"11.180.231.158:2882", cluster_id:100005}))

该日志再次印证时钟不同步。由于时钟不同步常见于网络因素，因此开始排查告警时间段的网络带宽压力情况。

经排查发现，NFS 盘的交换机端口负载带宽理论峰值为 1.25GB/S，在备份时间点，带宽已被打满。同时，observer.log 日志中还出现了如下提示：

[2024-06-13 07:05:38.145487] WARN __tg_cleanup (easy_connection.c:2563) [17920][0][Y0-0000000000000000] [lt=6] [dc=0] easy cost too much time: 3505807us send_response: count=1
[2024-06-13 07:05:38.145493] WARN __tg_cleanup (easy_connection.c:1220) [17920][0][Y0-0000000000000000] [lt=5] [dc=0] easy cost too much time: 3505813us on_thread_wakeup: (nil)
[2024-06-13 07:05:38.145467] WARN __tg_cleanup (easy_connection.c:2682) [17897][0][Y0-0000000000000000] [lt=5] [dc=0] easy cost too much time: 4075659us send_session_list: count=1
[2024-06-13 07:05:38.145499] WARN __tg_cleanup (easy_connection.c:1220) [17897][0][Y0-0000000000000000] [lt=30] [dc=0] easy cost too much time: 4075692us on_thread_wakeup: (nil)
[2024-06-13 07:05:38.145499] WARN ev_invoke_pending (ev.c:2137) [17920][0][Y0-0000000000000000] [lt=4] [dc=0] epoll handler too much time :3516150 count=2 malloc=5/2 write=3505746/1 read=0/0 server_process=0/0 client_cb=0/0
[2024-06-13 07:05:38.145500] WARN __tg_cleanup (easy_socket.c:230) [17928][0][Y0-0000000000000000] [lt=12] [dc=0] easy cost too much time(4547689us). loadavg(20.060000, 16.900000, 15.660000), socket write, fd(7137), iov(210/2), conn(0x7e9bab055050).
[2024-06-13 07:05:38.145506] WARN ev_invoke_pending (ev.c:2137) [17897][0][Y0-0000000000000000] [lt=4] [dc=0] epoll handler too much time :4087710 count=2 malloc=5/1 write=4075617/1 read=0/0 server_process=0/0 client_cb=0/0
[2024-06-13 07:05:38.145509] WARN __tg_cleanup (easy_connection.c:2563) [17928][0][Y0-0000000000000000] [lt=7] [dc=0] easy cost too much time: 4547734us send_response: count=1
[2024-06-13 07:05:38.145517] WARN __tg_cleanup (easy_connection.c:1220) [17928][0][Y0-0000000000000000] [lt=7] [dc=0] easy cost too much time: 4547743us on_thread_wakeup: (nil)

这表明 easy 工作线程是共享的，由于备份网络处理繁忙，导致其他 rpc 的处理也受到了影响。

通过命令 grep 'ob_net_easy.cp' observer.log.20240625070148 |awk -F 'request doing=' '{print $2}' 进一步分析，得到了一系列数据（此处省略具体数据展示）。

2.4 查看告警时间段的 tsar 日志

执行命令：

tsar -d 20240613 -i 1

结果显示，网络流出压力是平时的 10 倍左右。

2.5 检查 RPC 消息是否积压

通过以下命令搜索 observer.log，查看 request doing 值是否过大，如果达到千级别，说明 RPC 消息有明显的积压，需要继续排查网络是否异常：

grep 'RPC EASY STAT' observer.log.20240613070304 
grep 'RPC EASY STAT' observer.log.20240613070304 |awk -F 'request doing=' '{print $2}'

得到一系列数据（此处省略具体数据展示），部分值达到千级别，说明存在RPC消息积压。

2.6 检查是否为独立网卡

使用 ip link 和 ifconfig 命令可以显示网络接口的信息。通过查看接口名称、MAC 地址等信息，可以区分不同的网卡。

ip link show 

# 或者
ifconfig -a

每个网卡都会有唯一的接口名称（如 eth0、eth1、ens33、ens34 等）和 MAC 地址。经排查，bond1 和 bond0 为独立网卡。

2.7 检查 observer 是否为万兆网卡

bond0 为业务网卡，bond1 为备份网卡。执行命令：

ethtool bond0

显示 Speed:10000Mb/s，说明 observer 为万兆网卡。

2.8 检查路由地址是否正确

执行命令：

ip route

得到结果：

default via 11.180.167.254 dev bond0
2.4.8.0/24 dev bondi proto kernel scope linksrc 2.4.8.69
169.254.0.0/16 dev bond0 scope link metric 1014
169.254.0.0/16 dev bondl scope link metric  1015