昨天寫了一篇Greenplum數據倉庫遷移小記，看起來一起都在計劃中，一切都在掌握中，今天早上的時候，統計組的同學反饋說寫入GP的時候報了下面的錯誤。
看到這個錯誤，其實我的內心是很平靜的，因為看起來明顯是配置的問題。首先集群能夠正常啟動，其次集群的節點是使用了主機名的方式。pg_hba.conf和防火牆層面都調整過了。如果有的話，看起來調整也不是難事。
根據裡面的錯誤信息，11.20.130.28是遷移前的Master節點IP,遷移後的IP是11.21.130.28
28 Jun23:02:19ERRORInterconnect Error: Could not connect to seqserver (connection: 11, host: 11.20.130.28, port: 60221). (seg0 slice1 yz-dba-gp130-31:40000 pid=80331)
但是當我連接到環境之後，檢查了所有的節點配置，依舊沒有任何的發現。
業務數據的提供是有一個時間段的，如果在指定的時間段裡數據出不來，對於問題的分析和處理就會有一種額外的壓力。
所以看起來很簡單的問題，但是我卻找不到可以修改的地方。所以我的注意力主要在三個地方：
1.是segment節點的配置問題，但是pg_hba.conf沒有找到這個IP的任何配置信息
2.是Master端的配置問題，但是pg_hba.conf沒有找到這個IP的任何配置信息
3.是客戶端連接的問題，客戶端還在使用錯誤的IP連接，雖然邏輯不通，但是不能完全排除其他的可能因素，比如外部表的引用方式等。
所以為了快速驗證這個問題，我使用瞭如下的方式創建了一個表，來簡單驗證是否是服務端出了問題。
不幸的是，拋出了類似的錯誤，所以根據錯誤，儘管在seg0拋錯，在其他的segment節點也應該是類似的問題。
testDB=# create table test_sequence(id serial, name text);NOTICE: CREATE TABLE will create implicit sequence "test_sequence_id_seq" for serial column "test_sequence.id"NOTICE: Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.HINT: The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.CREATE TABLEtestDB=# insert into test_sequence (name) values(1);ERROR: Interconnect Error: Could not connect to seqserver (connection: 11, host: 11.20.130.28, port: 60221). (seg0 slice1 yz-dba-gp130-31:40000 pid=130100)DETAIL: Connection timed out (connect errno 110)
這樣一個錯誤，讓我開始緊張起來。從原理上來說拋錯是指向seqserver,sqlserver可以理解為一個組件，所有的Segment獲取最新的Sequence都需要向Master的seqserver請求，然後seqserver更新Sequence的信息，返回給Segment。
所以順著這個思路來看，錯誤應該是segment連接Master的階段，所以錯誤應該需要在Master端來排查。
GP常用的數據字典gp_segment_configuration是首選，儘管我自己之前看了好幾遍，這次還是照例繼續核對下，沒想到這一看讓我開始有些慌張了，因為第1行的address字段是IP地址。
testDB=# select *from gp_segment_configuration; dbid | content | role | preferred_role | mode | status | port | hostname | address | replication_port | san_mounts ------+---------+------+----------------+------+--------+-------+-----------------+-----------------+------------------+------------ 1 | -1 | p | p | s | u | 5432 | yz-dba-gp130-28 | 11.20.130.28 | | 2 | 0 | p | p | s | u | 40000 | yz-dba-gp130-31 | yz-dba-gp130-31 | 41000 | 13 | 11 | p | p | s | u | 40001 | yz-dba-gp130-32 | yz-dba-gp130-32 | 41001 |
如此一來，整個GP集群的數據字典信息竟然有這樣的配置錯誤，讓目前的狀態很是糾結。
如果重新備份和導入數據，幾十TB的數據，導出和恢復都需要好幾天，這還不包括業務的影響時間和範圍，重新部署和搭建的代價。
否則還有什麼辦法呢，直接改數據字典的信息，改錯了之後，整個GP集群都不可用，那麼我們基本就可以歇菜了。
把服務器重新搬回原機房，估計系統部的同學會砍我。因為這個代價幾乎沒法衡量，同時我沒法保證一切都完全可控。
我重新配置一個本地的“虛”IP,比如服務器IP是11.21.130.28.我們內部從11.20.130.28來跳轉到11.21.130.28，但是顯然從網絡配置上就行不通。
如果我配置的是11.20.130.28_s這種字符串格式，那麼還能有一些希望，目前的純IP方式已經沒有了可能。
隨著時間一點一點過去，我們開始尋找各種可能性和方法。顯然快速解決方法，同時保持系統穩定是主線。
Greenplum能否直接修改主機名，雖然沒有完全確認，但是查看GP的一些資料，這個方法理論是可行的，至於修改之後是否可用，目前還不夠明朗。
那麼我們就需要測試和模擬，如果修改之後不可回退，導致GP集群不可用，那麼手工修改的方式我們就可以直接放棄，否則還是可以一試的。
所以我們沒有一上來就修改正式環境，先找了一個測試環境開始模擬。
初步的結論是如果配置失敗，會導致集群無法啟動，但是可以回退該配置。
所以有了這一個基本的基礎，我們開始嘗試修復。
停止GP集群。
$ gpstop -M fast20180628:11:14:52:100415 gpstop:yz-dba-gp130-28:gpadmin-[INFO]:-Starting gpstop with args: -M fast20180628:11:14:52:100415 gpstop:yz-dba-gp130-28:gpadmin-[INFO]:-Gathering information and validating the environment...20180628:11:14:52:100415 gpstop:yz-dba-gp130-28:gpadmin-[INFO]:-Obtaining Greenplum Master catalog information20180628:11:14:52:100415 gpstop:yz-dba-gp130-28:gpadmin-[INFO]:-Obtaining Segment details from master...下面的步驟是關鍵，使用如下的方式來連接到GP Master:[gpadmin@yz-dba-gp130-28 ~]$ PGOPTIONS='-c gp_session_role=utility' psql -U gpadmin postgrespsql (8.2.15)Type "help" for help.開啟系統表修改的設置。postgres=# set allow_system_table_mods='dml';SET查看GP segment的配置：postgres=# select *from gp_segment_configuration; dbid | content | role | preferred_role | mode | status | port | hostname | address | replication_port | san_mounts ------+---------+------+----------------+------+--------+-------+-----------------+-----------------+------------------+------------ 1 | -1 | p | p | s | u | 5432 | yz-dba-gp130-28 | 11.20.130.28 | | 2 | 0 | p | p | s | u | 40000 | yz-dba-gp130-31 | yz-dba-gp130-31 | 41000 | 13 | 11 | p | p | s | u | 40001 | yz-dba-gp130-32 | yz-dba-gp130-32 | 41001 | 開始修改該配置：postgres=# update gp_segment_configuration set address='yz-dba-gp130-28' where dbid=1 and hostname='yz-dba-gp130-28';UPDATE 1
整個過程很快就完成了。推出GP集群命令行，並停止GP集群。
postgres=# \q[gpadmin@yz-dba-gp130-28 ~]$ gpstop -m
啟動GP集群 gpstart -a，整個過程算是順利完成了，我們來開啟一個初步的驗證。
創建一個表customers,然後插入一行數據啟用自增列。
testDB=# CREATE TABLE customers testDB-# ( testDB(# customerid SERIAL primary key , testDB(# companyname character varying, testDB(# contactname character varying, testDB(# phone character varying, testDB(# country character varying testDB(# ) ;NOTICE: CREATE TABLE will create implicit sequence "customers_customerid_seq" for serial column "customers.customerid"NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "customers_pkey" for table "customers"CREATE TABLEtestDB=# insert into customers(companyname,contactname,phone,country) values('a1','b1','c1','d1');INSERT 0 1整個驗證算是通過了，後續和同事做了確認，對於其他的場景也做了一些細緻的對比和測試，目前可以驗證整個GP segment節點是可用的。
後續也做了一些外的補充和檢查，GP集群的問題修復算是告一段落。
閱讀更多 楊建榮的學習筆記 的文章
