本文分享自華為雲社群《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.
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的數字，表示開啟此功能，使用者可根據自己實際場景和需求確定剔除時間。
重新設定該引數後需要重啟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
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工具進行修改。
點選關注，第一時間瞭解華為雲新鮮技術~