昨天写了一篇

   看到这个错误，其实我的内心是很平静的，因为看起来明显是配置的问题。首先集群能够正常启动，其次集群的节点是使用了主机名的方式。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集群的问题修复算是告一段落。