【经验分享】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

相关文章

Ilya-AI分享的他在OpenAI学习到的15个提示工程技巧

Ilya(不是本人,claude AI)在社交媒体上分享了他在OpenAI学习到的15个Prompt撰写技巧。 以下是详细的内容: 提示精确化:在编写提示时,力求表达清晰准确。清楚地阐述任务需求和概念定义至关重要。例:不用"分析文本",而用"判断这段话的情感倾向:积极、消极还是中性"。 快速迭代:善于快速连续调整提示。熟练的提示工程师能够灵活地进行多轮优化。例:从"总结文章"到"用

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

电脑桌面文件删除了怎么找回来?别急,快速恢复攻略在此

在日常使用电脑的过程中,我们经常会遇到这样的情况:一不小心,桌面上的某个重要文件被删除了。这时,大多数人可能会感到惊慌失措,不知所措。 其实,不必过于担心,因为有很多方法可以帮助我们找回被删除的桌面文件。下面,就让我们一起来了解一下这些恢复桌面文件的方法吧。 一、使用撤销操作 如果我们刚刚删除了桌面上的文件,并且还没有进行其他操作,那么可以尝试使用撤销操作来恢复文件。在键盘上同时按下“C

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业

安卓链接正常显示,ios#符被转义%23导致链接访问404

原因分析: url中含有特殊字符 中文未编码 都有可能导致URL转换失败,所以需要对url编码处理  如下: guard let allowUrl = webUrl.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) else {return} 后面发现当url中有#号时,会被误伤转义为%23,导致链接无法访问

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出 在数字化时代,文本到语音(Text-to-Speech, TTS)技术已成为人机交互的关键桥梁,无论是为视障人士提供辅助阅读,还是为智能助手注入声音的灵魂,TTS 技术都扮演着至关重要的角色。从最初的拼接式方法到参数化技术,再到现今的深度学习解决方案,TTS 技术经历了一段长足的进步。这篇文章将带您穿越时

Thymeleaf:生成静态文件及异常处理java.lang.NoClassDefFoundError: ognl/PropertyAccessor

我们需要引入包: <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-thymeleaf</artifactId></dependency><dependency><groupId>org.springframework</groupId><artifactId>sp

深入理解数据库的 4NF:多值依赖与消除数据异常

在数据库设计中, "范式" 是一个常常被提到的重要概念。许多初学者在学习数据库设计时,经常听到第一范式(1NF)、第二范式(2NF)、第三范式(3NF)以及 BCNF(Boyce-Codd范式)。这些范式都旨在通过消除数据冗余和异常来优化数据库结构。然而,当我们谈到 4NF(第四范式)时,事情变得更加复杂。本文将带你深入了解 多值依赖 和 4NF,帮助你在数据库设计中消除更高级别的异常。 什么是