5.6 如何快速处理 OceanBase 数据库故障

如何定位判断 OceanBase 数据库故障

当 OceanBase 数据库故障时，应用端会反馈有很多报错信息。此时需要初步判断应用是全部失败，还是部分失败。

理论上 OceanBase 数据库局部节点故障时，应用只会是局部数据库读写故障或者中断，在 1 分钟左右应用就能全部恢复。同时需按以下步骤尽快确认 OceanBase 集群的状态。

1. 确认集群节点状态

   select a.zone,concat(a.svr_ip,':',a.svr_port) observer, cpu_total, (cpu_total-cpu_assigned) cpu_free, round(mem_total/1024/1024/1024) mem_total_gb, round((mem_total-mem_assigned)/1024/1024/1024) mem_free_gb, usec_to_time(b.last_offline_time) last_offline_time, usec_to_time(b.start_service_time) start_service_time, b.status, usec_to_time(b.stop_time) stop_time 
   from __all_virtual_server_stat a join __all_server b on (a.svr_ip=b.svr_ip and a.svr_port=b.svr_port)
   order by a.zone, a.svr_ip
   ;

   您需关注：

   • 节点状态 status：升级前没有 inactive 值，升级过程中会有。

   • 节点服务时间 start_service_time：是否是默认值（1970-01-01 08:00:00.000000）。如果是，则表示节点还没有恢复结束。

   • 节点停止时间 stop_time：是否是默认值（1970-01-01 08:00:00.000000），如果不是，则表示节点被停服（ stop server）了，需要先启动服务（start server）。

2. 确认集群近期事件

   SELECT DATE_FORMAT(gmt_create, '%b%d %H:%i:%s') gmt_create_ , module, event, name1, value1, name2, value2, rs_svr_ip
   FROM __all_rootservice_event_history
   WHERE 1 = 1   
      AND module IN ('server','root_service','balancer')
      AND gmt_create > SUBDATE(now(),interval  1 hour)
   ORDER BY gmt_create DESC
   LIMIT 50;

   需着重留意节点掉线和上线事件、合并超时事件、数据迁移事件等。

如何处理节点掉线或宕机故障

修改租户变量允许 DDL

如果有租户的架构是 1-1-1 并且宕机的节点就是该租户的成员，宕机后可能导致租户的 DDL 报错。

MySQL [test]> create table t2 like t1;
ERROR 4624 (HY000): machine resource is not enough to hold a new unit

此时需要将全局变量 ob_create_table_strict_mode 值设置为 OFF。

set global ob_create_table_strict_mode = off;

之后重新登录业务租户，就可以做 DDL 了。

注意

关闭这个变量有风险，需要尽快修复故障节点。

启动 observer 进程

如果节点掉线了，但是节点的进程还在，则很可能有两个原因：

• 节点跟其他节点的时间误差超过 200ms，此时首先应检查时间是否同步。

• 节点的事务日志目录空间使用率超过参数 clog_disk_usage_limit_percentage 定义（默认值是 95，意为 95%）。

如果节点进程不存在，则首先应尝试拉起进程，之后再观察几分钟，确认进程是否再次推出。

启动进程时需注意用户是否正确。

# 切换到正确用户下
cd /home/admin/oceanbase-ce && bin/observer

如果进程还是会退出，则需要查看最近的进程运行日志，搜索 ERROR 信息。

cd /home/admin/oceanbase-ce 
grep ERROR log/observer.log | vim -

如何处理节点时间不同步故障

判断集群节点时间同步误差

您必须准确判断节点时间是否同步。您可使用测试命令 clockdiff 对集群中所有节点进行相互测试。

[root@obce01 ~]# clockdiff 172.20.249.49
...
host=172.20.249.49 rtt=428(314)ms/0ms delta=0ms/0ms Thu Sep 30 21:33:16 2021
[root@obce01 ~]# clockdiff 172.20.249.51
...
host=172.20.249.51 rtt=426(314)ms/0ms delta=0ms/0ms Thu Sep 30 21:33:22 2021

[root@obce02 ~]# clockdiff 172.20.249.50
.
host=172.20.249.50 rtt=750(187)ms/0ms delta=0ms/0ms Thu Sep 30 21:34:10 2021
[root@obce02 ~]# clockdiff 172.20.249.52
...
host=172.20.249.52 rtt=423(315)ms/0ms delta=-1ms/-1ms Thu Sep 30 21:34:14 2021

在某些客户机房环境下，命令 clockdiff 可能会报错（原因不明）。此时可使用 ping 命令，查看返回的信息判断时间误差。

ping -T tsandaddr 172.20.249.49 -c 3

输出：
[root@obce01 ~]# ping -T tsandaddr 172.20.249.49 -c 3
PING 172.20.249.49 (172.20.249.49) 56(124) bytes of data.
64 bytes from 172.20.249.49: icmp_seq=1 ttl=64 time=26.3 ms
TS:     172.20.249.52   48963954 absolute
        172.20.249.49   13
        172.20.249.49   0
        172.20.249.52   13

64 bytes from 172.20.249.49: icmp_seq=2 ttl=64 time=0.333 ms
TS:     172.20.249.52   48964963 absolute
        172.20.249.49   1
        172.20.249.49   0
        172.20.249.52   0

64 bytes from 172.20.249.49: icmp_seq=3 ttl=64 time=0.480 ms
TS:     172.20.249.52   48966011 absolute
        172.20.249.49   0
        172.20.249.49   0
        172.20.249.52   0


--- 172.20.249.49 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2057ms
rtt min/avg/max/mdev = 0.333/9.038/26.302/12.207 ms

修复集群节点时间同步服务

在此环节中主要是检查每个节点的时间同步服务是否正常。推荐使用 chrony 同步服务，不要使用 ntpd。

• 检查 chrony 节点同步服务

  使用 chrony 时间服务是为了保证 OceanBase 集群各个节点时间尽可能保证同步。如下命令仅供参考，具体使用请查看 chrony 官方使用说明：Chronyc Frequently Asked Questions。

  查看时间同步活动
  chronyc activity
  
  查看时间服务器
  chronyc sources
  
  查看同步状态
  chronyc sources -v
  
  校准时间服务器：
  chronyc tracking

• 检查节点与选中的时间服务器之间的时间差

  该步骤也使用 clockdiff 命令。 如果时间服务器是禁止 ping 命令，或者防火墙禁止 ping 命令，则无法探知时间误差。

  您可以使用 ntpdate 命令快速同步本节点跟时间源之间的时间。测试环境中如果时间总是不同步，可以将这个命令写到 crontab 里，每分钟运行一次。

  ntpdate -b xxx.xxx.xxx.xxx