節點啟動失敗問題總體分析思路
問題描述
控制臺頁面上顯示節點為停止/異常狀態，手動啟動失敗。
可能影響
- 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服務日志中節點停止命令執行返回失敗具體報錯，根據錯誤提示做相應處理，如：節點軟件運行目錄文件損壞或權限不足導致命令執行報錯；操作系統異常無響應或響應慢導致命令執行超時，僵尸進程殘留等。
