节点启动失败问题总体分析思路
问题描述
控制台页面上显示节点为停止/异常状态，手动启动失败。
可能影响
- DN主节点启动失败，会导致访问到该DN的节点SQL报错，实例部分不可用；
- CN主节点启动失败，会导致流入该节点的SQL语句报错，流入其它CN主节点的DDL语句报错；
- GTM主节点启动失败，会导致整个实例不可用；
- GTM/CN/DN备节点失败失败，如果开启同步复制，同步复制节点数量不足且未启用退化策略时，会导致DDL、DML语句卡住；
- GTM/CN/DN备节点失败失败，可能会导致无可用备节点，主节点再次异常会导致实例不可用，有数据丢失风险。
解决步骤
- 控制台页面启动节点会下发任务到节点所在的Agent服务，检查Agent服务运行是否正常，如果Agent未启动或启动失败，优先解决Agent服务问题，再尝试启动节点；
Agent服务运行情况检查：
ps -fu teledbx|grep teledbx_oss|grep oss_server|grep -v grep
返回有一个进程存在，输出结果如：
teledbx 16371 1 1 2023 ? 2-03:21:22 /home/teledbx/install/teledbx_oss/bin/oss_server -conf /home/teledbx/install/teledbx_oss/config//teledbx_oss_conf.ini -log /home/teledbx/install/teledbx_oss/logs/ -level 1
Agent服务端口监听情况检查：
netstat -lntp|grep oss_server
返回应包含至少两行记录，端口包含8118、8119，输出结果如：
tcp 0 0 172.16.16.15:8118 0.0.0.0:* LISTEN 16371/oss_server
tcp 0 0 127.0.0.1:8119 0.0.0.0:* LISTEN 16371/oss_server
Agent服务日志检查：
teledbx用户家目录下install/teledbx_oss/logs/oss_log_xxx(pid)，通常为/home/teledbx/install/teledbx_oss/logs/oss_log_xxx(pid)
查看最新的日志文件内容是否有FATAL错误。
如果进程不存在，则需要检查原因，因为Agent服务有crontab任务守护，会每分钟检测，异常时自动拉起。
如果进程在持续不断的重启，则需要根据日志检查具体原因。
如果进程运行正常，则继续分析节点启动日志和运行日志。
- 节点启动日志有几个地方可以查看
1）Agent日志中节点启动日志
在Agent的oss_log_xxx(pid)中会打印节点启动日志和报错信息，可通过以下egrep命令搜索日志中启动信息和返回结果：
egrep pg_ctl.*start oss_log_xxx
2）节点启动日志
Agent日志目录log下有个节点启动停止目录cls_log，该目录下记录了该服务器上部署所有实例、所有节点的启动停止日志，目录如：
/home/teledbx/install/teledbx_oss/logs/cls_log/实例id/节点名称_节点id_节点ip_节点端口/pg_ctl.start_yyyymmdd_hh24miss.log 或pg_ctl.stop_yyyymmdd_hh24miss.log
对于启动加载配置文件、控制文件、监听端口、分配内存等在节点启动前的异常报错，会在该日志中记录；这里没有报错，通常节点可以顺利启动成功；
如果这里没有启动日志，或没有更新，则需要检查Agent服务。
如果这里有启动日志，但是在不断的启动、停止、启动...，则需要检查节点运行日志。
3）节点运行日志
在节点数据目录下的pg_log目录，记录了节点启动后运行时的一些信息，默认为postgres-星期(英文)-小时.csv;
如果这里没有日志更新，则需要检查节点启动日志和Agent服务。
如果这里日志有更新，则查看日志，根据日志提示进行处理。
- 根据上述日志具体报错，做相应处理，如：磁盘空间%、操作系统内存不足导致启动节点时不能分配内存，节点数据目录部分文件权限不足、文件损坏、配置文件参数错误等。
节点启动超时问题
问题描述
控制台页面上显示节点为停止/异常状态，手动或自动启动失败。
为避免因系统卡顿、节点异常等原因，导致节点长时间处理启动等待状态问题，系统新增了全局参数NODE_MAX_START_WAIT_TIMES控制节点启动超时时间，默认为60秒。当节点重启、重做备机、添加备节点等操作时，如果启动时需要应用的WAL日志较多，启动时间可能会超过60秒，此时节点会收到Center Master下发的停止命令，节点启动60秒后日志会打印 received fast shutdown request，节点启动失败。
可能影响
- DN主节点启动失败，会导致访问到该DN的节点SQL报错，实例部分不可用；
- CN主节点启动失败，会导致流入该节点的SQL语句报错，流入其它CN主节点的DDL语句报错；
- CN/DN备节点失败失败，如果开启同步复制，同步复制节点数量不足且未启用退化策略时，会导致DDL、DML语句卡住；
- CN/DN备节点失败失败，可能会导致无可用备节点，主节点再次异常会导致实例不可用，有数据丢失风险。
解决步骤
- 控制台页面进入“系统信息”-“基本信息”页面，切换至“参数配置”TAB页，查找并修改参数NODE_MAX_START_WAIT_TIMES；
- 重新发起节点启动任务，或等待节点自动拉起。
pg_hba.conf文件内容错误导致启动失败问题
问题描述
节点启动失败，日志显示报错could not load pg_hba.conf，如：
CST,"YB17102_0",,,17102,coord(0,0),,65a34d68.42ce,coord(0,0),3,,2024-01-14 10:56:40
CST,,0,FATAL,XX000,"could not load pg_hba.conf",,,,,,,,,,""
2024-01-14 10:56:43.566
CST,"YB17102_0",,,17102,coord(0,0),,65a34d68.42ce,coord(0,0),4,,2024-01-14 10:56:40
CST,,0,LOG,00000,"database system is shut down",,,,,,,,,,""
而前一行会提示错误位置和错误原因，如：
LOG,F0000,"invalid IP mask ""md5"": 未知的名称或服务",,,,,"line 24 of configuration file
""/data/xxx/....../pg_hba.conf""",,,,,""
或
LOG,F0000,"invalid connection type""host1""",,,,,"line 11 of configuration
file""/data/xxx/......./pg_hba.conf""",,,,""
这里第一个错误显示第24行ip地址后的mask格式错误；第二个错误显示第11行连接类型host1错误，枚举类型中不包含host1。
可能影响
- DN主节点启动失败，会导致访问到该DN的节点SQL报错，实例部分不可用；
- CN主节点启动失败，会导致流入该节点的SQL语句报错，流入其它CN主节点的DDL语句报错；
- CN/DN备节点失败失败，如果开启同步复制，同步复制节点数量不足且未启用退化策略时，会导致DDL、DML语句卡住；
- CN/DN备节点失败失败，可能会导致无可用备节点，主节点再次异常会导致实例不可用，有数据丢失风险。
解决步骤
- 按照错误提示，修正pg_hba.conf文件内容；
- 重新发起节点启动任务，或等待节点自动拉起。
postgresql.conf文件内容错误导致启动失败问题
问题描述
节点启动失败，启动日志（在Agent目录logs/cls_log下对应节点的日志pg_ctl.start_xxx.log）显示报错 configuration file "....../pg_hba.conf" contains errors，如：
2024-01-15 01:01:08.874 GMT [21832,coord(0,0)] FATAL: configuration file
"/data/xxx/....../postgresql.conf" contains errors
而前一行会提示错误位置和错误原因，例如：
LOG: unrecognized configuration parameter "work_mam" in file
"/data/xxx/....../postgresql.conf" line 23
这里显示第23行的参数 work_man无效，此处是参数名拼写错误，应该是work_mem。
postgresql.conf中配置加载的参数文件postgresql.conf.user，或postgresql.auto.conf文件内容错误，也会启动失败，报错同上，仅指向文件不同。
需要说明的是，配置文件中参数名错误会导致节点启动失败，而参数值错误不会导致节点启动失败，只是参数值设置失效，仍会使用默认值。参数值错误，在启动启动日志（在Agent目录logs/cls_log下对应节点的日志pg_ctl.start_xxx.log）中会有类似如下提示：
LOG: invalid value for parameter "work_mem": "4m"
HINT: Valid units for this parameter are "kB", "MB", "GB", and "TB".
这里显示work_mem参数值错误，并给出了可选说明。
可能影响
- DN主节点启动失败，会导致访问到该DN的节点SQL报错，实例部分不可用；
- CN主节点启动失败，会导致流入该节点的SQL语句报错，流入其它CN主节点的DDL语句报错；
- CN/DN备节点失败失败，如果开启同步复制，同步复制节点数量不足且未启用退化策略时，会导致DDL、DML语句卡住；
- CN/DN备节点失败失败，可能会导致无可用备节点，主节点再次异常会导致实例不可用，有数据丢失风险。
解决步骤
- 按照错误提示，修正postgresql.conf文件内容；
- 重新发起节点启动任务，或等待节点自动拉起。
端口被占用导致启动失败问题
问题描述
节点启动失败，启动日志（在Agent目录logs/cls_log下对应节点的日志pg_ctl.start_xxx.log）显示报错: 地址已在使用，如：
2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0LOG: could not bind IPv4 address "0.0.0.0": 地址已在使用
2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0HINT: Is another postmaster already running on port 11006? If not, wait a few seconds and retry.
2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0LOG: could not bind IPv6 address "::": 地址已在使用
2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0HINT: Is another postmaster already running on port 11006? If not, wait a few seconds and retry.
2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0WARNING: could not create listen socket for "*"
2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0FATAL: could not create any TCP/IP sockets2024-01-15 09:37:40.881 CST 22855,coord(0,0) 0LOG: database system is shut down
这里显示11006端口已被使用。
可能影响
- DN主节点启动失败，会导致访问到该DN的节点SQL报错，实例部分不可用；
- CN主节点启动失败，会导致流入该节点的SQL语句报错，流入其它CN主节点的DDL语句报错；
- CN/DN备节点失败失败，如果开启同步复制，同步复制节点数量不足且未启用退化策略时，会导致DDL、DML语句卡住；
- CN/DN备节点失败失败，可能会导致无可用备节点，主节点再次异常会导致实例不可用，有数据丢失风险。
解决步骤
- 通过netstat -lntp|grep xxx(端口) 查看哪个进程使用了端口，例如上述报错11006
netstat -lntp|grep 11006 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:11006 0.0.0.0:* LISTEN 5228/postgrestcp6 0 0 :::11006 :::* LISTEN 5228/postgres这里提示ID为5228的进程使用了该端口，该进程也是postgres命令启动的。通过如ps -fe|grep 5228可以查看进程启动相关进程信息，核实进程具体使用人，确认进程是否在使用，是否可停止等。
- 根据核实情况，选择停掉该进程（通常对应场景：在服务器上手动部署一些服务，占用了数据库端口），或者更改端口（通常对应场景：实例创建时端口分配错误导致冲突）；
- 一种特殊情况，该端口被占用的进程是僵尸进程，如果僵尸进程的父进程是1，则需要通过重启服务器来解决；
- 重新发起节点启动任务，或等待节点自动拉起。
节点目录权限不正确导致启动失败问题
问题描述
节点启动失败，启动日志（在Agent目录logs/cls_log下对应节点的日志pg_ctl.start_xxx.log）显示报错: data directory xxx has group or world access，如：
2024-01-15 11:28:22.874 CST 1389,coord(0,0) 0FATAL: data directory "/data/xxx/.../data/dn001" has group or world access
2024-01-15 11:28:22.874 CST 1389,coord(0,0) 0DETAIL: Permissions should be u=rwx (0700).
可能影响
- DN主节点启动失败，会导致访问到该DN的节点SQL报错，实例部分不可用；
- CN主节点启动失败，会导致流入该节点的SQL语句报错，流入其它CN主节点的DDL语句报错；
- CN/DN备节点失败失败，如果开启同步复制，同步复制节点数量不足且未启用退化策略时，会导致DDL、DML语句卡住；
- CN/DN备节点失败失败，可能会导致无可用备节点，主节点再次异常会导致实例不可用，有数据丢失风险。
解决步骤
- 用teledbx用户查看节点目录权限 ls -lrt xxx（节点目录），应为700，示例如下
drwx------ 24 teledbx teledbx 4096 Jan 15 11:33 dn001
如果不是700，则需要改为700（只改节点目录，不能带-R递归修改子目录或文件）
chmod 700 dn001
- 重新发起节点启动任务，或等待节点自动拉起。
这里特别说明：节点data目录特别要求为700，需要特别注意。另外，对节点的bin目录、data目录做好权限管理，一定不能随意修改他们的目录或上级目录的属主、权限，否则可能会导致节点启动失败、运行异常。
节点停止失败问题
问题描述
控制台页面上手动停止节点失败，或主节点异常发起主备自动切换时原主节点停止失败。
可能影响
- 变更期间节点停止失败，会导致变更无法开展；
- 主节点异常发起主备自动切换时原主节点停止失败，可能会导致主备切换失败，影响实例正常运行。
解决步骤
- 控制台页面启动节点会下发任务到节点所在的Agent服务，检查Agent服务运行是否正常，如果Agent未启动或启动失败，优先解决Agent服务问题，再尝试停止节点；
服务状态查看、日志分析，参见“节点启动失败问题总体分析思路”。
- 尝试重启节点所在服务器的Agent服务；
- 检查Agent服务日志中节点停止命令执行返回失败具体报错，根据错误提示做相应处理，如：节点软件运行目录文件损坏或权限不足导致命令执行报错；操作系统异常无响应或响应慢导致命令执行超时，僵尸进程残留等。
