Greenplum xlog 损坏恢复

记一次 Greenplum 集群宕机恢复流程,网上相关资料比较少,主要问题是非正常关闭集群,导致 segment 的 xlog 损坏,最后通过pg_resetxlog 修复 xlog 之后,修改 Greenplum 系统表 gp_segment_configuration 来重置 segment 状态。

故障原因

微信报警系统通知有 8 个 mirror 节点 oom, 后来就没有启动,然后上服务器执行 gprecoverseg,提示已经有 gprecoverseg 进程在执行,看 GPCC 有多个查询,其中有一个比较大的 ETL SQL 正在执行,正常情况下 5min 就可以执行完,当时已经执行超过 20 分钟,尝试 kill 掉这个查询;kill 之后 GPCC 不可用了,无法连接数据库,psql 命令也无法连接数据库,等待几分钟之后集群没有相应,尝试重启集群(错误示范,这个操作非常危险),这时候集群就起不来了。

故障现象

集群 8 台机器,每台机器 6 个 primary 和 6 个 mirror 节点,一共 96 个 segment;

集群第一次重启过程中,不会去尝试启动之前 down 的 8 个 mirror,而其他节点则一直处于启动中的状态,系统无法使用,只能通过 gpstart -m 只启动 master 节点,后面又重启一次,尝试启动的节点数变为 48 个,显示 down 掉 48 个节点,后续多次重启都是这样了。

启动过程中 master 节点一直尝试连接各个 segment,显示日志 FTS: detected segment is in recovery mode and not making process,说节点处于恢复状态,但是实际并没有在恢复;

深入调查

各个 segment 日志则显示 The database system is starting up,看 postgres 相关进程,则显示 postgres startup process recovering 00000000XXX,后面这一串字符是 xlog 的位置,xlog 是 postgres 的事务日志(WAL 预写日志),pg_log 里面 segment 最开始的日志也会打印 end of transaction log location is 1F7/2CEXXXXX 的语句,把数据备份之后,尝试执行 pg_xlogdump pg_xlog/00000000XXX 也就是进程里面显示的正在恢复的文件,最后有个报错:error in WAL record at 1F7/2CEXXXXX: record with zero length at 1F7/2CEXXXXX,说这个位置的预写日志是空的,问题已经很明显,是这个 xlog 出错导致无法启动。

解决问题

把所有 segment 数据备份之后,各个节点执行 pg_resetxlog path_to_segment/ 命令即可,不需要加其他参数,这样就能启动这个 segment,最终把所有的 primary 节点恢复之后,gpstart -m 启动系统,默认情况下 GP 不允许修改系统表,需要使用 PGOPTIONS='-c gp_session_role=utility' psql 进入系统,执行 set allow_system_table_mods='1' 之后才允许修改系统表,然后更新 gp_segment_configuration 表各个 segment 节点状态 status,primary 节点状态改成 u,mirror 节点改为 d,这样就会只启动 primary 节点,然后修改 pg_hba.conf 文件,禁止其他用户登录系统,启动集群之后,检查数据完整性,恢复服务。


如果你不是非常有钱,请不要捐赠,土豪随意