From 862bcb67e0e1400c968810faa07b799c833ecb78 Mon Sep 17 00:00:00 2001 From: hejiahuan11 Date: Thu, 10 Oct 2024 17:14:02 +0800 Subject: [PATCH] =?UTF-8?q?=E8=B5=84=E6=BA=90=E6=B1=A0=E5=8C=96=E9=9B=86?= =?UTF-8?q?=E7=BE=A4=E5=90=AF=E5=8A=A8=E6=88=96=E9=87=8D=E5=90=AF=E5=A4=B1?= =?UTF-8?q?=E8=B4=A5=E6=95=85=E9=9A=9C=E6=A1=88=E4=BE=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...45\347\232\204\351\227\256\351\242\230.md" | 41 +++++++++++++ ...45\347\232\204\351\227\256\351\242\230.md" | 45 ++++++++++++++ ...45\347\232\204\351\227\256\351\242\230.md" | 36 ++++++++++++ ...45\347\232\204\351\227\256\351\242\230.md" | 36 ++++++++++++ ...45\347\232\204\351\227\256\351\242\230.md" | 58 +++++++++++++++++++ ...45\347\232\204\351\227\256\351\242\230.md" | 41 +++++++++++++ ...45\347\232\204\351\227\256\351\242\230.md" | 45 ++++++++++++++ 7 files changed, 302 insertions(+) create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\346\216\247\345\210\266\346\226\207\344\273\266\346\215\237\345\235\217\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\343\200\201\347\233\256\345\275\225\344\270\215\345\255\230\345\234\250\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\347\233\256\345\275\225\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\226\255\351\223\276\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" create mode 100644 "content/zh/docs/DatabaseOMGuide/\345\233\240\347\253\257\345\217\243\345\206\262\347\252\201\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\346\216\247\345\210\266\346\226\207\344\273\266\346\215\237\345\235\217\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\346\216\247\345\210\266\346\226\207\344\273\266\346\215\237\345\235\217\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..667777eab --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\346\216\247\345\210\266\346\226\207\344\273\266\346\215\237\345\235\217\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,41 @@ +# 因控制文件异常的问题导致启动或重启集群失败的问题 + +## 一、问题现象 +若openGauss资源池化集群启动或重启失败，有如下报错信息： +```shell +cm_ctl: start cluster failed in (601)s! + +HINT: Maybe the cluster is continually being started in the background. +You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. +``` +报告启动集群失败，10min 超时。 + +使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点为正常，`Datanode State`中所有节点的状态为`Down Manually stopped`, `cluster_state`为`Unavailable`。 + +## 二、定位方法 +1. 进入`$PGDATA`目录下，查看`DBstart.log`日志，发现如下报错信息： + ```shell + 2024-10-10 15:35:00.648 670783a4.1 [unknown] 281469404839952 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG: base_page_saved_interval is 400, ori is 400. + gaussdb: could not find the database system + Expected to find it in the directory "/usr4/hjhzz_install/omm/openGaussdebug/dn1", + but could not open file "+data/pg_control": Unknown error 2190 + ``` + 通过上述报错信息可以看出是+data/pg_control文件异常导致 + +2. 使用`cm_ctl stop`命令停止 cm 相关服务，然后使用`dssserver -M &`命令启动 dss 服务，当回显`DSS SERVER STARTED.`时说明启动 dss 服务成功。 + +3. 在启动 dss 服务成功后，可以使用`dsscmd -ls -p +data`命令查看`pg_control`文件是否存在、是否损坏、是否改名，即可找到对应问题所在。 + + +## 三、问题根因 +系统控制文件`pg_control`出现异常导致的启动或重启集群失败。 + +## 四、解决方案 +针对该问题，有两种情况分别有不同的解决方案，如下： +1. 若`pg_control`文件不存在或损坏了，卸载集群重新安装即可。 +2. 若`pg_control`文件存在且未损坏，只是更换了文件名称： + ```shell + dsscmd mv 将文件名称恢复 + dsscmd stopdss 停止 dss 服务 + cm_ctl start 启动集群即可 + ``` \ No newline at end of file diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\343\200\201\347\233\256\345\275\225\344\270\215\345\255\230\345\234\250\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\343\200\201\347\233\256\345\275\225\344\270\215\345\255\230\345\234\250\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..9e8ab1221 --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\343\200\201\347\233\256\345\275\225\344\270\215\345\255\230\345\234\250\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,45 @@ +# 因文件、目录不存在导致启动或重启集群失败的问题 + +## 一、问题现象 +若openGauss资源池化集群启动或重启失败，有如下报错信息： +```shell +cm_ctl: start cluster failed in (601)s! + +HINT: Maybe the cluster is continually being started in the background. +You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. +``` +报告启动集群失败，10min 超时。 + +使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点正常，`Datanode State`中有的节点的状态为`Down Manually stopped`, `cluster_state`为`Degraded`。 + +## 二、定位方法 +1. 登录故障节点机器，进入`$GAUSSLOG/cm/cm_agent`目录下，寻找该节点最近时间点的`cm_agent`日志，发现如下报错信息： + ```shell + 2024-10-10 09:26:02.270 tid=2015951 LOG: gaussdb state file "/.../.../dn1/gaussdb.state" is not exist, could not get the build infomation: No such file or directory + 2024-10-10 09:26:02.746 tid=2015996 DiskUsageCheck ERROR: [GetDiskUsageForPath][line:908] GetDiskUsageForPath /.../.../dn1 disk usage failed! errno:2 err:No such file or directory. + + 2024-10-10 09:26:02.880 tid=2015948 ERROR: [get_connection: 1526]: fail to read pid file (/.../.../dn1/postmaster.pid). + 2024-10-10 09:26:02.880 tid=2015948 ERROR: failed to connect to datanode:/.../...//dn1 + ``` + 绝对路径`/.../.../dn1`就是`$PGDATA`，上述报错信息表明问题是`$PGDATA`目录不存在。 + +2. 使用`cd $PGDATA`命令却回显以下信息，印证了问题是`$PGDATA`目录不存在。 + ```shell + [ ~]$ cd $PGDATA + -bash: cd: /.../.../dn1: No such file or directory + ``` + +若在cm_agent中未发现明确的报错信息，但能进入`$PGDATA`目录下，则查看`DBstart.log`日志，发现如下报错信息： +```shell +2024-10-10 09:55:35.343 67073417.1 [unknown] 281471761580048 [unknown] 0 dn_6001_6002 58P01 0 [BACKEND] LOG: could not open configuration file "/.../.../dn1/pg_hba.conf": No such file or directory +2024-10-10 09:55:35.543 67073417.1 [unknown] 281471761580048 [unknown] 0 dn_6001_6002 58P01 0 [BACKEND] LOG: could not open configuration file "/.../.../dn1/pg_hba.conf": No such file or directory +2024-10-10 09:55:35.743 67073417.1 [unknown] 281471761580048 [unknown] 0 dn_6001_6002 58P01 0 [BACKEND] LOG: could not open configuration file "/.../.../dn1/pg_hba.conf": No such file or directory +2024-10-10 09:55:35.743 67073417.1 [unknown] 281471761580048 [unknown] 0 dn_6001_6002 42809 0 [BACKEND] FATAL: could not load pg_hba.conf +``` +这个数据库启动日志的报错明确说明了`pg_hba.conf`文件不存在。 + +## 三、问题根因 +系统配置文件、目录缺失导致集群启动或重启失败。 + +## 四、解决方案 +若还存在状态正常的节点机器，可以将正常节点机器的目录或文件复制到故障节点机器上；若没有正常节点机器，可以卸载然后重新进行安装启动。 \ No newline at end of file diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..bfc9af239 --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\346\226\207\344\273\266\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,36 @@ +# 因文件权限问题导致启动或重启集群失败的问题 + +## 一、问题现象 +若openGauss资源池化集群启动或重启失败，有如下报错信息： +```shell +cm_ctl: start cluster failed in (601)s! + +HINT: Maybe the cluster is continually being started in the background. +You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. +``` +报告启动集群失败，10min 超时。 + +使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点为`Down`。 + +## 二、定位方法 +1. 进入`$GAUSSLOG/cm/cm_agent`目录下，寻找该节点最近时间点的`cm_agent`日志，发现如下报错信息： + ```shell + 2024-10-09 11:07:59.018 tid=313687 LOG: open gaussdb state file "/.../.../dn1/gaussdb.state" failed, could not get the build infomation: Permission denied. + + 2024-10-09 11:07:58.966 tid=313678 ERROR: [get_connection: 1526]: fail to read pid file (/.../.../dn1/postmaster.pid). + 2024-10-09 11:07:58.966 tid=313678 ERROR: failed to connect to datanode:/.../.../dn1 + ``` + 绝对路径`/.../.../dn1`就是`$PGDATA`，上述报错信息表明问题是`$PGDATA`目录的权限不足。 + +2. 使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点正常，`Datanode State`中有节点的状态为`Down Manually stopped`, `cluster_state`为`Unavailable`。 + +3. 查看`$PGDATA`目录的权限，发现用户没有`dn1`目录的权限。 + ```shell + drwx------. 15 root root 8.0K Oct 9 11:06 dn1 + ``` + +## 三、问题根因 +用户对`pg_hba.conf`文件没有权限。 + +## 四、解决方案 +需要以 root 用户登录对应机器，使用`chmod`或`chown`修改`$PGDATA`文件权限为子用户，再依次执行`cm_ctl stop`和`cm_ctl start`即可。 \ No newline at end of file diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\347\233\256\345\275\225\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\233\256\345\275\225\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..be394496c --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\233\256\345\275\225\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,36 @@ +# 因目录权限问题导致启动或重启集群失败的问题 + +## 一、问题现象 +若openGauss资源池化集群启动或重启失败，有如下报错信息： +```shell +cm_ctl: start cluster failed in (601)s! + +HINT: Maybe the cluster is continually being started in the background. +You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. +``` +报告启动集群失败，10min 超时。 + +使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点为`Down`。 + +## 二、定位方法 +1. 进入`$GAUSSLOG/cm/cm_agent`目录下，寻找该节点最近时间点的`cm_agent`日志，发现如下报错信息： + ```shell + 2024-10-09 11:07:59.018 tid=313687 LOG: open gaussdb state file "/.../.../dn1/gaussdb.state" failed, could not get the build infomation: Permission denied. + + 2024-10-09 11:07:58.966 tid=313678 ERROR: [get_connection: 1526]: fail to read pid file (/.../.../dn1/postmaster.pid). + 2024-10-09 11:07:58.966 tid=313678 ERROR: failed to connect to datanode:/.../.../dn1 + ``` + 绝对路径`/.../.../dn1`就是`$PGDATA`，上述报错信息表明问题是`$PGDATA`目录的权限不足。 + +2. 使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点正常，`Datanode State`中有节点的状态为`Down Manually stopped`, `cluster_state`为`Unavailable`。 + +3. 查看`$PGDATA`目录的权限，发现用户没有`dn1`目录的权限。 + ```shell + drwx------. 15 root root 8.0K Oct 9 11:06 dn1 + ``` + +## 三、问题根因 +用户对`$PGDATA`目录没有权限。 + +## 四、解决方案 +需要以 root 用户登录对应机器，使用`chmod`或`chown`修改`$PGDATA`目录权限为子用户，再依次执行`cm_ctl stop`和`cm_ctl start`即可。 \ No newline at end of file diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\226\255\351\223\276\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\226\255\351\223\276\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..f092bc7c7 --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\226\255\351\223\276\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,58 @@ +# 因磁阵断链导致启动或重启集群失败的问题 + +## 一、问题现象 +若openGauss资源池化集群启动或重启失败，有如下报错信息： +```shell +cm_ctl: start cluster failed in (601)s! + +HINT: Maybe the cluster is continually being started in the background. +You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. +``` +报告启动集群失败，10min 超时。 + +使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点为`Down`。 + +## 二、定位方法 +1. 进入`$GAUSSLOG/cm/cm_agent`目录下，寻找该节点最近时间点的`cm_agent`日志，发现如下报错信息： + ```shell + 2024-10-08 19:57:53.495 tid=3790142 VotingDisk ERROR: [InitVotingDiskHandler] open disk /dev/xxx failed, errno 2. + 2024-10-08 19:57:53.495 tid=3790142 VotingDisk FATAL: Init voting disk failed! + ``` + 这里的 errno 2 表示找不到磁盘。 + +2. 使用`lsscsi -is`查看设备标识符，发现没有对应的盘符。 + +## 三、问题根因 +磁阵断链导致无法启动或重启资源池化集群。 + +## 四、解决方案 +对于该问题，有解决方案如下： + +在 root 用户下执行： + +1. 查看磁阵连接 + ```shell + iscsiadm -m node + ``` +2. 断开磁阵连接 + ```shell + iscsiadm -m node --logoutall=all + ``` +3. 登录磁阵连接 + ```shell + iscsiadm -m node -p xx.xx.xx.xxx -l + ``` +4. 重新扫描盘符连接 + ```shell + rescan-scsi-bus.sh + ``` + 此时使用`lsscsi -is`查看设备标识符，可以发现有了对应的盘符。 + +在子用户下执行： + +5. 使用`cm_ctl start`命令启动集群后再使用`cm_ctl query -Cvipd`查询，显示集群状态正常。 + +>![](figure/Note.png)**注意:** +>+ 使用断开磁阵连接命令会影响节点上所有的磁阵。 +>+ 登录磁阵连接命令中 -p 后的 iP 对应查到的 ip。 +>+ 重新登录磁阵连接后，还需要再修改磁阵的权限为子用户，可以使用`chmod`或`chown`进行修改。 \ No newline at end of file diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..18d5e45c9 --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\243\201\351\230\265\346\235\203\351\231\220\351\227\256\351\242\230\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,41 @@ +# 因磁阵权限问题导致启动或重启集群失败的问题 + +## 一、问题现象 +若openGauss资源池化集群启动或重启失败，有如下报错信息： +```shell +cm_ctl: start cluster failed in (601)s! + +HINT: Maybe the cluster is continually being started in the background. +You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. +``` +报告启动集群失败，10min 超时。 + +使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中所有节点为`Down`。 + +## 二、定位方法 +1. 进入`$GAUSSLOG/cm/cm_agent`目录下，寻找该节点最近时间点的`cm_agent`日志，发现如下报错信息： + ```shell + 2024-10-09 10:03:34.593 tid=82953 VotingDisk ERROR: [InitVotingDiskHandler] open disk /dev/xxx failed, errno 13. + ``` + errno 13 表示权限不足。 + 使用`ll /dev/xxx`命令查到的权限为 root disk。 + +2. 查看其他磁盘的权限，发现用户没有了共享存储使用的盘的权限。 + ```shell + ll /dev | grep $USER 返回的结果为空 + ``` + +3. 在 root 用户下，修改没有权限的磁盘权限，数据库正常或重启成功，以 omm 用户为例。 + ```shell + 查看用户的 xml 文件，获取共享存储使用的磁盘。（建议使用 lsscsi -is 查看设备标识符，确定对应的盘符。） + chown -R omm:omm /dev/xxx + 如果多个节点权限异常，每个节点都需要修改。 + ``` + +4. 使用`cm_ctl query -Cvipd`命令查询集群状态，显示状态正常。若还存在异常，使用`cm_ctl stop`和`cm_ctl start`命令重启集群后再次查询，显示状态正常。 + +## 三、问题根因 +用户对磁盘没有权限。 + +## 四、解决方案 +需要以 root 用户登录对应机器，使用`chmod`或`chown`修改对应磁盘权限为子用户，再依次执行`cm_ctl stop`和`cm_ctl start`即可。 \ No newline at end of file diff --git "a/content/zh/docs/DatabaseOMGuide/\345\233\240\347\253\257\345\217\243\345\206\262\347\252\201\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\253\257\345\217\243\345\206\262\347\252\201\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" new file mode 100644 index 000000000..8c30ce278 --- /dev/null +++ "b/content/zh/docs/DatabaseOMGuide/\345\233\240\347\253\257\345\217\243\345\206\262\347\252\201\345\257\274\350\207\264\345\220\257\345\212\250\346\210\226\351\207\215\345\220\257\351\233\206\347\276\244\345\244\261\350\264\245\347\232\204\351\227\256\351\242\230.md" @@ -0,0 +1,45 @@ +# 因端口冲突导致启动或重启失败的问题 + +## 一、问题现象 +以资源池化一主一备环境为例，介绍因端口冲突导致启动或重启失败的问题。 +主节点 IP 为 aaa.aaa.aaa.aaa，备节点 IP 为 bbb.bbb.bbb.bbb，端口号均为 xxx。 +1. 若openGauss资源池化集群启动或重启成功，但使用`cm_ctl query -Cvipd`查询集群状态后显示`CMServer State`中某个节点的`state`为`Down`。 +2. 若openGauss资源池化集群启动或重启失败，有如下报错信息： + ```shell + cm_ctl: start cluster failed in (601)s! + + HINT: Maybe the cluster is continually being started in the background. + You can wait for a while and check whether the cluster starts, or increase the value of parameter "-t", e.g -t 600. + ``` + 报告启动集群失败，10min 超时。 + +## 二、定位方法 +对于问题现象1: +1. 登录故障节点机器，进入`$GAUSSLOG/cm/cm_agent`目录下，寻找该节点最近时间点的`cm_agent`日志，发现如下报错信息： + ```shell + 2024-09-29 16:52:33.198 tid=3554807 StartAndStop WARNING: port:xxx already in use. + ``` + 从上述日志可以确认，端口 xxx 已被使用。 + +2. 查看`$GAUSSLOG/cm/cm_ctl`日志，发现如下信息： + ```shell + 2024-09-29 16:37:21.420 tid=3554057 DEBUG1: begin to create ssl connection + 2024-09-29 16:37:21.437 tid=3554057 DEBUG1: connect to cmserver success, remotehost is bbb.bbb.bbb.bbb:xxx. + ``` + 从上述日志可以确认，连接 cmserver 成功，连接的 ip 为 bbb.bbb.bbb.bbb，连接的端口号为 xxx，同时可以发现日志内没有主节点 cmsever 连接成功的信息。 +通过上述方法，可以确认问题现象1的集群`CMServer State`中某个节点的`state`为`Down`是由该节点 CM 端口冲突导致的。 + +对于问题现象2： +在`cm_ctl start`回显报错信息后，使用`cm_ctl query -Cvipd`查询集群状态，可能会有以下几种情况： +1. 使用`cm_ctl query -Cvipd`查询集群状态后有如下报错信息： +2. 首先使用`cm_ctl query -Cvipd`查询集群状态后，可以观测到`CMServer State`中节点状态均为`Normal`，但是`Datanode State`均不为`Normal`或某个节点数据库状态不为`Normal`。 + 然后登录故障节点机器，进入`$GAUSSLOG/cm/cm_ctl`目录下，寻找该节点最近时间点的`cm_ctl1`日志，发现如下报错信息： + ```shell + DEBUG1: starting exceeds 2 mins, instance status:g_cluster_start_status=3,g_az_start_status=5, g_node_start_status=5, g_instance_start_status=5 + ``` + +## 三、问题根因 +在各个组件启动时，需要使用特定端口进行 socket 通信，如果所有节点 cm 端口都被占用，在集群启动或重启过程中无法成功建立连接，导致 cm 拉起失败，查询集群状态会报错；如果部分节点 cm 端口被占用，集群会启动或重启成功，但对应节点的 cmserver 状态为`Down`，集群数据库状态为`Normal`；如果所有或部分节点数据库端口被占用，在集群启动或重启过程中无法成功建立连接，导致集群启动或重启失败，集群各节点数据库状态均不为`Normal`，但 cmserver 状态均为`Normal`。因此在启动或重启数据库过程中，请保证端口独立，不与其他进程混用、不使用默认系统端口。 + +## 四、解决方案 +对于该问题，请在启动或重启完成后（无论成功与否）使用`lsof -i:端口号`或其他指令寻找占用端口的进程，杀掉该进程避免启动或重启失败。杀掉后等一会时间再次查询集群状态，若仍未正常，依次执行`cm_ctl stop`和`cm_ctl start`即可。 \ No newline at end of file -- Gitee