开源组件之Greenplum数据库故障处理分享

RAID卡底层日志没有发现有reset、time out等异常打印

暂时排除磁盘问题，那还有哪里出问题会导致数据问题？顺其自然想到是否是GP数据库在primary实例和mirror实例数据同步的时候出现问题？

我们先来温故一下primary实例和mirror实例主备复制的机制。

大家都知道Greenplum 是基于PostgreSQL开发，PostgreSQL的主备也是通过流复制实现，但是Segment节点中的Primary和Mirror之间的数据同步是基于文件级别的同步方式实现的。为什么Primary和Mirror不能再使用流复制实现呢？

Primary和Mirror同步的内容主要有两部分，即文件和数据。之所以Primary和Mirror要同步文件，是因为Primary和Mirror之间可以自动failover，只有两者保持同步才能相互替代，如果只把数据同步过去，pg_control、pg_clog、pg_subtrans 没有同步，那么从Primary切换到Mirror就会出现问题。

GP master和GP slave却不用担心这些问题，Append Only 表的数据只会存在 Segment，所以WAL日志足够保持GP master和GP slave同步(只要是流复制，pg_control、pg_clog、pg_subtrans 这些文件Slave会自动更新，无需从Master同步)。

当GP master向Primary下发执行计划后，Primary开始执行，如果是DML操作，那么Primary会产生XLOG及更新page。会在SlruPhysicalWritePage函数中(写数据页)产生FileRepOperationOpen、FileRepOperationWrite、FileRepOperationFlush、FileRepOperationClose等指令消息(消息中包含具体要更新的文件page及内容)，通过primary sender进程向Mirror发送Message，然后Mirror的mirror consumer等进程解析消息，执行变更。XLOG通过XLogWrite函数(写XLOG)执行同样的操作，把XLOG更新同步过去。

Primary的recovery进程会循环把Primary的 pg_control、pg_clog、pg_subtrans 等文件覆盖到Mirror。同时检查XLOG是否一致，如果不一致以Primary为主，对Mirror进行覆盖。除把Primary部分文件同步到Mirror之外recovery进程还会将Mirror上面的临时文件删掉。

根据以上的机制，在实验环境做了两个实验进行验证：

正常情况下, 一个事务必须在primary和mirror都写入完成的情况下才会提交, 如果primary和mirror无法同步, 那么会在超时后将mirror标记为 down的状态。

1. 在master进行写入操作。

2. 在写入的同时, 破坏primary的table文件. (cat xxx >> [table file]), 模拟硬件/文件系统问题导致损坏的情况。

3. 写入完成后, 对表执行select操作。

1. 写入可以正常完成, 因为写入的操作的块文件正常完成(fsync)。

2. 由于文件被破坏, 因此在select的时候会报错。

3. 同时, 由于复制是基于块的同步, 因此primary的损坏操作(人为追加)不会同步到mirror上, 因此mirror上的文件没有问题。

1.当数据写入时, 数据块分两条线走, 一条发送给mirror, 一条到primary落盘。

2.GP只会检查数据块本身是否写入完成(fsync), 对于落盘之后的外部操作无法感知, 即硬件/系统问题引起的数据文件损坏在数据块落盘后是无法发现的

3.只有在之后读取到对应的数据文件时, 才会检查到数据块错误.

通过上面的实验可以了解到primary实例和mirror实例之间的同步机制：当数据写入时候, 数据块分两条线走, 一条发送给mirror, 一条到primary落盘，GP只会检查数据块本身是否写入完成(fsync), 对于落盘之后的外部操作无法感知, 即硬件/系统问题引起的数据文件损坏在数据块落盘后是无法发现的，只有在之后读取到对应的数据文件时, 才会检查到数据块错误。

上面实验报错明显的指出了是primary实例下的文件有校验不一致的情况发生，那我们接着往下看mirror的文件是否有问题。

这个该怎么验证？很简单，把出现问题的文件和对应mirror实例下的文件做个md5sum的校验，看结果值是否一致，如一致则表明mirror实例下的文件肯定也损坏了，如不一致，则把两个文件备份一份，再把mirror实例下的文件覆盖primary实例下有问题的文件，对有问题的表再做一次查询，看是否还报错，通过实验及测试，如果AO表使用上面的方法可以解决文件坏块的问题，则说明是文件损坏的问题，不是在primary实例和mirror实例之间同步数据造成，因为如果是同步数据造成的，mirror文件也会损坏。

问题分析到这里遇到了瓶颈，磁盘也没有问题，也不是数据库数据同步造成的，那该是什么原因造成的呢？

看来只能对损坏的文件进行分析了，把之前报错的文件全部收集出来对文件块进行分析，

数据文件 7398846.1: Block 124473 checkusm 错误

- 日志显示损坏位置为 block header offset in file = 644305640

- 通过解析该数据文件, 对应的block为 124473

- 数据文件显示block 21406存在checksum错误, head中的checksum与实际不符

- 同时, Mirror的文件正常

数据文件 15165123.1: Block 21406 checksum 错误:

- 日志显示损坏位置为 block header offset in file = 182856032

- 通过解析该数据文件, 对应的block为 21406

- 数据文件显示block 21406存在checksum错误, head中的checksum与实际不符

- 同时, mirror的数据文件正常。

目前我们可以确定, 数据文件的确存在受损的问题, 且损坏只发生在primary segment上。

下面我们对出现文件损坏的表在进行分析下：

- 我们在深入检查table文件之后, 发现primary并没有缺损, 事实上primary从08ed2000位置开始被写了"0"

- primary从08ed2000 到 08ee03e0 都是0, 而mirror并不是

- 同时, 16进制的08ed2000,08ee03e0分别对应10进制的149757952和149816288, 恰好都是是4096的整数倍(即这个位置是一个4096大小的block的开始)

- 同样另外一张表, primary的01110000开始到0111ecf0变成了0, 而mirror不是:

- 16进制01110000和0111ecf0分别对应10进制17891328和17951984, 同样是4096的整数倍。

综上所述, 经研发部门确认该问题并非GPDB造成, 因为GPDB从来不会对table文件写0。所以将从软硬件方面来继续排查问题 (XFS? LVM? SAN? RAID card？)。

问题分析到这里基本可以得出结论，造成Block checksum does not match问题的不是磁盘，也不是数据库软件本身的问题，但是还需要从主机系统等层面进行分析，已联系操作系统等相关厂商一起进行分析，后续有进展将继续分享。

这个问题目前的处理方法很简单，有两种：

1.找到该实例对应的mirror实例，在对应mirror实例下找到对应的数据文件，通过MD5SUM工具来校验mirror和primary实例下数据文件的值是否一致，通过mirror的文件来覆盖primary下的文件来解决；

2. 一般这种表都为历史时间分区表，数据可以通过hadoop集群重新写入，所以如果出现问题，则可以通过把该表删除，并重新入数来解决；

上面的讲到了GP数据库中文件的损坏，及排查思路，那怎么确定损坏的数据文件和表之间的关系，下面在一起了解下这个关系如何确定；

首先介绍下在GP数据库中表的存储格式：Heap表和AO表（AORO表，AOCO表）

从上面的这个错误信息可以看出表在primary实例对应的数据文件有损坏，遇到这个问题，首先想到的就是这个数据文件对应的是那个表，但是该如何通过数据文件查到对应的表呢？

熟悉GP数据库的工程师立马会想到通过pg_class 中的relfilenode 这个信息来找到对应的表例如：

这样就找到了对应的表，大家肯定会说这也太简单了，这种方式一般都是用来查heap表和一些刚好是AO表的数据文件对应的应用数据表。

但是GP数据库中AO表是一种比较特殊的表，每个AO表都有一个关联的系统表，该系统表用于管理文件系统上的段文件，所以我们可以查到下面两种结果，仔细看这两种结果有什么不同:

AO表的行存和列存在数据库中存储时名称是有区别的，区别如下：

AORO（行存）表名:  [pg_aoseg.pg_aoseg_xxxxxx>]

AOCO（列存）表名:  [pg_aoseg.pg_aocsseg_xxxxxx>]

这明显不是我们想要的表，遇到这种结果我们该怎么通过这个系统表来找到对应的表？

当年一些有经验的老鸟曾告诉过一种比较偷懒的办法是AO表的系统表结构中结尾都是数字结束的，这些数字就是该表所对应的relfilenode，我就试了下，结果如下:

还真的查到了，快捷方便，所以在接下来的一段时间里，我一直使用这种方式也解决了很多问题。

直到一次故障，让我意识到偷懒的办法只能用来偷懒，在遇到更棘手的故障时，这种纯经验式解决方法是行不通的。事情是这的，应用侧反馈又出现了Block checksum does not match的报错，把对应的数据文件号发给我后。按照老方法根据文件号，通过pg_class 中的relfilenode来找对应的表，找到后发现是张AO表，然后又根据AO表的系统表后面的数字找对应的表，结果这次没找，确认了好几次就是这个文件号，但是查出来的结果却是为空；

结果如下：

这让我意识到该办法不科学不严谨，不能予以依赖，通过基于原理的办法步骤来找对应的表。

首先想到AO表所有信息会存在pg_appendonly数据字典中，然后一步步按照流程来查询，最终找到了的对应表；

在后续通过几次实验得出了一个两张数据字典表的关联关系：

今天的GP故障分享就到这里，后续会继续带来现场各种问题处理的案例分享和心得体会，我们下次见。