概述

客户的GP节点磁盘遭遇损坏,导致数据丢失。gprecoverseg命令无法恢复节点后做的一次非常规Greenplum恢复操作。

使用背景

在某次紧急运维下,我发现用户GP的某一个primary节点的状态异常,已经显示down掉,在确认所在的机器和磁盘没有异常后,我使用gprecoverseg命令去同步已经down的primary节点。但是失败了,在使用gpstate -e查看到的同步进度中看到同步了一会儿,但是随后失败了。(失败的原因是因为该mirror节点的磁盘曾经坏过,做过恢复,但是恢复的数据不是很完全,导致同步时校验出错),在该mirror节点的日志信息中查看到下面这段信息:

  1. 2019-03-16 21:30:35.341666 CST,,,p108637,th-1138622144,,,,0,,cmd126,seg-1,,,,,"ERROR","58P01","could not open relation 1663/43186/8782691: No such file or directory",,,,,,"(null)",0,,"md.c",1371,"Stack trace:
  2. 1 0xaf75c6 postgres errstart + 0x1f6
  3. 2 0x9f62ca postgres <symbol not found> + 0x9f62ca
  4. 3 0x9f7980 postgres mdnblocks + 0xf0

gprecoverseg命令会去从mirror节点获取数据去恢复primary节点,获取的数据多少在GP master的元数据表中都有记录,但是此时,mirror上的数据已经丢失,同步数据的进程到这里出错,因为找不到要找的表的数据,就直接退出,不再同步数据了,导致命令失败。

这种情况下,其实Greenplum的一主一备的高可用已经被破坏。数据已经永久丢失了,Greenplum本身没有什么好的办法恢复集群的状态了。

另辟蹊径

客户机器在mirror的支持下,依然是可以运行的,数据库的使用是正常的,但是客户担忧负载在一台机器磁盘上,依然会有风险,需要把GP恢复到完备的状态,其实我们还是有一个强行恢复Greenplum的方法

因为Greenplum的primary和mirror的文件目录的信息是完全一致的,不论是参数文件还是数据文件。我们完全可以手动将mirror上的文件目录拷贝过来,作为primary使用。但是要想让greenplum在下次启动时默认primary是好的去运行,还得做一些操作,完整如下:

将数据库先关闭,保证业务停止,mirror的数据目录不再有数据变化

  1. gpstop -m fast

将mirror的数据目录完整发送到primary的目录

  1. scp -r gpseg12 @sdw2:/data/primary/gpseg12 :示例

完成之后,再单独将master节点启动

  1. gpstart -m

进入到master数据库中(其实master数据库有三个template0,template1和postgres,这三个是全局的,进哪一个都一样)

  1. PGOPTIONS='-c gp_session_role=utility' psql template1

获取系统表的DML权限,以便后续修改状态

  1. set allow_system_table_mods='dml';

预防起见,将数据库的该系统表做一次备份

  1. create table 16_gp_segment_configuration as select * from gp_segment_configuration

将坏的节点全部状态信息改为正常,人为修改它的状态

  1. update gp_segment_configuration SET status='u' where dbid=3;

退出后关闭master节点

  1. gpstop -m

最后将数据库正常启动

  1. gpstart -a

启动完成之后,再看看集群的状态全部正常了。数据库也正常运行了。

后记

此种恢复的方法,关键点在于需要保证mirror作为数据目录,是可以正常运行的,也得保证将此目录完整的拷贝到primary中。

0 评论  
添加一条新评论