本文分享自華爲雲社區《GaussDB(分佈式)實例故障處理》，作者：subverter。

一、說明

GaussDB Kernel實例出現故障時，可以按照本節的辦法進行實例快速修復。

1、執行gs_om -t status --detail查看集羣狀態，cluster_state爲Normal，balanced爲No，請重置實例狀態。

2、執行gs_om -t status --detail查看集羣狀態，cluster_state爲Degraded，表示有實例異常，但是集羣依然可以正常對外提供服務。此時，雖然不影響業務運行，但是主備實例切換將加重某些節點上的工作負載，時間久了，可能帶來這些對應節點上的資源耗盡，進而影響業務運行。因此集羣處於Degraded狀態時，建議儘快定位，使集羣恢復至Normal狀態。GaussDB Kernel提供瞭如下辦法，協助用戶在操作系統和硬件正常時的實例快速修復。

3、CN實例異常，優先通過刪除CN和增加CN進行實例恢復。

4、各類實例異常的通用辦法——修改HOSTNAME、IP和端口號。

二、重置實例狀態

1、操作場景

集羣在運行過程中，如果發生了主機或某些實例故障，集羣管理模塊會自動將備實例提升爲主實例繼續提供服務；或是由於數據庫集羣管理人員手工進行過主備切換操作後，使當前集羣各主機上運行的主實例（GTM，DN）數不均等，造成集羣負載不均衡，即集羣“balanced”狀態爲"No"。這種情況下可以通過集羣管理命令將集羣中的數據庫實例恢復爲初始配置的主備狀態。

存在實例異常時，需要先將實例修復後，才能進行重置。

2、處理方法

1.以操作系統用戶omm登錄數據庫集羣任一主機。

2.查詢並確認集羣運行狀態及“balanced”狀態。

“cluster_state”爲“Normal”表示集羣運行正常。“balanced”狀態爲“No”表示集羣實例發生過主備切換。

gs_om -t status --detail

3.使用如下命令查看集羣狀態確認是哪些節點上的實例發生過主備切換。

gs_om -t status --detail

例如下面示例中，node2節點上的主dn2發生過主備切換。該DN原始爲主DN（“state”中的字母“P”代表其初始爲Primary DN），當前切換成了備DN（“state ”狀態變成了“Standby Normal”）。

4.使用如下命令將集羣中發生切換的實例恢復爲初始配置的主備狀態。

gs_om -t switch --reset --time-out=300

300爲切換的等待時間，單位爲s。切換後集羣的“balanced”狀態變爲“Yes”。

3、示例

查詢當前發生過切換的實例。

gs_om -t switch
Operation: Switch query.
[     GTM State     ]

node                   instance             state
--------------------------------------------------------------------
(no need to switchover gtm)

[  Datanode State   ]

node     node_ip         instance            state  | node     node_ip        instance                      state            | node     node_ip        instance                       state
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
AZ1 1  plat1 192.168.0.11    6001 /gaussdb/data/data_dn1 P Standby Normal | 2  plat2 192.168.0.12   6002 /gaussdb/data/data_dnS1  S Primary Normal | 3  plat1 192.168.0.13   3002 /gaussdb/data/data_dnDS1  R Secondary Normal
Operation succeeded: Switch query.

若實例未發生過主備切換，則查詢結果中會顯示“no need to switchover xxx”。否則，則有實例發生過主備切換。例如，上例中通過查詢發現有一組主備DN都發生過切換。將發生切換的實例恢復爲初始配置的主備狀態。

gs_om -t switch --reset --time-out=300
Operating: Switch reset.
cm_ctl: cmserver is rebalancing the cluster automatically.
......
cm_ctl: switchover successfully.
Operation succeeded: Switch reset.

4、錯誤排查

如果重置實例狀態失敗，請根據日誌文件中的日誌信息排查錯誤。

如果指定的超時時間到達後，仍然有某些實例沒有完成狀態切換，可以根據提示，執行3查看切換實例的當前狀態，然後設置更長的時間再次執行或者通過log查看切換失敗的原因。重置操作的默認超時時間爲300s。

三、處理CN異常

集羣部署多個CN同時對外提供服務，CN的角色是對等的，即執行DML語句時連接到任何一個CN都可以得到一致的結果。而DDL語句需要在所有CN上都執行完成，以保持數據庫對象定義一致。如果其中一個CN發生故障，整個集羣將無法執行DDL語句，直到故障CN被修復或剔除。

如果只有CN異常，使用gs_replace工具可以快速將故障CN替換爲正常CN。具體請參見修復故障實例。

如果因網絡無法連接、硬件故障造成操作系統無法登錄等，短時間內無法恢復CN，又希望集羣儘快恢復DDL執行能力，可以先手動刪除故障CN。待DDL業務完成後，再通過增加CN功能將CN加回。

GaussDB Kernel也提供了CN自動剔除功能，此功能默認開啓，開啓和關閉方式請參見自動剔除故障CN。通過設置coordinator_heartbeat_timeout爲具體的時間值，則CN故障超過此時間值後GaussDB Kernel將自動剔除故障CN。

多AZ多集羣部署結構下：

AZ的拓撲結構應當保持相同（由運維人員保證），應當對所有集羣進行同樣的增刪CN操作，成功後集羣再開始同步操作。
CN部署結構變化，可能將引起Roach做全量同步，具體以Roach的約束爲準
增刪CN開始時，會自動停止Roach的自動同步操作，完成或者回滾後，需要用戶手動恢復自動同步配置。

1、刪除CN

1.1 操作場景

在集羣運行過程中，CN發生故障後，整個集羣將無法執行DDL操作。因此，如果CN發生故障且無法快速修復時，可以使用gs_om中的managecn把故障CN從數據庫集羣中刪掉，從而使集羣可以快速恢復正常工作。

1.2 注意事項

“cluster_state”爲“Unavailable”時，將無法執行刪除CN操作。
一次僅允許刪除一個CN。
如果因CN故障造成集羣處於Degraded狀態，此時如果執行刪除CN操作，必須先刪除因故障被剔除的CN，之後才能刪除其他CN。
若已開啓CN自動剔除功能，CM會自動將故障CN剔除，即從pgxc_node中刪掉，這樣DDL可以正常執行。CN被自動剔除後，不會再被拉起，必須刪除CN或通過實例替換、節點替換、溫備修復，才能進行擴容、升級等其他操作。
刪除CN前不能鎖定集羣，不能執行其他運維及變更類操作。
刪除完成後集羣中至少剩餘一個正常的CN。
數據庫安裝用戶有足夠的權限將新xml文件分發到所有主機的相同目錄下。
在執行刪除CN操作時，建議不要進行數據增刪改等DML操作以及DDL操作，以避免數據的丟失。
在刪除CN操作時，執行刪除命令的節點不能是要刪除的CN節點。
單CN的集羣不支持繼續縮容操作。
3CN以下的集羣不建議進行縮容操作，避免縮容過程中或結束後因爲CN故障導致集羣功能不可用。
部署kerberos情況下，同時縮容kerberos server主備ip所在的cn會導致集羣異常。

1.3 處理方法

1.以操作系統用戶omm登錄數據庫集羣任一主機。

如果所登錄的主機因網絡或操作系統等故障無法登錄，請更換爲登錄另一集羣主機。

2.修改集羣XML配置文件clusterconfig.xml。

請將要刪除CN對應主機上的cooNum值從1改爲0。

<!-- cn -->
<PARAM name="cooNum" value="0"/>
<PARAM name="cooPortBase" value="8000"/>
<PARAM name="cooDir1" value="/gaussdb/data/coordinator"/>

3.使用gs_om工具腳本執行刪除CN操作。

gs_om -t managecn -m delete -X /opt/software/GaussDB_Kernel/clusterconfig.xml

1.4 示例

刪除集羣內部節點上的CN實例。

gs_om -t managecn -m delete -X /opt/software/GaussDB_Kernel/clusterconfig.xml
Checking the cluster configuration difference.
Successfully checked the cluster configuration difference.
Checking the cluster status.
Successfully checked the cluster status.
Distributing the XML configuration file to all nodes.
Successfully distributed the XML configuration file.
Creating backup directory.
Successfully created backup directory.
Backing up cluster configuration.
Successfully backed up cluster configuration.
Modifying static configuration files.
Static configuration file's modification is completed.
Locking cluster.
Successfully locked cluster.
Dropping pgxc_node catalog.
Successfully dropped pgxc_node catalog.
Configuring pg_hba on all nodes.
Unlocking cluster.
Successfully unlock cluster.
Waiting for cluster status to become Normal or Degraded.
.
The cluster status is Normal.
Deleting the CN instance.
Successfully cleaned CN instance.

集羣運行過程中，某個含有CN的節點損壞短時間內無法修復（網絡無法連接、硬件故障造成操作系統無法登錄等），此時會造成其他CN無法執行業務，造成業務中斷。此時，可以選擇進行節點替換，但耗時較長，爲了儘可能的快速恢復業務，可以執行對該節點上的CN刪除。以故障節點爲SIA1000022048爲例：

gs_om -t managecn -m delete -X /opt/software/GaussDB_Kernel/clusterconfig.xml
Checking the cluster configuration difference.
Successfully checked the cluster configuration difference.
Warning: Failed to connect to the node SIA1000022048.
Checking the cluster status.
Successfully checked the cluster status.
Distributing the XML configuration file to all nodes.
Successfully distributed the XML configuration file.
Creating backup directory.
Successfully created backup directory.
Backing up cluster configuration.
Successfully backed up cluster configuration.
Modifying static configuration files.
Static configuration file's modification is completed.
Locking cluster.
Successfully locked cluster.
Dropping pgxc_node catalog.
Successfully dropped pgxc_node catalog.
Configuring pg_hba on all nodes.
Successfully configured pg_hba on all nodes.
Unlocking cluster.
Successfully unlock cluster.
Waiting for cluster status to become Normal or Degraded.
...........
The cluster status is Degraded.
Manage CN is completed.

如果執行完刪除節點SIA1000022048的CN後，該節點又從故障中恢復，此時該節點上記錄的集羣信息爲刪除CN前的，造成該節點與真實的集羣信息不相同，因此需要對該節點執行如下操作，以保障集羣信息的統一。

調用gs_om -t generateconf -X /opt/software/GaussDB_Kernel/clusterconfig.xml ，用最新的集羣配置文件重新生成各節點的靜態配置文件，並覆蓋此節點上的靜態配置文件。
調用gs_om -t stop -h SIA1000022048和gs_om -t start -h SIA1000022048對該節點進行重啓，使得新的集羣配置信息生效。
手動刪除節點SIA1000022048上的CN數據目錄（選做）。

2、增加CN

2.1 操作場景

當集羣中的CN數量無法承載業務運行壓力時，可以通過gs_om的managecn功能給集羣增加CN。同時，如果CN因故障被刪除後，可以使用增加CN功能將其加回。

2.2 前提條件

增加CN需要集羣處於Normal狀態。
在已有主機上增加CN，需要提前創建CN的數據目錄、日誌目錄。
在新增主機上增加CN，需要在配置文件中新增新主機的CM路徑並使用gs_preinstall工具準備好新主機的環境。
需要在一個狀態正常的主機上執行操作。

2.3 注意事項

一次僅允許增加一個CN。
增加CN前不能鎖定集羣，不能執行引起集羣狀態或結構變化的其他運維操作。
數據庫安裝用戶有足夠的權限將新xml文件分發到所有主機的相同目錄下。
增加CN過程中集羣可以執行業務，特別說明：由於過程中會短暫鎖集羣，鎖集羣后用戶下發的包含顯式啓動事務的DDL語句會出現等待，集羣解鎖後會報錯或等待時間超過20分鐘會報錯。如包含創建臨時表操作，在集羣解鎖後會報錯（Don’t support temp table when need reconnect pooler）。
增加、刪除CN過程中系統將關閉“自動剔除故障CN”功能，在完成後系統再次打開該功能。

2.4 處理方法

1.以操作系統用戶omm登錄數據庫集羣任一主機。

2.修改集羣XML配置文件clusterconfig.xml。

在已有主機上新增CN，請將要增加CN對應主機上的cooNum值從0改爲1。

<!-- cn -->
<PARAM name="cooNum" value="1"/>
<PARAM name="cooPortBase" value="8000"/>
<PARAM name="cooDir1" value="/gaussdb/data/coordinator"/>

在新增主機上增加CN，要求該主機上只能配有CN，不能包含DN、GTM、CM Server及ETCD。如下以增加集羣外的主機SIA1000056772上的CN爲例：

<!-- SIA1000056772的實例部署信息 -->
  <DEVICE sn="1000002">
   <PARAM name="name" value="SIA1000056772"/>
   <PARAM name="backIp1" value="10.180.122.136"/>
   <PARAM name="sshIp1" value="10.180.122.136"/>

   <!--cmserver-->
   <PARAM name="cmsNum" value="0"/>
   <PARAM name="cmServerPortBase" value="28601"/>
   <PARAM name="cmServerPortStandby" value="28611"/>
   <PARAM name="cmServerlevel" value="1"/>
   <PARAM name="cmDir" value=" /data_rt/bigcluster_rt/cmserver"/>
   <PARAM name="cmServerRelation" value="SIA1000056772,SIA1000056672"/>

   <!-- cn -->
   <PARAM name="cooNum" value="1"/>
   <PARAM name="cooPortBase" value="8000"/>
   <PARAM name="cooDir1" value="/gaussdb/data/coordinator"/>

   <!-- gtm -->
   <PARAM name="gtmNum" value="0"/>
   <PARAM name="gtmPortBase" value="6000"/>
   <PARAM name="gtmPortStandby" value="6500"/>
   <PARAM name="gtmDir1" value="/data_rt/bigcluster_rt/gtm,SIA1000056672,/data_rt/bigcluster_rt/gtm"/>
   <PARAM name="gtmRelation" value="SIA1000056772,SIA1000056672"/>

  </DEVICE>

3.進入安裝包解壓出的script目錄下，執行下面命令爲增加CN準備好前置環境。

./gs_preinstall -U  -G dbgrp -L -X /opt/software/GaussDB_Kernel/clusterconfig.xml --alarm-type=5

4.使用gs_om工具腳本進行增加CN操作。

gs_om -t managecn -m add -X /opt/software/GaussDB_Kernel/clusterconfig.xml

5.（可選）如果增加CN前修改過CN的GUC參數：log_dir，listen_addresses，local_bind_address，port，pgxc_node_name，pooler_port，log_directory和audit_directory。增加CN成功後，新CN無法同步先前的修改。請使用gs_guc工具以reload方式修改重新修改CN上的這些GUC參數。

2.5 示例

增加集羣內部節點上的CN實例。

前提條件：在xml中配置好需要增加的CN信息，執行前置命令。

gs_om -t managecn -m add -X /opt/software/GaussDB_Kernel/clusterconfig.xml
Checking the cluster configuration difference.
Successfully checked the cluster configuration difference.
Checking the cluster status.
Successfully checked the cluster status.
Distributing the XML configuration file to all nodes.
Successfully distributed the XML configuration file.
Creating backup directory.
Successfully created backup directory.
Backing up cluster configuration.
Successfully backed up cluster configuration.
Modifying static configuration files.
Static configuration file's modification is completed.
Locking cluster.
Successfully locked cluster.
Building CN instance.
Successfully built CN instance.
Creating pgxc_node catalog.
Successfully created pgxc_node catalog.
Configuring pg_hba on all nodes.
Unlocking cluster.
Successfully unlock cluster.
Waiting for cluster status to become Normal or Degraded.
.
The cluster status is Normal.

增加集羣外部服務器上的CN，首先用新增外部機器CN的配置文件執行前置，然後以下面命令進行外部增加CN操作，以增加SIA10000622109爲例。

gs_om -t managecn -m add -X /opt/software/GaussDB_Kernel/clusterconfig.xml
Checking the cluster configuration difference.
Successfully checked the cluster configuration difference.
Checking the cluster status.
Successfully checked the cluster status.
Distributing the XML configuration file to all nodes.
Successfully distributed the XML configuration file.
Creating backup directory.
Successfully created backup directory.
Installing GaussDB Kernel on the new node.
Checking installation environment on this node (SIA1000062209).
Installing applications on this node (SIA1000062209).
Synchronizing libcgroup configuration to this node (SIA1000062209).
Successfully installed GaussDB Kernel on the new node.
Backing up cluster configuration.
Successfully backed up cluster configuration.
Modifying static configuration files.
Static configuration file's modification is completed.
Locking cluster.
Successfully locked cluster.
Building CN instance.
Successfully built CN instance.
Creating pgxc_node catalog.
Successfully created pgxc_node catalog.
Configuring pg_hba on all nodes.
Unlocking cluster.
Successfully unlock cluster.
Waiting for cluster status to become Normal or Degraded.
.
The cluster status is Normal.

3、自動剔除故障CN

自動剔除故障CN功能默認開啓。
在單機部署場景下，自動剔除CN功能不生效，無需執行本節操作。

3.1 背景信息

集羣可部署多個CN同時對外提供服務，CN的角色是對等的，即執行DML語句時連接到任何一個CN都可以得到一致的結果。而DDL語句需要在所有CN上都執行完成，保持相關定義一致，如果其中一個CN發生故障，整個集羣將無法執行DDL語句，直到故障CN被修復。
爲了不影響用戶業務的執行，GaussDB Kernel 提供了CN故障自動剔除功能，系統檢測到CN故障後在限定時間內將CN自動剔除，用戶的DDL語句就可以繼續執行。

3.2 前提條件

無。

3.3 注意事項

自動剔除故障CN功能默認開啓，默認設置CN剔除時間爲25秒。用戶可根據自己實際場景和需求確定是否開啓功能，以及開啓後的剔除時間。
集羣中部署的CN少於2個不會自動剔除。多CN場景下，共N個CN時，最多剔除N-1個CN。如果開啓了自動修復CN功能（，已剔除CN的故障解除後，系統可以自動修復CN，或者用戶執行實例替換命令手動修復，參見手動修復剔除的CN。
CN故障被剔除後，CN會處於Deleted狀態，集羣處於Degraded狀態，用戶業務可以繼續執行不受影響，但是物理集羣的擴容、縮容、升級、增加CN、change IP操作將不能執行。

3.4 處理方法

開啓自動剔除故障CN功能，即CN故障後，自動剔除故障的CN。

gs_guc set -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=25"

關閉自動剔除故障CN功能，即CN故障後，不剔除故障的CN。

gs_guc set -Z cmserver -N all -I all -c "coordinator_heartbeat_timeout=0"

其中coordinator_heartbeat_timeout爲CN自動剔除的時間，單位是秒，默認值25秒，設置爲0表示關閉CN自動剔除功能，設置爲大於0的數字，表示開啓此功能，用戶可根據自己實際場景和需求確定剔除時間。

重新設置該參數後需要重啓cm_server進程或發信號 kill -1 cm_server進程號才能生效。

4、手動剔除故障CN

CN故障時，除了自動剔除還可以對CN進行手動剔除。在單機部署場景下，手動剔除CN功能不生效，無需執行本節操作。

4.1 注意事項

當coordinator_heartbeat_timeout參數設置爲0，自動剔除功能關閉時也可以執行手動剔除。

只有CN狀態爲down時，才能手動剔除該CN。

手動剔除CN時，若發生cm_server主故障，有可能會出現剔除超時，超時後重新執行剔除。

4.2 處理方法

執行如下命令進行手動剔除故障CN：

cm_ctl disable -n node_id -D data_path
node_id爲CN所在節點的ID，data_path爲CN的數據目錄路徑，可通過cm_ctl query -Cvd查詢。

5、手動修復剔除的CN

CN故障被剔除後（狀態顯示爲Deleted），數據庫支持自動修復方式和手動修復方式修復被剔除的CN。本小節說明手動修復方式，即手動執行實例替換命令。
在單機部署場景下，手動修復CN功能不生效，無需執行本節操作。

5.1 背景信息

CN手動修復時會短暫阻塞DDL，修復結束後DDL可以繼續執行。

5.2 前提條件

當前CN故障解除後才能啓動手動修復。
CN手動修復需要在集羣有正常的CN時才能成功。
如果觸發手動修復，自動修復會被停止。

5.3 注意事項

下述兩條命令需要關聯一起執行，若只執行gs_replace -t config -h而未執行gs_replace -t start -h則可能影響集羣功能，導致後續使用自動修復方式時功能不可用。

5.4 處理方法

執行如下命令，對需要替換實例的主機進行配置操作。配置操作會清理替換實例的空間，初始化替換實例，配置替換實例。

gs_replace -t config -h hostname

執行如下命令，對需要修復實例的主機進行啓動操作。

gs_replace -t start -h hostname

hostname是故障CN所在主機的主機名稱。

6、修復故障實例

數據庫集羣是由多臺主機組成的，當集羣中主機上的某些實例發生故障後，爲了使GaussDB Kernel快速地恢復正常，用戶可以使用gs_replace工具將發生故障的實例替換爲正常實例。

6.1 前提條件

集羣處於啓動狀態，且處於沒有加鎖。
修復操作需要在一個正常主機上執行。
一組DN的主實例、備實例，其中只能有一個損壞。
集羣內如下實例分別至少存在一個正常運行的：CM Server、CM Agent、GTM、CN。
如果集羣中部署有ETCD，則正常的ETCD個數必須大於ETCD總個數的一半。
如果集羣中未部署ETCD，某個GTM實例存在故障，則要求實例替換前另外一個GTM實例必須爲最高可用模式，即該GTM實例正常。
由於在修復實例時，會檢查並修復所有主機上故障的CM Agent實例，所以要求各主機必須互信正常，且安裝目錄下的二進制文件未被損壞。
強制修復多節點時，由於會停止需要修復節點內的所有CN，所以如果集羣的所有CN在指定修復的節點中，則不支持強制修復多節點。
強制修復多個節點時，由於會停止需要修復節點上的所有DN主、備實例，所以指定修復的節點的DN主、備均不能在同一個DN環內。
一主多備部署下，修復DN實例時，爲保證數據正確，DN環中必須有CM可監控的主存活。

6.2 注意事項

如果集羣中含有故障的CN且其狀態不爲Deleted，那麼在修復過程中用戶執行DDL會報錯，DML可以正常執行。其他場景執行業務不受影響，特別說明：由於修復CN的過程中會短暫鎖集羣，鎖集羣后用戶下發的包含顯式啓動事務的DDL語句會出現等待，集羣解鎖後會報錯或等待時間超過20分鐘會報錯。如包含創建臨時表操作，在集羣解鎖後會報錯（Don’t support temp table when need reconnect pooler）。
如果故障實例所在主機的安裝目錄下（$GAUSSHOME/bin/）的二進制文件損壞或丟失，則不能通過替換實例進行修復。需要複製其他正常主機對應的二進制文件到該主機，或者將該主機卸載後，再通過替換主機修復。
在前一次修復結束後才能再次執行修復。因此請不要同時在多個主機上執行修復操作。
實例修復操作會修復故障節點下的全部故障實例。
在修復實例的config階段，先將CM Agent組件修復好，這樣才能獲取到集羣中所有實例的狀態。如果主機上的某些實例被人爲停止，在CM Agent組件修復好之後，這些原來正常的實例會被正常拉起，而不會被修復。如果在一定時間內拉起失敗，這些實例將會被修復。
修復故障實例過程中系統將關閉“自動剔除故障CN”功能，完成後系統再次打開該功能。因此建議在開始修復前確認故障的CN已經被自動剔除（即故障的CN狀態爲Deleted），否則在修復過程中用戶執行DDL會報錯。
修復CN實例過程中，在CN狀態未變爲Normal前，不能連接該CN執行業務。
實例修復前用戶手動在故障實例上配置的guc參數、pg_hba.conf配置的白名單會丟失，需要重新設置。

6.3 處理方法

以替換主機plat1、plat2上的實例爲例。

1.以操作系統用戶omm登錄數據庫集羣任一主機。
操作系統用戶omm登錄的主機爲非故障主機。

2.（可選）使用如下命令在需要替換實例的主機上清理可能存在的殘留文件。此命令僅在上次修復故障實例執行失敗的情況下需要執行。

(if [ -f $PGHOST/GaussReplace.dat ];then rm $PGHOST/GaussReplace.dat;fi)

該文件爲替換故障實例、替換主機中產生的用於記錄執行步驟的臨時文件，如果在上次執行過程中出現宕機或網卡中斷等，可能會導致該文件殘留。在替換故障實例前檢查該文件是否存在，且生成時間非本次替換故障實例的時間，則可判斷爲上次執行的殘留文件，刪除該文件後，繼續執行替換故障實例。

3.使用如下命令對需要替換實例的主機進行配置操作。

gs_replace -t config -h plat1, plat2

配置操作會清理替換實例的空間，初始化替換實例，配置替換實例。

如果收到提示：“GAUSS_50201: The XXX does not exist.”，則請檢查對應的實例數據目錄是否存在。如果不存在，請重新創建目錄後再次執行上述命令。

如果指定主機的表空間所在磁盤出現故障，從而導致表空間中的數據損壞，更換新磁盤後，需要指定–force參數對該主機強制進行表空間數據的恢復。如果在config階段指定–force參數，則在start階段也必須指定–force參數。

4.使用如下命令對需要修復實例的主機進行啓動操作。

gs_replace -t start -h plat1 , plat2

啓動操作會啓動集羣替換實例的主機。

5.使用如下命令重置實例狀態。

switch爲維護操作：確保集羣狀態正常，所有業務結束，並使用pgxc_get_senders_catchup_time()視圖查詢無主備追趕後，再進行switch操作。

gs_om -t switch --reset

重置過程會恢復集羣初始狀態，以保證各主機的負載都是均衡的。

6.執行如下命令查詢集羣狀態。

gs_om -t status

7、修復DN增量build失敗

7.1 背景信息

在集羣DN增量build過程中，會先刪除部分數據，如果原主損壞，那麼主備均損壞。爲了集羣快速恢復正常，需要手動進行文件替換，然後恢復集羣，使集羣能夠正常運行。

7.2 前提條件

只在增量build的場景下。
集羣已安裝，增量build前集羣狀態正常。
只有DN環中包含的主實例、備實例故障，從備實例正常。
集羣內如下實例分別至少存在一個正常運行的：CM Server、CM Agent、GTM、CN。
由於在修復實例時，會檢查並修復所有主機上故障的CM Agent實例，所以要求各主機必須互信正常，且安裝目錄下的二進制文件未被損壞。

7.3 注意事項

pg_rewind_bak目錄爲增量build時備機的文件備份目錄，不能被手動修改。

7.4 處理方法

1.以操作系統用戶omm登錄集羣故障節點的主機。

2.停止所有CN和故障的DN主備從。

3.執行以下命令查看CN和故障DN所在節點信息。

cm_ctl query -Cvd

例如在一個含3個CN和12個DN的主備從集羣中，

CN :
node             instance                     state
-----------------------------------------------------
1  lfgp000710736 5001 /data1/mpp/coordinator1 Normal
2  lfgp000710735 5002 /data1/mpp/coordinator2 Normal
3  lfgp000710734 5003 /data1/mpp/coordinator3 Normal

故障DN :

3  lfgp000710734 6017 /data1/mpp/data1/master09 P Down    Disk damaged | 1  lfgp000710736 6018 /data1/mpp/data1/slave09  S Down    Unknown | 2  lfgp000710735 3010 /data1/mpp/data1/dummy09  R Secondary Normal

執行以下命令停止所有CN和故障的dn主備從。

cm_ctl stop -n nodenumber -D CN所在目錄
cm_ctl stop -n nodenumber -D DN所在目錄

其中，nodenumber，CN所在目錄，DN所在目錄可由1獲取。例如，

cm_ctl stop -n 1 -D /data1/mpp/coordinator1
cm_ctl stop -n 2 -D /data1/mpp/coordinator2
cm_ctl stop -n 3 -D /data1/mpp/coordinator3
cm_ctl stop -n 1 -D /data1/mpp/data1/slave09
cm_ctl stop -n 2 -D /data1/mpp/data1/dummy09

執行restore操作，需要登錄到故障的機器上。

gs_ctl restore -D /data1/mpp/data1/slave09

cm_ctl start方式啓動故障結點。

cm_ctl start -n 1 -D /data1/mpp/data1/slave09/　#先變成Standby Need

repair(Disconnected)，然後是Standby Promoting，這時候起來從備

啓動從備：

cm_ctl start -n 2 -D /data1/mpp/data1/dummy09

備機升主成功。

啓動原主機:

cm_ctl start -n 3 -D /data1/mpp/data1/master09

原主機啓動成功後降爲備機。

啓動CN結點，恢復業務:

cm_ctl start -n 1 -D /data1/mpp/coordinator1
cm_ctl start -n 2 -D /data1/mpp/coordinator2
cm_ctl start -n 3 -D /data1/mpp/coordinator3

檢查結點狀態是否恢復正常：

cm_ctl query –Cvd

數據校驗。

啓動業務。

在數據驗證完成後，啓動業務。

四、修改HOSTNAME、IP和端口號

1、背景信息

在數據庫集羣使用過程中，由於網絡部署調整、機房搬遷、網絡故障等帶來主機IP地址和端口號的變更。GaussDB Kernel提供了gs_om的changeip操作可以在不換主機、不改變集羣其他配置的前提下，快速實現集羣IP地址、主機名或者端口號的變更。

2、前提條件

確認集羣狀態正常後，停止集羣。
基於新IP、主機名的用戶互信已配置好。
數據庫安裝用戶有足夠的權限將新xml文件分發到所有主機的相同目錄下。

3、注意事項

僅換IP地址、主機名或者端口號，不換主機。
以數據庫安裝用戶執行腳本。
外部表IP不處理。
修改IP支持集羣backIP，sshIP，HaIP以及實例偵聽IP的修改。修改端口支持修改GTM、CN、ETCD、CM Server以及DN端口。
在修改集羣IP過程中，出現異常情況（斷電、宕機）時，通過“gs_om -t status”獲取到的集羣以及實例狀態信息是不準確的。重新執行修改集羣IP操作，正常結束後才能進行其它操作。
修改IP和端口號操作需要停止業務，執行過程中不支持數據庫DQL、DDL、DML、DCL操作。
當未配置實例端口時，實例初始化的默認端口爲cm_server主5000備5500；GTM主6000備6500；CN主8000備8500；DN主40000備45000從50000；ETCD主2379備2380。

4、處理方法

1.以root用戶身份登錄數據庫集羣任一主機。

2.修改集羣部署配置文件clusterconfig.xml，把主機的IP和hostname或者端口號替換爲新的。

3.進入安裝包解壓後的script文件夾。例如，安裝包存放路

爲/opt/software/GaussDB_Kernel。

cd /opt/software/GaussDB_Kernel/script

4.準備集羣環境。

./gs_preinstall -U omm -G dbgrp -X ../clusterconfig.xml --alarm-type=5

omm爲運行集羣的操作系統用戶，dbgrp爲操作系統用戶的羣組名稱，clusterconfig.xml爲集羣配置文件，此示例中假設其存儲在安裝包存放路徑下。

5.切換爲omm用戶。

su - omm

6.執行如下命令進行修改集羣IP操作。

gs_om -t changeip -X clusterconfig.xml
clusterconfig.xml爲修改後的配置文件。

如果執行修改集羣IP過程中出現錯誤，系統調用自動回滾。如果自動回滾過程中，因爲磁盤滿等原因，導致回滾失敗，則用戶排除錯誤後，如需繼續執行修改IP則調用本命令，如果要放棄修改IP，則調用如下命令將集羣恢復到修改ip之前的狀態：

gs_om -t changeip -X clusterconfig.xml --rollback

5、涉及修改參數列表

集羣的IP和端口號都需要使用gs_om工具進行修改。

點擊關注，第一時間瞭解華爲雲新鮮技術~

GaussDB(分佈式)實例故障處理

一、說明

二、重置實例狀態

1、操作場景

2、處理方法

3、示例

4、錯誤排查

三、處理CN異常

1、刪除CN

2、增加CN

3、自動剔除故障CN

4、手動剔除故障CN

5、手動修復剔除的CN

6、修復故障實例

7、修復DN增量build失敗

四、修改HOSTNAME、IP和端口號

1、背景信息

2、前提條件

3、注意事項

4、處理方法

5、涉及修改參數列表

Golang爬蟲代理接入的技術與實踐

MySQL查出時間比實際晚8小時的解決方案

什麼是IPD項目管理模式？聊聊IPD下的產品研發流程

aaaaaa1

Java編程工具：簡潔高效實現

Java word通過html設置樣式（Spire Docx）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結