在greenplum數據庫運維過程中，會出現各種問題，上次分享的是因為磁盤問題導致數據庫的數據文件損壞，造成一些數據不能查詢，假如在上次的情況下，是主機的磁盤徹底損壞，造成數據庫的實例宕機，數據無法恢復，且主機換盤需要很長時間才能完成，但是又不能耽誤第二天的業務正常使用，那該怎么做呢，下面就來介紹下greenplum數據庫的備機替換流程，通過備機替換把有問題的主機踢出去，把正常的主機加到集群中，來完成集群的正常使用，根據集群數據量大小、集群規模大小及集群中業務表的使用情況，備機替換大概需要3到6小時之內完成，下面詳細介紹下備機替換流程及替換過程中遇到的問題。

1、環境準備

1.1、修改主機名：

備機：  sdw4192.168.100.106

問題主機：sdw3192.168.100.105

把備機的主機名修改成替換下來的主機名（源主機），保持主機名一致，然后修改/etc/hosts文件，修改需要替換主機的IP地址，操作如下：

檢查集群狀態，查看問題主機，確定要替換下來的主機名：

檢查確認sdw3主機為問題主機。

然后登錄備機修改主機名：

hostnamesdw3

vi/etc/sysconfig/network

NETWORKING=yes

HOSTNAME=sdw3

1.2、修改集群所有主機的/etc/hosts文件

原文件信息：

[root@mdw~]# cat /etc/hosts

127.0.0.1   localhost

#Greenplum   hosts start

192.168.100.101   mdw

192.168.100.102   smdw

192.168.100.103   sdw1

192.168.100.104   sdw2

192.168.100.105   sdw3

修改成如下

[root@mdw~]# cat /etc/hosts

127.0.0.1   localhost

#Greenplum   hosts start

192.168.100.101   mdw

192.168.100.102   smdw

192.168.100.103   sdw1

192.168.100.104   sdw2

192.168.100.106   sdw3

分發/etc/hosts文件到所有集群主機

source/usr/local/greenplum-db/greenplum_path.sh

集群做互信

[root@mdw~]# gpssh-exkeys -f /tmp/all_hosts

分發

gpscp-f /tmp/all_hosts /etc/hosts =:/etc/hosts

驗證是否分發成功

[root@mdw~]# gpssh -f /tmp/all_hosts

[root@mdw~]# gpssh -f /tmp/all_hosts

=>cat /etc/hosts|grep  sdw3

[sdw3]192.168.100.106    sdw3

[smdw]192.168.100.106    sdw3

[mdw] 192.168.100.106    sdw3

[sdw2]192.168.100.106    sdw3

[sdw1]192.168.100.106    sdw3

1.3、檢查主機參數

cat/etc/sysctl.conf

cat/etc/security/limits.conf

cat/etc/security/limits.d/90-nproc.conf

不一致遷移（若有不一致，將生產節點的參數文件scp到當前待替換節點）

scp192.168.100.106:/etc/sysctl.conf /etc/sysctl.conf

scp1192.168.100.106:/etc/security/limits.conf  /etc/security/limits.conf

scp192.168.100.106:/etc/security/limits.d/90-nproc.conf/etc/security/limits.d/90-nproc.conf

ulimit-a

使參數生效

/sbin/sysctl-p

1.4、檢查備機數據庫軟件包

如果備機中已存在greenplum數據庫對應的軟件包，且版本一致，則不需要操作，如沒有對應的軟件包，則從集群其他主機把軟件包拷貝到備機的相應目錄下，并賦對應權限，操作如下：

ls -lrt /usr/local

scp -r192.168.100.104:/usr/local/greenplum* /usr/local/

chown -R gpadmin:gpadmin greenplum*

rm -rf greenplum-dbgreenplum-cc-web（將未軟連接的文件刪除）

ln -s greenplum-db-5.23.0 greenplum-db

1.5、查看防火墻狀態

Redhat 6 版本

serviceiptables status

serviceiptables stop

Redhat 7版本

systemctlstatus firewalld

systemctlstop  firewalld

1.6、備機創建對應文件夾

備機創建和源主機相同的文件夾目錄

具體目錄根據集群目錄而定

chown-R gpadmin:gpadmin /data*  

mkdir/data{1,2}/{primary,mirror}

mkdir/data{1,2}/{primary,mirror}/{gpfs,default}

2、開始替換

2.1、禁止普通用戶連接

此處有兩種方式：

1、修改pg_hba.conf

vi$MASTER_DATA_DIRECTORY/pg_hba.conf

reject                  =====》禁止用戶連接

gpstop-u                =====》使配置生效

2、重啟數據庫到限制模式

停止數據庫：

gpstop-a -M fast

啟動數據庫：

gpstart-aR

2.2、進行數據全量恢復

gprecoverseg-F

開始數據同步，通過gpstate-e查看同步進度

數據同步完成

2.3、數據庫角色切換

開始進行primary和mirror實例的角色切換

gprecoverseg-r

查看進度如下：

角色切換完成

集群狀態正常

2.4、放開用戶連接

此處有兩種方式

1、修改pg_hba.conf

vi$MASTER_DATA_DIRECTORY/pg_hba.conf

#reject                  =====》解除禁止用戶連接

gpstop-u                =====》使配置生效

2、重啟數據庫到限制模式

停止數據庫：

gpstop-a -M fast

啟動數據庫：

gpstart-a

以上就是整個備機替換的操作流程，仔細觀察的話，會發現環境準備是備機替換的重要部分，環境準備如果有問題的話，在替換過程中就會出現各種報錯及問題，在替換過程中如果出現問題，請不要著急，把環境準備這塊仔細檢查一遍，然后再看問題，就會發現問題已經解決了。

3.1、集群主機的/etc/hosts沒有全部修改

在修改集群的/etc/hosts文件時，由于集群沒有做ssh互信，導致在修改時出現一些主機的遺漏，而遺漏的主機恰好和備機在一個數據環內，則會出現該主機對應備機上的實例無法恢復的情況。

3.2、備機主機參數不一致

這個問題在做備機替換的過程中不會出現問題，但是在替換完成過后使用中會出現問題，例如集群的用戶連接數設置為unlimited，但是備機的則是有限制的，在使用過程中就會出現segment主機連接數問題，導致實例宕機或者應用連接上不去等。

3.3、防火墻沒有關閉

防火墻沒有關閉，這個問題會出現在數據同步過程中，集群同步出錯。

3.4、備機對應文件沒有創建

如果備機對應的數據庫實例文件夾沒有創建，則會在同步過程中報文件夾不存在，數據無法同步問題，所以在環境準備的時候，一定要把對應的文件夾創建好。

以上就是我們在生產中遇到的一些常見問題，往往因為這些看似很小的問題，卻造成了很大的問題，浪費很多時間，所以細節決定成敗，磨刀不誤砍柴工，在做任何事情的時候，準備工作做充分，后續就會事半功倍。