暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

【经验分享】PT(persistent table)表异常导致gprecoverseg全量恢复失败的探索

Greenplum中文社区 2021-03-12
764

背景

最近来自中兴通讯的系统架构师、敏捷教练王爱军在工作过程中,遇到gp5.20通过 gprecoverseg -F做全量恢复失败的异常。master和primary的pg_log日志中打印internal error,然后primary crash。本文分享问题的定位过程以及涉及到相关概念,大家学习参考。

一、问题现象

1.1 集群状态查看

    [gpadmin@instance-eqmn04jr pg_log]$ gpstate -s

    1 Mirror Down

    1.2 全量恢复

      [gpadmin@instance-eqmn04jr pg_log]$ gprecoverseg -F

      2 gprecoverseg失败

      1.3 master日志

      3 master pg_log

      • 日志打印:QE执行command失败

        could not execute command on QE (cdbdisp_query.c:550)","Unexpected internal error (cdbpersistentfilespace.c:1163)。

      • QE:Query Executor对应primary segment。

      • QD:Query Dispatcher对应master。

      1.4 primary日志

      4 master pg_log

      日志中线索:

      • "cdbpersistentfilespace.c",1163行代码抛异常。
      • PersistentFilespace_AddMirror 被调用
      • gp_add_segment_persistent_entries被调用

      二、源码分析

      代码位置:src/backend/cdb/ cdbpersistentfilespace.c

      2.1 函数入口

      5 函数入口

      函数入参数说明:

      • filespace:文件空间oid

      • mirpath:mirror路径

      • pridbid:primary dbid

      • mirdbid:mirror dbid

      2.2 抛错代码1163行

      6 抛错代码

      代码分析可以得到:

      • filespace对应的dbId1和dbId2 都不等于当前的pridbid,因而抛异常。

      • PT表(gp_persistent_filespace_node )数据可能出现不一致。

      2.3 gp_persistent_filespace_node数据

      i. utility方式查看filespace的PT信息

        [gpadmin@instance-eqmn04jr cdb]$ PGOPTIONS='-c gp_session_role=utility' psql -dpostgres -p 25432

        7 PT filespace信息

        ii. 查看segment信息

          [gpadmin@instance-eqmn04jr cdb]$ psql -dpostgres

          8 segment信息

          很明显gp_persistent_filespace_node中的db_id_1=21是一个不存在的dbid,在进行filespace状态同步匹配不到,从而抛错。正确的db_id_1应该为port=25432对应的dbid=2。

          2.4 问题解决

          i.更新PT(gp_persistent_filespace_node表)为正确值。

            示例:

          9 更新PT

          (注:i.catalog表修改非常危险不要随意操作)

          ii.重启集群,然后再次全量同步恢复mirror。

          iii.PT表的修复需要在原厂专业人员指导下操作,否则可能会导致整个集群启动失败。

          2.5 问题回顾

          PT表的信息错误,遇到的非常偶然,该故障的定位和修复过程非常曲折,如不修复对整个集群有很大风险。

          该故障应该是gp5.20的版本bug,已反馈给原厂研发人员,但由于故障难以复现,修复可能需要一些时间。很可能是数据库负荷过重,在做gprecoverseg增量恢复的时候primary segment crash,进而导致的状态同步信息没有正确的更新到对应的PT表中。

          10 release notes

          三、概念说明

          3.1 PT 表

          PT(persistent table)的包含如下四张表,使用场景为通过gprecoverseg进行segment恢复,跟踪对象恢复的状态。

          1 PT

          3.2 实体对应的层次关系   

          11 实体层次关系

          为了提升IO能力,文件空间filespace可以指向高速存储,如ssd。表空间建立在对应的filespace,表建立在相应的tablespace上。创建文件空间的命令可以参考gpfilespace用法。PT表和filespace概念适用于gp5.x版本,gp6.x 取消了filespace以及PT表。

          四、总结

          本文总结了通过pg_log日志和源代码相结合,进行全量恢复失败的问题定位和解决过程。通过该方式可以洞悉问题的本源,对更好的运维Greenplum数据库提供帮助。

           

          五、参考信息

          https://github.com/greenplum-db/gpdb

          https://docs.greenplum.orghttps://cn.greenplum.org

          作者简介

          王爱军,中兴通讯系统架构师&敏捷教练20年来一直工作在一线的老码农,目前就职于中兴通讯。主要工作方向为5G网络管理系统架构,近期在使用和研究Greenplum。

          点击文末“阅读原文”,获取Greenplum中文资源。


          来一波 “在看”、“分享”和 “赞” 吧!

          文章转载自Greenplum中文社区,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

          评论