昨天写了一篇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集群的问题修复算是告一段落。