数据库内核月报

数据库内核月报 - 2016 / 04

GPDB · 特性分析 · Segment事务一致性与异常处理

Author: 康贤

事务一致性

这篇月报Primary和Mirror同步机制讲了Primary和Mirror之间各种数据和文件的同步过程。这些数据和文件的同步,看似彼此独立。那么如何保证某个时间点Mirror的所有数据是一致的,即任何时间点发生HA切换,Mirror都能达到一致性状态并对外提供服务?正如我们前面提到的,这主要靠同步的顺序来保证:

  1. AO表的同步是个强同步的过程,数据在更新发生时即同步到Mirror,Primary和Mirror时刻保持着数据一致性。另一方面,事务提交时会更新AO表文件的尾指针信息,并同步到备库。这样事务提交后,Mirror肯定可以看到所有已提交的数据。所以Primary failover切换后AO表数据不会丢失,不影响事务的一致性。

  2. Heap表的数据的更新会写入相应的Xlog,同时确保Heap表数据页的同步必须在对应的Xlog同步完成后才能进行。

    你可能有疑问:Heap表的数据更新同步到Mirror是个异步的过程,那么会不会出现一个事务提交了,Heap表数据更新还没有来得及同步到Mirror,这时候Primary failover切换到Mirror,导致Heap表数据丢失?当然不会的,虽然Heap表数据同步是一个异步的过程,但是Xlog的同步却是一个强同步的过程。Primary failover切换到Mirror之后,Mirror上面的Xlog和Primary的Xlog完全一致,这时候Mirror会启动startup进程,进入Recovery模式,应用Xlog,所以即便Heap表数据没有同步过来,Mirror也会通过Xlog将这些没有过来的数据恢复。

  3. 其他文件的更新,其实不需要实时同步。切换时Mirror会回放Xlog,恢复这些文件的内容。

这样,如果Primary与Mirror保持同步,上述顺序保证了任何时间点Mirror节点的数据都能达到一致。但是,假如出现了网络阻塞或者Mirror宕机的情况,数据就无法及时同步到Mirror。此时,如果Primary在更新数据时,等待数据被同步到Mirror,就会被阻塞,而无法继续提供服务。为解决这个问题,Greenplum提供了异常处理机制。

异常处理

此处所说的对网络阻塞或Mirror宕机异常情况的处理,其实就是Greenplum所谓的Change Tracking机制。在Primary向Mirror同步数据的时候,如果Mirror长时间没有回应Primary,那么Primary将会认为Mirror挂掉,这个时候Master将会把系统表gp_segment_configuration里面的Mirror状态(status)置为’d’,同时把Primary的模式(mode)置为’c’,而这个’c’模式就是ChangeTracing Mode。Primary进入Change Tracking状态后,不会再试图同步数据到Mirror(每次有数据更改时会调用FileRepPrimary_IsMirroringRequired进行检查是否需要同步)。

Primary进入ChangeTracing Mode之后,每次更新数据产生的Xlog,会被立即解析成数据更新记录,放入到Change log文件里面(参见ChangeTracking_AddRecordFromXlog函数)。Change log文件在pg_changetracking/目录下:

-rw------- 1 bgadmin bgadmin    196608 Apr 10 18:22 CT_LOG_FULL
-rw------- 1 bgadmin bgadmin    403991 Apr 10 18:22 FILEREP_CONFIG_LOG
-rw------- 1 bgadmin bgadmin 105119744 Apr 10 18:22 FILEREP_LOG

ChangeTracing信息具体记录在CT_LOG_FULL文件里面,文件记录的核心信息是当前的数据更新在Xlog中的位置,文件内容经过解析之后如下:

postgres=# select * from gp_changetracking_log(0) limit 3;
 segment_id | dbid | space |  db   | rel  |   xlogloc    | blocknum | persistent_tid | persistent_sn
------------+------+-------+-------+------+--------------+----------+----------------+---------------
          0 |    2 |  1663 | 10893 | 5043 | (0/40000160) |        0 | (2,36)         |           538
          0 |    2 |  1663 | 10893 | 5043 | (0/400001C0) |        0 | (2,36)         |           538
          0 |    2 |  1663 | 10893 | 5043 | (0/40000220) |        0 | (2,36)         |           538

Change log里面只存放Heap表的修改信息。AO表的更新信息存放在特定的表中,无需另外记录。而Xlog和普通文件,都完整保存在Primary的数据目录下,无需记录修改信息(具体原因在异常恢复的说明中有介绍)。

Change log其实是存放的Heap表更改页的元数据信息,并未存放更改的实际内容。所以它并不占用太多存储空间,另外它还可以对相同页上的修改进行合并,进一步压缩大小,减少恢复时间(参见FileRepPrimary_RunChangeTrackingCompacting函数)。

那么,Mirror在宕机后重启或网络拥塞发生后恢复正常了,重新连接到Primary后,如何通过Change log恢复同步呢?