Greenplum叢集遷移與擴容實踐

記錄針對客戶的叢集遷移與擴容過程，針對該過程中的坑做一下總結。

場景描述

客戶現場有3台裝有greenplum的叢集，目前資料量約1T左右，客戶想再增加3台伺服器到叢集中。在此過程中，由于客戶想進行機房的搬遷，而在此過程中不長時間中斷業務的使用。是以就采用以下方案：

先在新的機房中安裝并部署greenplum叢集，然後将舊的叢集中的資料遷移到新的叢集中，先使用新的叢集開展業務，待舊的主機搬遷到新的機房後進行擴容加入。

檢查資料庫狀态

到客戶現場後，在資料遷移前先檢查舊的叢集的狀态，通過gpstate -e指令，發現叢集中segment的一些instance有挂掉的狀況，并是以導緻了primary和mirror角色的錯位。對于這種現象，使用gprecoverseg指令進行恢複，若恢複不成功，使用gprecoverseg -F進行全量恢複。在使用gprecoverseg指令進行恢複時，恢複失敗，不得已進行了資料庫的重新開機，又發現重新開機失敗，通過檢視gp_log目錄下的startup.log，可以獲得重新開機失敗的原因。重新開機失敗的原因是資料庫中的一個參數修改的太大導緻，這時，先在master節點上對該參數進行修改（在postgresql.conf檔案裡修改），然後通過gpstart -m指令重新開機mater節點，然後通過gpconfig指令修改其他節點的參數值，修改完成後重新開機資料庫即可。

繼續進行gprecoverseg -F進行全量恢複，在恢複過程中，通過gpstate -m檢視鏡像同步狀态，發現在進行資料同步時，速度非常的慢，當時沒有仔細去考慮該問題的原因，這位後續的資料遷移緩慢，埋下了伏筆。

叢集資料遷移

使用gptransfer指令進行叢集的遷移。

一個參考遷移指令是：

gptransfer -d test_db --source-map-file=host_source -a --dest-host=101.8.187.11  --batch-size=2 –truncate
           

該指令從源叢集遷移一個資料庫test_db到目标叢集，目标叢集的master節點IP為101.8.187.11，–truncate指令表示當執行遷移時，若發現目标叢集已經資料庫中已經有要遷移的表時，先進行truncate操作。

若想加快傳輸速率，可以通過修改參數–batch-size和–sub-batch-size來提高同時傳輸的表數和針對一個表起的并發數。

在遷移前，需要将表中的索引給删除，遷移完成後再進行重建。若在進行表的遷移時，對于大表使用gptransfer指令進行遷移，而對于小表，可以使用copy指令進行遷移。

在執行遷移時，出現

gptransfer failed.(Reason=’fe_sendauth:’ no passwd supplied)

的錯誤。此時，可通過修改目标叢集master節點上的pg_hba.conf檔案，增加對目标叢集所有節點主機的信任。例如，

将

host all all 0.0.0.0/0 md5

修改為

host all all 0.0.0.0/0 trust

在遷移過程中，發現遷移的速度非常慢，600G左右的資料，遷移了接近兩天。分析檢查原因，發現：

1. 叢集網絡有問題。

   對于該問題，對叢集進行資料的遷移前，一定要使用gpcheckpref指令進行網絡，磁盤等的檢測。在進行其他資料操作時，若發現異常的慢，也首先需要考慮使用gpcheckperf進行檢測。

2. 遷移過程中，表發生了死鎖。

   使用

   select * from pg_stat_activity;

   檢視哪些操作發生了死鎖。再使用

   select pg_terminate_backend(線程号);

   指令将死鎖的線程給幹掉。

在解決了死鎖問題後，gptransfer指令結束，并顯示一個錯誤消息并且把表名加到一個失敗的傳輸檔案中，可以檢視該失敗的傳輸檔案，對于由于死鎖而導緻傳輸失敗的表，單獨進行傳輸。

叢集擴容準備

在叢集進行擴容前，先需要檢查原叢集的磁盤，網絡等性能，使用gpcheckperf指令進行檢測。在進行檢測時，使用指令為：

gpcheckpref -f /home/gpadmin/hostfile_exkeys -r dns –d /home/gpadmin
           

其中hostfile_exkeys檔案包含叢集中所有節點的主機名。

發生如下錯誤：

[Error] command failed:time -p /home/gpadmin/gpcheckperf_$USER/multidd -i /dev/zero -o /home/gpadmin/gpcheckperf_$USER/ddfile -B 32768 -S 539799134208
           

定位該問題發現，gpcheckperf進行磁盤IO性能檢查時，會預設使用2倍于主機記憶體的檔案進行讀寫。當指定檢測時使用的目錄為/home/gpadmin/時，會在該目錄下建立一個gpcheckperf_$USER目錄來進行資料的讀寫（通過dd指令生成檔案進行讀寫）。而由于實體機記憶體比較大，而/home/gpadmin/目錄所在分區比較小，是以就會出現上述錯誤。

解決辦法：

指定一個大于實體機記憶體兩倍的目錄進行測試，同時該目錄必須要有gpadmin使用者的寫權限。

叢集擴容

叢集擴容可參考：

https://blog.csdn.net/hmxz2nn/article/details/86319300

在執行/home/gpadmin/目錄下執行

gpexpand -i gpexpand_inputfile -D expanddb

時，發生錯誤而失敗。

錯誤log：

ExecutionError: ‘non-zero rc: 2’ occurred. Details:’GPSTART_INTERNAL_MASTER_ONLY=1’ && /bin/tar cvPf gpexpand_schema.tar -C /opt/MPP1/disk/master/gpexpand_04102019_408836 .’ cmd had rc=2 complete=True halted=False
Stdout=’./
…
Stderr=/bin/tar:gpexpand_schema.tar:wrote only 4096 of 10240bytes
/bin/tar:Error is not recoverable:exiting now
           

通過本地複現及檢視gpexpand指令的python檔案代碼得到，在執行

gpexpand -i gpexpand_inputfile -D expanddb

時，會有如下操作：

1. 将master節點下的/opt/MPP1/disk/master/gpseg-1下的檔案拷貝至/opt/MPP1/disk/master下的一個臨時檔案夾，比如gpexpand_04102019_408836
2. 打包該臨時檔案夾，生成一個gpexpand_schema.tar檔案。比如執行指令

   /bin/tar cvPf gpexpand_schema.tar -C /opt/MPP1/disk/master/gpexpand_04102019_408836 .

   就是将gpexpand_schema.tar打包至目前目錄下，也就是/home/gpadmin/目錄
3. 将打包得到的檔案拷貝至新的主機對應目錄下，然後解壓縮至新主機的/opt/MPP1/disk1/primary/seg-1等目錄下。

同時，檢視發小gpseg-1目錄下檔案大小大于/home/gpadmin/目錄大小。由此找到問題原因所在：即原叢集master節點gpseg-1目錄下檔案太大，導緻打包時，要打包到的位置檔案空間不足。

補充：

在官方文檔中，對于使用gpexpand 進行擴容，有以下介紹：

在擴容前，驗證master的資料目錄中在pg_log或者gpperfmon/data目錄下有沒有極大的檔案。

解決辦法及注意事項：

在擴容前，確定/opt/MPP1/disk/master/seg-1目錄下的檔案大小不超過根目錄可用空間大小。

若路徑下确實有大檔案，可以先移動備份到其他位置，這樣既避免了可能的空間不足，又可以節省擴容時間。