整體來看，整件事的背景是服務器硬件超保，借超保服務器更換的契機，對集群架構進行優化改造。？
1.集群架構轉型的目標
目前存在的壹些潛在問題之前也有總結，這也是本次部署架構改進的目標:
1)之前，GP段數量設計過度，因為資源限制，過度考慮功能和性能，缺乏集群的穩定性和資源均衡性。每個物理機節點都部署了10主節點和10鏡像節點。壹旦1個服務器節點不可用，整個集群幾乎無法支持服務。
2)GP集群的存儲資源和性能之間的平衡不夠。GP存儲基於RAID-5。如果有壹個壞盤，盤重建的成本比較高，重建的時候如果又有壹個壞盤，那就很被動了。而且對線下倉庫的數據質量要求高，存儲容量比較小。所以綜合考慮存儲容量和性能，我們選擇RAID-10。
3)集群異常場景的恢復有待提高，集群異常情況下的故障恢復場景(如服務器非正常停機、數據節點不可用、服務器過保後節點滾動更換)測試不充分，導致在壹些遷移和改造中信心相對不足，存在壹些知識盲區。
4)集群版本太低，功能和性能還有提升空間。畢竟這個集群是4年前的版本，底層的PG節點版本也比較老，在功能和性能上有壹定的期待，至少能與時俱進。
5)操作系統版本升級。之前的操作系統是基於CentOS6的，至少需要適配CentOS 7。
6) TPCH集群壓力試驗驗收。集群部署後，需要進行整體的TPCH壓力測試驗收。如果有明顯的問題，它需要不斷調整配置和架構，以達到預期的性能目標。
此外，還有壹些應用層面的考慮。總之希望解決大部分痛點，無論是系統層面還是應用層面。
2.集群規劃設計的選擇與思考
明確目標，即把任務拆分出來進行規劃設計，在規劃設計中主要有以下幾個問題:
1)Greenplum版本選擇，目前主要有兩個版本類別，壹個是開源分發和Pivotal正式版。他們的壹個區別是，正式版需要註冊並簽署協議，在此基礎上可以使用GPCC等工具，而開源版可以實現源代碼編譯或rpm安裝，GPCC無法配置。綜合來看，我們選擇了6.16.2的開源版本，其中也問了壹些業內的朋友，特意挑選了幾個涉及到穩定性bug修復的版本。
2)數據集市的技術選擇。在數據集市的技術選型上，壹開始我堅持基於PostgreSQL的模型，而業務方則希望壹些復雜的邏輯能夠得到GP的支持。過了很久，又咨詢了壹些業內的朋友，可以選擇基於GP的方案，於是我們試壹試做了壹個壓力測試，這樣數據倉庫和數據集市就會由兩個不同大小和體積的GP集群來支持。
3)3)GP的產能規劃，因為之前的節點設計有點過分，所以我們減少了數量。每臺服務器有12個段節點，例如，壹臺***12服務器，其中10服務器為段節點，每臺服務器有6個主節點、6個節點和6個鏡像，另外兩臺有主備。
4)部署架構方案的選擇。部署架構相對容易想到，但是在實現中有許多細節需要考慮。首先，考慮到GP的主備節點混合使用可以節省壹些資源，因此數據倉庫和數據集市的部署架構就是這樣設計的。但進入部署階段後，很快發現這種交叉部署的模式並不可行，或者有壹定的復雜性。
此外，在單個GP集群的部署架構級別，有四個方案需要考慮。
？方案1:主備分段混合部署。
？方案二:主、備、段獨立部署，整個集群的節點數量會更少。
？方案三:分段獨立部署，部署主備虛擬機。
？方案4:最小化單節點集群部署(這是數據集市最安全的方案)？
這方面有很大的發揮空間，而且壹般來說這種驗證的成本比較高。實踐給了我壹個教訓。越想走捷徑，越會讓妳少走壹些彎路，有時候不知道怎麽改優化，感覺無路可走，所以我們其實對以上四個方案都做了相關的測試和驗證。
3.集群架構的詳細設計與實踐。
1)設計詳細的部署架構圖。
在總體規劃的基礎上，我設計了以下部署架構圖。每個服務器節點有六個主節點、六個鏡像節點和六個鏡像節點，這些服務器成對映射。
2)核參數的優化
根據官方文檔中的建議和具體配置，我們對內核參數進行了如下配置:
vm.swappiness=10
vm.zone_reclaim_mode = 0
vm.dirty_expire_centisecs = 500
VM . dirty _ write back _ centi secs = 100
vm.dirty_background_ratio = 0 #請參見系統內存
vm.dirty_ratio = 0
VM . dirty _ background _ bytes = 1610612736
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 3943084
vm.overcommit_memory=2
kernel.sem = 500 2048000 200 4096
4.集群部署步驟
1)第壹步是配置/etc/hosts，需要整理出所有節點的IP和主機名。？
2)配置用戶，這是壹個常規步驟。
groupaddgpadmin
useradd gpadmin -g gpadmin
passwd gpadmin
3)配置sysctl.conf和資源配置。
4)以rpm模式安裝
# yum install-y apr apr-util bzip2 krb5-devel zip
# rpm -ivh開源-greenplum-d b-6.16.2-rhel 7-x86 _ 64 . rpm
5)配置兩個主機文件也是為了方便以後統壹部署。建議先開放gpadmin的sudo權限，這樣壹些復雜的批量操作就可以通過gpssh來處理了。
6)通過gpssh-exkeys打通ssh信任關系，需要吐槽這個ssh信任，端口必須是22，否則處理起來會很麻煩，需要修改/etc/ssh/sshd_config文件。
gpssh-exkeys -f主機列表
7)壹個復雜的步驟是把master的Greenplum-db-6.16.2軟件打包，然後分發給各個段位機。整個過程包括文件打包、批量傳輸和配置。可以借助gpscp和gpssh來傳輸文件，比如gpscp。以下命令將被傳輸到/tmp目錄。
gpscp-f/usr/local/greenplum-db/conf/host list/tmp/greenplum-d b-6.16.2 . tar . gz =:/tmp
或者直接在每臺服務器上安裝rpm -ivh。
8)8)主節點需要單獨配置相關目錄，而段節點的目錄可以提前規劃。例如，我們將主服務器和鏡像服務器放在不同的分區中。？
mkdir-p/data 1/gp data/gp data 1
mkdir-p/data 1/gp data/gp data 2
mkdir-p/data 2/gp data/gp datam 1
mkdir -p /data2/gpdata/gpdatam2
9)整個過程中最重要的是gpinitsystem_config的配置，因為段節點和端口間隔的ID配置和命名都是按照壹定的規則動態生成的，所以要額外註意目錄的配置。
10)部署GP集群的關鍵命令是
gpinitsystem-c gpinitsystem _ config-s？待機主機名
gpinitsystem_config文件的主要內容如下:
主主機名=xxxx
declare-a DATA _ DIRECTORY =(/DATA 1/gp DATA/gp DATA 1/DATA 1/gp DATA/gp DATA 2/DATA 1/gp DATA/gp DATA 3/DATA 1/gp DATA/gp DATA 4/DATA 1/gp DATA/gp DATA 5/DATA 1/gp DATA/gp DATA 6)
TRUSTED_SHELL=ssh
declare-a MIRROR _ DATA _ DIRECTORY =(/DATA 2/gp DATA/gp datam 1/DATA 2/gp DATA/gp datam 2/DATA 2/gp DATA/gp datam 3/DATA 2/gp DATA/gp datam 4/DATA 2/gp DATA/gp datam 5/DATA 2/gp DATA/gp datam 6)
機器列表文件=/usr/local/greenplum-db/conf/seg _ hosts
整個過程大約5分鐘到10分鐘完成。部署過程中，建議查看後端日誌，看是否有異常。異常情況下的體驗不是很好，可能會浪費。
5.解決集群部署問題
集群部署還有很多細節問題，基本的我就不提了，基本都是配置，目錄權限等問題。讓我提幾個其他的例子:
1)資源配置問題。如果/etc/security/limits.conf的資源配置不足，安裝過程中會給出以下警告:
2)網絡問題。集群部署後可以正常運行，但是查詢數據時會拋出錯誤。例如，SQL看起來很簡單，如下所示:select count(*) from customer，但會引發以下錯誤:
這個問題的主要原因與防火墻配置有關。其實不僅要配置輸入的權限，還要配置輸出的權限。？
對於數據節點，您可以打開稍大的權限，例如:
入口配置:
-A輸入-p all -s xxxxx？-j接受
出口配置:
-A輸出-p all -s xxxxx -j接受
3)網絡配置問題。這個問題的詭異之處在於錯誤報告同上，只是排除了防火墻配置之後，選擇了count(*)from customer；；這樣的語句可以執行，但是等待執行的時間比較長。比如表格lineitem比較大，數據量過億。當有65，438+00個物理節點時，查詢響應時間為65，438+00秒，但對於4個物理節點，查詢響應時間為90秒，這讓整體刪除感覺不合理。
為了排查網絡問題，還測試了gpcheckperf等工具，4節點和10節點的基本配置是壹樣的。
gpcheckperf-f/usr/local/greenplum-db/conf/seg _ hosts-r N-d/tmp
$ cat /etc/hosts
127.0.0.1本地主機本地主機本地域本地主機4本地主機4 .本地域4
::1?本地主機本地主機.本地域本地主機6本地主機6 .本地域6
#127.0.0.1?測試-dbs-gp-128-230
xxxxx.128.238測試-dbs-gp-svr-128-238
xxxxx.128.239測試-dbs-gp-svr-128-239
其中127.0.0.1的配置在段主備混合部分有問題，修正後就好了。這個關鍵問題也被郭雲凱發現了。
5.集群故障恢復測試
集群故障測試是這個架構設計中的重點內容，所以這壹塊也是躍躍欲試。
總的來說，我們包括兩種場景，服務器停機修復後的集群恢復和服務器不可用時的恢復模式。
第壹種場景比較簡單，就是讓段節點重新加入集群，在集群級別交換主用和鏡像的角色，而第二種場景時間比較長，主要是數據節點需要重建，成本基本是PG級別的數據恢復。為了全面模擬整個測試和恢復，我們采用了類似的恢復方法，比如重啟服務器進行停機修復，在服務器不可用時清理數據目錄，類似於新配置的機器。
1)服務器停機修復後的集群恢復
select * from gp _ segment _ configuration where status！= ' u
gprecoverseg？-o/recov
gprecoverseg？-r
select * from gp _ segment _ configuration，其中status='u '
2)服務器不可用時的集群恢復
在重構數據節點的過程中，總體來說，網絡帶寬還是被充分利用的。
select * from gp _ segment _ configuration，其中status='u '
select * from gp _ segment _ configuration其中status='u' and role！=首選_角色；
gprecoverseg？-r
select * from gp _ segment _ configuration其中status='u' and role！=首選_角色；
測試後，重新啟動節點並修復數據大約需要3分鐘。
6.解決集群優化問題
1)部署架構優化和叠代
對於優化問題，是本次測試中特別關註和爭議的部分。？
首先，經過初步選擇，多倉系統部署比較順利，采用第壹套方案。
因為數據集市的集群部分的節點相對較少，所以選擇了第二種方案。
在實際測試過程中，由於配置問題，TPCH的結果並沒有達到預期。
所以現階段有壹些疑惑和質疑。壹種是轉回第壹種方案，但是節點數量會少很多，或者第三種是虛擬機的模式部署，最安全的方案是單節點部署。當然，這是最牽強的方案。
這個階段確實很難，但是經過上述配置的修復，集群仿佛豁然開朗，性能不錯，很快完成了100G和1T數據量的TPCH測試。
在隨後的改造中，我們也嘗試了第三種方案，基於虛擬機的模式。通過測試，發現和我們預想的相差甚遠。同壹個數據節點下，主備用的是物理機和虛擬機，性能相差很大，出乎意料。例如，對於同壹個SQL，執行方案3需要2秒，而執行方案2需要80秒。我們比較了這種差異的許多指標。最後，我個人理解，區別還是在網卡部分。
因此，經過比較，選擇了方案二的混合部署模式。
2)分析2)SQL性能優化
此外，整個過程的TPCH也為集群的性能提供了參考。比如方案二的混合部署模式，壹條SQL需要18秒，但相比同類型集群，可能只需要2秒左右，這顯然是有問題的。？
在消除了系統配置和硬件配置的差異之後，經典的解決方案是檢查執行計劃。
性能差的SQL執行計劃:
#解釋分析客戶選擇計數(*)；
查詢計劃？
合計(成本=0.00..431.00行=1寬=8)(實際時間=24792.916..24792.916行=1個循環=1)
？-& gt；聚集運動36:1(slice 1；段數:36)(成本=0.00)..431.00行=1寬度=1)(實際時間=3.255..16489.394行=15000000循環=1)
？-& gt；客戶順序掃描(成本=0.00..431.00行=1寬度=1)(實際時間=0.780..1267.878行=4172607循環=1)
規劃時間:4.466毫秒
？(slice0)執行器內存:680K字節。
？(slice1)執行器內存:平均218K字節x 36個工作線程，最大218K字節(seg0)。
使用的內存:2457600kB
優化器:Pivotal優化器(GPORCA)
執行時間:24832.611毫秒
(9行)
時間:24892.500毫秒
更好的SQL執行計劃:
#解釋分析客戶選擇計數(*)；
查詢計劃
合計(成本=0.00..842.08行=1寬度=8)(實際時間= 1519.311..1519.311行=1循環=1)
？-& gt；聚集運動36:1(slice 1；段數:36)(成本=0.00)..842.08行=1寬度=8)(實際時間=634.787..1519.214行=36個循環=1)
？-& gt；合計(成本=0.00..842.08行=1寬度=8)(實際時間=1473.296)..1473.296行=1個循環=1)
？-& gt；客戶順序掃描(成本=0.00..834.33行=4166667寬=1)(實際時間=0.758..438.319行=4172607循環=1)
規劃時間:5.033毫秒
？(slice0)執行器內存:176K字節。
？(slice1)執行器內存:平均234K字節x 36個工作線程，最大234K字節(seg0)。
使用的內存:2457600kB
優化器:Pivotal優化器(GPORCA)
執行時間:1543.611毫秒
(10行)
時間:1549.324毫秒
很明顯，實施方案是被誤導的，誤導因素是基於統計信息。這個問題的修復很簡單:
分析客戶；
但原因是測壓時先用了100G測壓，測壓後保留了原來的表結構，直接導入了1T的數據量，導致執行計劃沒有更新。
3)集群配置優化
此外，還做了壹些集群配置優化，比如調整緩存。？
gpconfig -c語句_mem -m 2457600 -v 2457600
gp config-c gp _ vmem _ protect _ limit-m 32000-v 32000
7.集群優化數據
最後，讓我們感受壹下集群的性能:
1)10個物理節點，(6+6)*10+2。
tpch_1t=# iming on
計時開始。
tpch_1t=# select count(*)來自客戶；
？數數？
-
150000000
(1行)
時間:1235.801毫秒
tpch _ 1t = # select count(*)from line item；
？數數
-
5999989709
(1行)
時間:10661.756毫秒
2)6個物理節點，(6+6)*6
#從客戶中選擇count(*)；
數數
-
？150000000
(1行)
時間:1346.833毫秒
# select count(*)from lineitem；
數數？
-
？5999989709
(1行)
時間:18145.092毫秒
3)4個物理節點，(6+6)*4
#從客戶中選擇count(*)；
數數
-
？150000000
(1行)
時間:1531.621毫秒
# select count(*)from lineitem；
數數？
-
？5999989709
(1行)
時間:2572.501毫秒
4)TPCH有19查詢模型，部分SQL邏輯過於復雜，暫時忽略，也是郭雲凱整理的列表。
1T基準下的基準性能: