带宽被 OBServer 备份 “榨干”，集群陷入 “无主” 危机
带宽被 OBServer 备份 “榨干”，集群陷入 “无主” 危机
爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
本文约 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
结论：路由地址正确。
综上所述：可以判断是因为每日备份导致网络带宽打满，从而引起时钟同步异常，进而导致原主的租约过期，最终出现无主情况。
3解决方案
3.1 扩容带宽
可通过增加网络带宽的方式，缓解备份时的网络压力，避免因带宽不足导致的各种问题。
3.2 备份限速
backup_net_limit：该参数为 0 时，表示不对备份带宽做限速。目前研发侧此功能尚未实现。
backup_concurrency：系统会根据当前资源进行自动适配（配置为 0 时，默认值为 10）。
建议将其配置为 1，这样备份时间会拉长。但修改为 1 后，集群无主的问题得到了改善。
sys_bkgd_net_percentage：用于设置后台系统任务可占用网络带宽百分比。不建议调整此参数，因为调整后整个 observer 都会限流，不单单是备份。
参考资料
[1]
无主问题排查: https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000360700
本文关键字：#OceanBase# #带宽# #时钟#
腾讯云开发者
