Greenplum -- segment 死机后恢复

标签：sql查询   stat   存在   使用配置   text   sql   https   生成   from   

GPDB4.x中：是基于文件复制同步，如果个别segment宕机，整个数据库依然可以运行，当Mirror宕机时，Primary会记录在这个阶段文件变化的数据块，等到Mirror恢复了，再把数据块复制过去；当Primary宕机了，那么对于的Mirror节点就会替换Primary，记录文件变化的数据块，等到Primary恢复了，它就变成了Mirror，丢失的数据就会被复制过来，这里虽然可以继续运行，但是存在一个问题，那就是Primary和Mirror调换了，导致个别机器Primary比其他机器多，负载不均衡，最好还是把它从新恢复过正常对应关系来

二、恢复：

2.1、使用sql查询segment状态：

testdb=# select * from gp_segment_configuration;
存在部分segment down机的时候，在关闭的GPDB的时候，我们可以看到

再次启动时也一样，GPDB会忽略掉down机的segment，同时开启mirror备用

2.1、使用配置文件生成恢复文件

可以看到生成的配置文件里包含了需要恢复的segment节点

2.2、使用配置文件开始恢复机器

2.3、开启另外一个窗口，查看恢复状态：gpstate -m

Resynchronizing：正在恢复中，必须等待所有的都Synchronized才行

2.4、存在：Acting as Primary，说明有将mirror当primary使用了，必须等待所有恢复完毕之后，才能调换过来，调换过程会重启GPDB

执行命令：gprecoverseg -r

2.5、全部交换之后，查看备用mirror的状态 gpstate -m

2.6、sql查询各节点信息，都为up状态

Greenplum -- segment 死机后恢复

标签：sql查询   stat   存在   使用配置   text   sql   https   生成   from   

原文地址：http://blog.51cto.com/13126942/2339755