昨天写了一篇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 TABLE testDB=# 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 fast 20180628:11:14:52:100415 gpstop:yz-dba-gp130-28:gpadmin-[INFO]:-Starting gpstop with args: -M fast 20180628: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 information 20180628: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 postgres psql (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 TABLE
testDB=# insert into customers(companyname,contactname,phone,country) values('a1','b1','c1','d1');
INSERT 0 1
整个验证算是通过了，后续和同事做了确认，对于其他的场景也做了一些细致的对比和测试，目前可以验证整个GP segment节点是可用的。
后续也做了一些外的补充和检查，GP集群的问题修复算是告一段落。
