洞察纵观鸿蒙next版本,如何凭借FinClip加强小程序的跨平台管理,确保企业在数字化转型中的高效运营和数据安全?
700
2022-08-30
Greenplum数据库故障分析——能对数据库base文件夹进行软连接嘛?
案例背景
现场项目Greenplum数据库Standby Master节点宕机且一直没有重建成功,项目运维联系DBA团队接口人,团队DBA同事将故障转交给我进行分析,作为团队入职两年的小开发一枚,秉承通过故障分析才能快速切入学习数据库路径的原则,接下了这个活。通过分析HA组件(用于在Master节点挂时提升Standby节点;Standby节点挂时初始化并激活Standby节点)日志发现,HA组件报告修复Standby Master成功,但是gpstate工具显示Standby Master节点实际上依旧为宕机状态。HA组件执行gpinitstandby的日志如下所示:
gpinitstandby:xxx:gpadmin-[INFO]:-Warm master standby removal parametersgpinitstandby:xxx:gpadmin-[INFO]:-------------------------------------------gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master hostname = xxxgpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master data directory = /home/gpadmin/data/master/default/gpseg-1gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master port = 5432gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master hostname = xxxgpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master port = 5432gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master data directory = /home/gpadmin/data/master/default/gpseg-1gpinitstandby:xxx:gpadmin-[INFO]:-Removing standby master from catalog...gpinitstandby:xxx:gpadmin-[INFO]:-Database catalog updated successfully.gpinitstandby:xxx:gpadmin-[INFO]:-Removing data directory on standby master...gpinitstandby:xxx:gpadmin-[INFO]:-Successfully removed standby master.gpinitstandby:xxx:gpadmin-[INFO]:-Validating environment and parameters for standby initialization...gpinitstandby:xxx:gpadmin-[INFO]:-Checking for data directory /home/gpadmin/data/master/default/gpseg-1gpinitstandby:xxx:gpadmin-[INFO]:-------------------------------------------gpinitstandby:xxx:gpadmin-[INFO]:Greenplum standby master initialization parametersgpinitstandby:xxx:gpadmin-[INFO]:-------------------------------------------gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master hostname = xxxgpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master data directory = /home/gpadmin/data/master/default/gpseg-1gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master port = 5432gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master hostname = xxxgpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master port = 5432gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master data directory = /home/gpadmin/data/master/default/gpseg-1gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum update system catalog = Ongpinitstandby:xxx:gpadmin-[INFO]:-Syncing Greenplum Database extensions to standbygpinitstandby:xxx:gpadmin-[INFO]:-The packages on xxx are consistentgpinitstandby:xxx:gpadmin-[INFO]:-Adding standby master to catalog...gpinitstandby:xxx:gpadmin-[INFO]:-Database catalog updated successfully.gpinitstandby:xxx:gpadmin-[INFO]:-Updating pg_hba.conf file...gpinitstandby:xxx:gpadmin-[INFO]:-pg_hba.conf files updated successfully.gpinitstandby:xxx:gpadmin-[INFO]:-Starting standby mastergpinitstandby:xxx:gpadmin-[INFO]:-Checking if standby master is running on host: xxx in directory: /home/gpadmin/data/master/default/gpseg-1gpinitstandby:xxx:gpadmin-[WARNING]-Unable to cleanup previously started standby: 'Authorized only. All activity will be monitored and reportedgpinitstandby:xxx:gpadmin-[WARNING]-Could not start standby mastergpinitstandby:xxx:gpadmin-[INFO]:-Cleaning up pg_hba.conf backup files...
从上述日志可以发现gpinitstandby脚本初始化完成standby节点之后,不能启动standby master节点。
分析过程
不能启动standby master节点,首先就先看一下pg_log下的startup.log文件,从文件时间来看和当前集群时间对不上,说明postmaster守护进程启动时并没有打印什么报错信息。现在就只能看看是否是某些文件缺失导致的Could not start standby master。首先看一下master节点和standby master节点gpseg-1磁盘数据量对比,使用du -sh,可以看到大小差10个G左右(我们知道pg_basebackup做基础备份时会排除一些文件,这个10G数据差是有可能的)。到这里是没啥头绪的,直接对别一下master节点和standby master节点gpseg-1目录看看是不是缺失了些目录。这一对比发现,standby master节点gpseg-1中居然没有base数据目录。OMG,这是个大问题呀,如果现在一直修不好,后面客户业务量上来后,master节点撑不住,没有备份standby,那不是DBA的噩梦嘛。 base目录是pg_basebackup从master节点拉取的,也就是问题可能出在了pg_basebackup流程。从standby master节点的/home/gpAdminLogs下面查看pg_basebackup日志,发现如下警告。从日志看出pg_basebackup说base目录是特殊文件,WTF,啥意思。感觉看一下master节点gpseg-1下面base是个什么情况。
pg_basebackup: initiating base backup, waiting for checkpoint to completeWARNING: skipping special file "./base"pg_basebackup: checkpoint completedtransaction log start point: 0/30000028 on timeline 1 ...transaction log end point: 0/300000D0pg_basebackup: sync
master节点gpseg-1下面base不是一个目录而是一个软连接,由此可以发现pg_basebackup其实对软链接的处理不太到位(其实从开发角度看这样处理是正常的,因为standby master节点磁盘未知,重建软连接也不知道能不能成功,不如索性就略过)。跟业务交涉之后,由于业务一直没有对系统表进行过vaccum操作,导致元数据目录过大,夸张到上TB级别。最关键的是master节点的数据目录是在系统盘下,在系统盘告急的情况下,说我们数据库团队给提供了软链接方案,将base数据拷贝到外挂盘上,然后进行了软链接,他们测试部测试也没问题。。。
从standby master中找到base链接的路径,查看发现里面的数据是上TB的,而且文件日期有点久远呢,这可以猜测到业务肯定是在数据库 master和standby master都是正常时做的停机软链接目录的处理操作,之后一直没有管过这档子事了。gpinitstandby脚本会有一个流程Removing data directory on standby master...,但是为何没有删掉standby master中base链接的路径呢。删除的具体代码如下所示,可以看出时使用rsync进行删除的,经过测试发现rsync删文件不会删除软连接链接的目录。问题就此水落石出。
unique_dir = "/tmp/emptyForRemove%s" %uuid.uuid4() if [ -d {target_dir} ]; then mkdir -p {unique_dir} && rsync -a --delete {unique_dir} {target_dir} && rmdir {target_dir} {unique_dir}; fi
产生原因
rsync删文件不会删除软连接链接的目录pg_basebackup其实对软链接的处理不太到位
解决方案
从上述流程我们可以看出即使对base上一层做/home/gpadmin/data/master/default/gpseg-1软连接,在重建standby master时,gpinitstandby脚本也不会帮我们安装master配置的软链接重建standby master上的软链接,而是直接创建目录,因此该目录还是会在系统盘下,而不是我们新挂载的目录。只有对/home/gpadmin/data/master/default这层目录进行软链接,不要数据库功能帮我们重建创建,这样才能保证不管主备怎么倒换,数据会一直存在于我们链接的目录中。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~