Skip to content

Commit 10a2ebf

Browse files
committed
在进阶教程中的故障应急手册里添加《节点宕机》小节
1 parent 1abb2e6 commit 10a2ebf

File tree

2 files changed

+120
-0
lines changed
  • docs/user_manual/operation_and_maintenance/emergency_handbook
  • static/img/user_manual/operation_and_maintenance/emergency_handbook/04_node_breakdown

2 files changed

+120
-0
lines changed
Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
---
2+
title: 节点宕机
3+
weight: 4
4+
---
5+
6+
## 业务及数据库表现
7+
8+
业务表现:业务失败。
9+
10+
数据库表现:数据库服务器节点异常,出现节点宕机,OceanBase 数据库对应节点服务不可用。
11+
12+
## 排查方向和流程
13+
14+
![image](/img/user_manual/operation_and_maintenance/emergency_handbook/04_node_breakdown/001.png)
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)
220 KB
Loading

0 commit comments

Comments
 (0)