本文分享自華為雲社區《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 示例

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.

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.

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的數字，表示開啟此功能，用戶可根據自己實際場景和需求確定剔除時間。

4、手動剔除故障CN

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

4.1 註意事項

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

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

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

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工具進行修改。

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