cp /etc/hosts /home/gpadmin/migrate
cp /etc/hosts.allow /home/gpadmin/migrate
cp /home/gpadmin/.ssh/id_rsa /home/gpadmin/migrate
cp /home/gpadmin/.ssh/id_rsa.pub /home/gpadmin/migrate
cp /home/gpadmin/.ssh/authorized_keys /home/gpadmin/migrate
cp /home/gpadmin/.ssh/known_hosts /home/gpadmin/migrate
cp /var/log/dmesg /home/gpadmin/migrate 備份系統日誌
cp /etc/sysctl.conf /home/gpadmin/migrate
ps -ef|grep post > /home/gpadmin/migrate/ps_os.lst
2.備份GP，PG配置文件pg_hba.conf
因為有上百個節點，所以節點的目錄結構會非常複雜，這部分的信息需要提前抓取，提前配置。
3.GPCC的配置備份。
GPCC這個工具整體來說還不錯，為了保證遷移前後的可用性，最後確認了下只需要修改下基本的配置文件即可。最壞的打算是GPCC無法啟動，我需要重新搭建和配置。
4.PG的配置和備份
比如有下面的一些PG實例，就需要提前把元信息記錄下來，方便後續的改動和配置。
-> ps -ef|grep post|grep data
postgres 00:00:59 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5533
postgres 00:00:59 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5534
postgres 00:00:58 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5535 +
postgres 00:00:58 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5536
postgres 00:05:00 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5532
5.其他的服務和配合
在檢查的時候，突然發現部分GP，PG的元數據有一個MySQL庫在存放，還有一個web應用opencron在運行，還有一個Django自建項目在運行，整個的過程會比開始的時候規劃的要複雜很多，比如相關的opencron的agent都需要重啟和配置，這個時候發現裡面的很多信息都是一環扣一環。
6.備份crontab信息和配置
crontab的信息在ETL端是信息大戶，這部分的信息還是需要提前備份。
7.監控的配置
監控是整個環節的一個輔助亮點，需要確保在遷移過程中不會有報警風暴。
8.數據的備份
這部分的備份，只能取到最小的結果集，對於GP集群而言，最起碼的DDL配置是要備份的，對於PG而言，屬於數據集市，結果集不大，所以可以考慮同步數據到其他的集群或者節點上。
整個遷移的過程和遷移後的一些小結：
1.對於停止GP集群，我們採用瞭如下的方式：
停止GP集群
重啟GP集群
停止GP集群
這樣確保集群沒有任何明顯的問題，遷移後是一個相對純粹的環境。
2.遷移後對於集群節點的關係可以使用gpssh來前期驗證，千萬不要著急重啟GP集群，準備好了一氣呵成。
3.對於GP節點間的互信關係，需要配置/etc/hosts.allow這個配置是之前測試中遺漏的。
4.對於segment節點中的pg_hba.conf配置，其實涉及的點非常多，每個節點有差不多5條變更，整體下來就是接近上千條變更了。這個過程一定要使用腳本，備份好之後果斷使用。
5.對於應用層面的權限和配置等，雖然看起來簡單，瑣碎，但是這個過程卻是也繞不過去，還是得花不少的功夫來反覆確認。
集群的遷移來說，基本就是修改IP，停止其他應用，停止集群，啟動集群，配置關係等等。事無鉅細，還是要關注細節。
閱讀更多 楊建榮的學習筆記 的文章
