|
| 1 | +--- |
| 2 | +title: 节点宕机 |
| 3 | +weight: 4 |
| 4 | +--- |
| 5 | + |
| 6 | +## 业务及数据库表现 |
| 7 | + |
| 8 | +业务表现:业务失败。 |
| 9 | + |
| 10 | +数据库表现:数据库服务器节点异常,出现节点宕机,OceanBase 数据库对应节点服务不可用。 |
| 11 | + |
| 12 | +## 排查方向和流程 |
| 13 | + |
| 14 | + |
| 15 | + |
| 16 | +### 排查是否宕机 |
| 17 | + |
| 18 | +检查主机可用性,如果可以登录对应节点,执行 ps 命令看下 observer 进程是否存在。 |
| 19 | + |
| 20 | +``` |
| 21 | +$ps -ef | grep observer |
| 22 | +03:55:52 /home/xiaofeng.lby/obn.obs0/bin/observer |
| 23 | +00:00:00 grep --color=auto observer |
| 24 | +``` |
| 25 | + |
| 26 | +如果进程依然存在,可以进一步检查节点所在主机的网络连通性,排除因为节点间网络隔离或者网络抖动等原因导致的误报。 |
| 27 | + |
| 28 | +参考:[NTP 时钟不同步的问题排查](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207684) |
| 29 | + |
| 30 | + |
| 31 | +### 如果健康节点已经不满足多数派 |
| 32 | + |
| 33 | +如果评估主机或网络问题无法及时恢复: |
| 34 | + |
| 35 | +- 优先考虑使用 OCP 通过 **物理备租户(集群) Failover** 的方式来进行恢复。 |
| 36 | + |
| 37 | +- 其次考虑使用 OCP 通过**物理备份恢复**的方式来进行恢复。 |
| 38 | + |
| 39 | +- 如果没有物理备库及数据备份,尝试轮流重启集群各个节点的 observer 进程。 |
| 40 | + |
| 41 | +- 如果轮流重启之后依然无法恢复,联系社区论坛值班同学进行排查。 |
| 42 | + |
| 43 | +- 联系社区论坛值班同学分析故障根因。 |
| 44 | + |
| 45 | + |
| 46 | +**<font color="red">生产环境中的重要数据和关键租户,建议大家启用备份,以防各种不可预期的故障!</font>** 推荐大家在生产环境中使用 OCP 进行白屏化的[物理备份恢复](https://www.oceanbase.com/docs/common-ocp-1000000001739862),以及[搭建物理备租户/集群](https://www.oceanbase.com/docs/common-ocp-1000000001740033)。 |
| 47 | + |
| 48 | + |
| 49 | +### 如果健康节点能构成多数派 |
| 50 | + |
| 51 | +- 如果健康节点可以构成多数派,依靠 OceanBase 集群自身的高可用能力(8 秒内选出新的主副本),就能够继续对外提供服务。重启或替换出问题的节点即可。绝大对数情况到这里就结束了。**<font color="red">大家可以收藏一下下面这个命令。</font>** |
| 52 | + |
| 53 | + ``` |
| 54 | + -- 故障开始前 |
| 55 | + SELECT SVR_IP, ROLE, SCN_TO_TIMESTAMP(END_SCN) |
| 56 | + FROM oceanbase.GV$OB_LOG_STAT |
| 57 | + WHERE TENANT_ID = 1 order by LS_ID, ROLE; |
| 58 | + +---------------+----------+----------------------------+ |
| 59 | + | SVR_IP | ROLE | SCN_TO_TIMESTAMP(END_SCN) | |
| 60 | + +---------------+----------+----------------------------+ |
| 61 | + | xx.xxx.xxx.1 | FOLLOWER | 2024-11-27 19:44:27.881516 | |
| 62 | + | xx.xxx.xxx.2 | FOLLOWER | 2024-11-27 19:44:27.881516 | |
| 63 | + | xx.xxx.xxx.3 | LEADER | 2024-11-27 19:44:27.881516 | |
| 64 | + +---------------+----------+----------------------------+ |
| 65 | +
|
| 66 | + -- 系统自动选主后 |
| 67 | + SELECT SVR_IP, ROLE, SCN_TO_TIMESTAMP(END_SCN) |
| 68 | + FROM oceanbase.GV$OB_LOG_STAT |
| 69 | + WHERE TENANT_ID = 1 order by LS_ID, ROLE; |
| 70 | + +---------------+----------+----------------------------+ |
| 71 | + | SVR_IP | ROLE | SCN_TO_TIMESTAMP(END_SCN) | |
| 72 | + +---------------+----------+----------------------------+ |
| 73 | + | xx.xxx.xxx.1 | FOLLOWER | 2024-11-27 19:44:38.737837 | |
| 74 | + | xx.xxx.xxx.2 | LEADER | 2024-11-27 19:44:38.737837 | |
| 75 | + +---------------+----------+----------------------------+ |
| 76 | + ``` |
| 77 | +> SCN_TO_TIMESTAMP(END_SCN) 会获取指定日志流副本的最新日志位点信息,并转换成时间戳形式。日志流的 Follower 副本和 Leader 副本的最新日志位点差距在 5 秒以内,即可以认为日志是同步的。 |
| 78 | +
|
| 79 | +- 如果无法对外提供服务,先隔离有问题的节点。并考虑是否需要调大永久下线参数 [server_permanent_offline_time 的值](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001576427)(默认一小时)。 |
| 80 | + ``` |
| 81 | + -- 确认集群各节点状态 |
| 82 | + select SVR_IP, SVR_PORT, ZONE, WITH_ROOTSERVER, STATUS from oceanbase.DBA_OB_SERVERS; |
| 83 | + +---------------+----------+-------+-----------------+----------+ |
| 84 | + | SVR_IP | SVR_PORT | ZONE | WITH_ROOTSERVER | STATUS | |
| 85 | + +---------------+----------+-------+-----------------+----------+ |
| 86 | + | xx.xxx.xxx.3 | 2882 | zone3 | NO | INACTIVE | |
| 87 | + | xx.xxx.xxx.2 | 2882 | zone2 | YES | ACTIVE | |
| 88 | + | xx.xxx.xxx.1 | 2882 | zone1 | NO | ACTIVE | |
| 89 | + +---------------+----------+-------+-----------------+----------+ |
| 90 | +
|
| 91 | + -- 检查永久下线参数值 |
| 92 | + show parameters like "%server_permanent_offline_time%"; |
| 93 | +
|
| 94 | + -- 停止节点,隔离故障节点 |
| 95 | + alter system stop server 'xx.xxx.xxx.3:2882'; |
| 96 | + ``` |
| 97 | +
|
| 98 | +> STOP SERVER 是最安全的隔离命令。STOP SERVER 不但可以将业务流量从该节点上切走,实现该节点与业务流量隔离的效果,还能保证除被隔离节点以外的其他节点依然能够构成 Paxos 多数派,从而可以安全的对被隔离节点执行任何动作,例如 pstack / obstack、调整日志级别等,甚至停止进程。STOP SERVER 适用于需要故障隔离和停机运维的场景,是故障隔离和运维变更首选的隔离命令。 |
| 99 | +
|
| 100 | +
|
| 101 | +- 如果执行完上一步操作,两分钟之后依然无法恢复。手动选择一个不包含问题节点的 zone 进行切主。 |
| 102 | + ``` |
| 103 | + ALTER TENANT tenant_name primary_zone='zone1'; |
| 104 | +
|
| 105 | + -- 通过查询 GV$OB_LOG_STAT 中的 ROLE 字段判断切主是否成功。 |
| 106 | + SELECT SVR_IP, ROLE, SCN_TO_TIMESTAMP(END_SCN) |
| 107 | + FROM oceanbase.GV$OB_LOG_STAT |
| 108 | + WHERE TENANT_ID = 1 order by LS_ID, ROLE; |
| 109 | + ``` |
| 110 | +
|
| 111 | +- 如果切主三分钟之后,依然无法恢复服务,参考 “如果健康节点已经不满足多数派” 部分的内容进行恢复。 |
| 112 | +
|
| 113 | +- 联系社区论坛值班同学分析故障根因。 |
| 114 | +
|
| 115 | +
|
| 116 | +# 参考资料 |
| 117 | +
|
| 118 | +- 洪波大佬的社区博客:[《OceanBase 应急三板斧》](https://open.oceanbase.com/blog/13250502949) |
| 119 | +- 官网文档:[《集群常见故障处理》](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001573937) |
| 120 | +- 官网文档:[《隔离节点》](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001573941) |
0 commit comments