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 parameters
gpinitstandby:xxx:gpadmin-[INFO]:-------------------------------------------
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master hostname					= xxx
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master data directory			= /home/gpadmin/data/master/default/gpseg-1
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master port						= 5432
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master hostname			= xxx
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master port				= 5432
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master data directory	= /home/gpadmin/data/master/default/gpseg-1
gpinitstandby: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-1
gpinitstandby:xxx:gpadmin-[INFO]:-------------------------------------------
gpinitstandby:xxx:gpadmin-[INFO]:Greenplum standby master initialization parameters
gpinitstandby:xxx:gpadmin-[INFO]:-------------------------------------------
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master hostname					= xxx
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master data directory			= /home/gpadmin/data/master/default/gpseg-1
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum master port						= 5432
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master hostname			= xxx
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master port				= 5432
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum standby master data directory	= /home/gpadmin/data/master/default/gpseg-1
gpinitstandby:xxx:gpadmin-[INFO]:-Greenplum update system catalog			= On
gpinitstandby:xxx:gpadmin-[INFO]:-Syncing Greenplum Database extensions to standby
gpinitstandby:xxx:gpadmin-[INFO]:-The packages on xxx are consistent
gpinitstandby: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 master
gpinitstandby:xxx:gpadmin-[INFO]:-Checking if standby master is running on host: xxx in directory: /home/gpadmin/data/master/default/gpseg-1
gpinitstandby:xxx:gpadmin-[WARNING]-Unable to cleanup previously started standby: 'Authorized only. All activity will be monitored and reported
gpinitstandby:xxx:gpadmin-[WARNING]-Could not start standby master
gpinitstandby: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 complete
WARNING: skipping special file "./base"
pg_basebackup: checkpoint completed
transaction log start point: 0/30000028 on timeline 1
  ...
transaction log end point: 0/300000D0
pg_basebackup: sync the target data directory
pg_basebackup: base backup completed

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这层目录进行软链接，不要数据库功能帮我们重建创建，这样才能保证不管主备怎么倒换，数据会一直存在于我们链接的目录中。