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

本文主要是介绍【经验分享】PT(persistent table)表异常导致gprecoverseg全量恢复失败的探索,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

73fb7321-b931-460b-9e54-807a124126d8.jpg

 

了解更多Greenplum相关内容,欢迎访问Greenplum中文社区网站

背景

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

 

一、问题现象

 

1.1 集群状态查看

 

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

 

8214e94d-7648-4b3d-ae4f-ef3f64c1e9ed.png

图1 Mirror Down

 

1.2 全量恢复

 

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

 

5125f619-e267-43dc-963c-c81ba68685fa.png

图2 gprecoverseg失败

 

1.3 master日志

 

5e10f6d7-914d-492c-86c7-a43057183b48.png

图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日志

 

cfaceeac-daed-4833-9966-85ff1d51401b.png

图4 master pg_log

 

日志中线索:

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

 

二、源码分析

 

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

 

2.1 函数入口

 

51e6ecb9-2671-4a95-a513-3c178c7cf601.png

图5 函数入口

 

函数入参数说明:

  • filespace:文件空间oid

  • mirpath:mirror路径

  • pridbid:primary dbid

  • mirdbid:mirror dbid

 

2.2 抛错代码1163行

 

84bcf6d1-d1ee-48ec-8cb5-1eb8f2d78e93.png

图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

 

d6df3c08-bf23-4cfe-acc1-700ec9d13fed.png

图7 PT filespace信息

 

ii. 查看segment信息

 

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

 

ec1ffb79-1ccf-42ee-8542-044f95cf94c0.png

图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表)为正确值。

 

  示例:

1c484285-ac3e-4515-87ea-52bcf492ab1c.png

图9 更新PT表

 

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

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

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

 

2.5 问题回顾

 

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

 

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

 

 

57d25da0-94f1-4e94-9d15-8f3c7e27c783.png

图10 release notes

 

三、概念说明

 

3.1 PT 表

 

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

21af7a2c-57d5-4f21-b29b-e56dc1d70a2a.png

表1 PT表

 

3.2 实体对应的层次关系   

 

d8837381-f5f1-44d3-b910-fa7c41f2d0a3.png

图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.org

https://cn.greenplum.org

 

作者简介

 

王爱军,中兴通讯系统架构师&敏捷教练

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


up-f175fefbeb33b30075a094498c554b31130.png


 

这篇关于【经验分享】PT(persistent table)表异常导致gprecoverseg全量恢复失败的探索的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/162631

相关文章

java.sql.SQLTransientConnectionException连接超时异常原因及解决方案

《java.sql.SQLTransientConnectionException连接超时异常原因及解决方案》:本文主要介绍java.sql.SQLTransientConnectionExcep... 目录一、引言二、异常信息分析三、可能的原因3.1 连接池配置不合理3.2 数据库负载过高3.3 连接泄漏

javacv依赖太大导致jar包也大的解决办法

《javacv依赖太大导致jar包也大的解决办法》随着项目的复杂度和依赖关系的增加,打包后的JAR包可能会变得很大,:本文主要介绍javacv依赖太大导致jar包也大的解决办法,文中通过代码介绍的... 目录前言1.检查依赖2.更改依赖3.检查副依赖总结 前言最近在写项目时,用到了Javacv里的获取视频

Python中 try / except / else / finally 异常处理方法详解

《Python中try/except/else/finally异常处理方法详解》:本文主要介绍Python中try/except/else/finally异常处理方法的相关资料,涵... 目录1. 基本结构2. 各部分的作用tryexceptelsefinally3. 执行流程总结4. 常见用法(1)多个e

Debian 13升级后网络转发等功能异常怎么办? 并非错误而是管理机制变更

《Debian13升级后网络转发等功能异常怎么办?并非错误而是管理机制变更》很多朋友反馈,更新到Debian13后网络转发等功能异常,这并非BUG而是Debian13Trixie调整... 日前 Debian 13 Trixie 发布后已经有众多网友升级到新版本,只不过升级后发现某些功能存在异常,例如网络转

C#文件复制异常:"未能找到文件"的解决方案与预防措施

《C#文件复制异常:未能找到文件的解决方案与预防措施》在C#开发中,文件操作是基础中的基础,但有时最基础的File.Copy()方法也会抛出令人困惑的异常,当targetFilePath设置为D:2... 目录一个看似简单的文件操作问题问题重现与错误分析错误代码示例错误信息根本原因分析全面解决方案1. 确保

Python内存优化的实战技巧分享

《Python内存优化的实战技巧分享》Python作为一门解释型语言,虽然在开发效率上有着显著优势,但在执行效率方面往往被诟病,然而,通过合理的内存优化策略,我们可以让Python程序的运行速度提升3... 目录前言python内存管理机制引用计数机制垃圾回收机制内存泄漏的常见原因1. 循环引用2. 全局变

Java利用@SneakyThrows注解提升异常处理效率详解

《Java利用@SneakyThrows注解提升异常处理效率详解》这篇文章将深度剖析@SneakyThrows的原理,用法,适用场景以及隐藏的陷阱,看看它如何让Java异常处理效率飙升50%,感兴趣的... 目录前言一、检查型异常的“诅咒”:为什么Java开发者讨厌它1.1 检查型异常的痛点1.2 为什么说

SysMain服务可以关吗? 解决SysMain服务导致的高CPU使用率问题

《SysMain服务可以关吗?解决SysMain服务导致的高CPU使用率问题》SysMain服务是超级预读取,该服务会记录您打开应用程序的模式,并预先将它们加载到内存中以节省时间,但它可能占用大量... 在使用电脑的过程中,CPU使用率居高不下是许多用户都遇到过的问题,其中名为SysMain的服务往往是罪魁

Java异常捕获及处理方式详解

《Java异常捕获及处理方式详解》异常处理是Java编程中非常重要的一部分,它允许我们在程序运行时捕获并处理错误或不预期的行为,而不是让程序直接崩溃,本文将介绍Java中如何捕获异常,以及常用的异常处... 目录前言什么是异常?Java异常的基本语法解释:1. 捕获异常并处理示例1:捕获并处理单个异常解释:

Python自定义异常的全面指南(入门到实践)

《Python自定义异常的全面指南(入门到实践)》想象你正在开发一个银行系统,用户转账时余额不足,如果直接抛出ValueError,调用方很难区分是金额格式错误还是余额不足,这正是Python自定义异... 目录引言:为什么需要自定义异常一、异常基础:先搞懂python的异常体系1.1 异常是什么?1.2