PostgreSQL数据库数据同步——pg_rewind概念

Bertha 。 2022-08-30 12:55 409阅读 0赞

pg的高可用架构中，主库挂掉后，备库会自动升级为主库继续提供服务，对于原来的主库通常有两种处理方式：

*  删掉，重搭新备库。
 *  降级为备库，继续服务。  
    很显然，相比来说第一种不是个很好的方案，而且当数据量比较大时，重搭备库的时间成本太高。

但是因为老的主库挂掉的原因多种多样，甚至有可能是高可用系统的误判，而老主库也有可能是在挂掉之后又重新作为主库启动起来，这个时候降级并重搭流复制关系的操作就有可能失败（新的备库比新主库数据更超前）。为了解决这种情况，PostgreSQL 引入了pg\_rewind工具。

pg\_rewind 工具主要实现了从源集群到目的集群的**文件级别数据同步**。但是和rsync的区别是，pg\_rewind 不需要去读那些未变化的文件块，当数据量比较大而变化较小的时候，pg\_rewind会更快。  
先看下官方介绍：pg\_rewind是一个工具，**用于在群集的时间线发生分歧之后**，将PostgreSQL群集与同一群集的另一个副本进行同步。典型的方案是在故障转移后将旧的主服务器恢复联机，作为新主服务器之后的备用服务器。

pg\_rewind为了能够支持文件级别的数据同步，postgresql.conf必须配置如下参数

wal_log_hints=on
    full_page_writes=on

## 选项解析 ##

pg\_rewind检查源和目标集群的时间线历史，以确定它们发散的点， 并且**期望在目标集群的pg\_xlog目录中找到WAL，一直到达分歧点**。 在典型的故障切换情况下，目标集群在分歧后很快关闭，这不是问题， 但如果目标集群在分歧后运行了很长时间，旧的WAL文件可能不再存在。 在这种情况下，可以将它们*从WAL归档手动复制到pg\_xlog目录*。 目前不支持自动从WAL档案中获取缺少的文件。

当目标服务器在运行pg\_rewind之后第一次启动时， 它将进入恢复模式，并在发散点之后重放源服务器中生成的所有WAL。 如果在pg\_rewind运行时，源服务器中的某些WAL不再可用， 因此无法通过pg\_rewind会话复制，则需要在目标服务器启动时可用。 这可以通过使用合适的restore\_command 在目标数据目录中创建一个recovery.conf文件来完成。

pg_rewind [option...] { -D | --target-pgdata} directory { --source-pgdata=directory | --source-server=connstr}

\-D directory | --target-pgdata=directory：此选项指定与源同步的目标数据目录。目标服务器必须在运行 pg\_rewind之前完全关闭。  
–source-pgdata=directory：指定源服务器的数据目录的路径，以便与目标服务器同步。 当使用–source-pgdata时，源服务器必须完全关闭。  
–source-server=connstr：指定一个libpq连接字符串以连接到源PostgreSQL 服务器以与目标同步。连接必须是具有超级用户访问权限的正常（非复制）连接。 服务器必须已启动并正在运行，且不能处于恢复模式。当使用–source-server选项时，pg\_rewind 也使用libpq支持的环境变量。  
\-n | --dry-run：除了实际修改目标目录外，执行所有操作。  
\-P | --progress：启用进度报告。打开此选项将在从源群集复制数据时提供大致的进度报告。  
–debug：打印详细调试输出，对于调试pg\_rewind的开发人员来说非常有用。

## 具体实现 ##

为了在PostgreSQL 中实现文件级别同步数据的功能，pg\_rewind 主要进行了如下的处理步骤：

1.  在目的集群中找到源集群和目的集群的分叉点之前的最近一次checkpoint 点。这样相当于找到了在两个副本数据产生不同前的最后一个一致性位点。目的集群在这个位点之后所有的表数据变化都记录在这个位点之后的WAL 日志中。
2.  pg\_rewind 会将目的集群这些变化的数据页从源集群复制过来。这里会有2种方式：使用文件系统方式拷贝、使用 libpq 建立连接的方式拷贝。  
    总结来讲：pg\_rewind 可以快速找到两个集群数据开始分叉的点，然后找到目的集群从该点之后的数据变化，通过拷贝源集群的对应数据页，再通过应用源集群的WAL 日志达到数据一致。

它是怎么运行的？基本思想是将所有从新集群复制到旧集群，除了我们知道的那些相同的块。  
3. 扫描旧集群的WAL日志，从新集群的时间线历史记录从旧集群分出的点之前的最后一个检查点开始。 **对于每个WAL记录，记下被触及的数据块。 这将产生在新群集分叉之后在旧群集中更改的所有数据块的列表**。  
4. **将所有更改的块从新集群复制到旧集群**。  
5. 将所有其他文件（如clog和配置文件） 从新集群复制到旧集群，除关系文件外的所有内容。  
6. 从在故障切换时创建的检查点开始，从新集群应用WAL。 （严格地说， pg\_rewind不应用WAL， 它只是创建一个备份标签文件，指示当PostgreSQL启动时， 它将从该检查点开始重放，并应用所有需要的WAL。）

## 举例 ##

以greenplum数据的grecoverseg增量修复为例（GP的增量修复使用pg\_rewind同步primary和mirror）：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]  
\-D directory | --target-pgdata=directory：此选项指定与源同步的目标数据目录。目标服务器必须在运行 pg\_rewind之前完全关闭。如下gp情况下target-pgdata为/home/gpadmin\_postgis/gpdata2/mirror/default/gpseg3。  
–source-pgdata=directory：指定源服务器的数据目录的路径，以便与目标服务器同步。 当使用–source-pgdata时，源服务器必须完全关闭。gp这里不使用该选项。  
–source-server=connstr：指定一个libpq连接字符串以连接到源PostgreSQL 服务器以与目标同步。连接必须是具有超级用户访问权限的正常（非复制）连接。 服务器必须已启动并正在运行，且不能处于恢复模式。当使用–source-server选项时，pg\_rewind 也使用libpq支持的环境变量。如下gp情况下`source-server为"host=node196 port=40001 dbname=template1 applocation_name=__gprecoverseg_pg_rewind__"`。

PGOPTIONS="-c gp_session_role=utility" $GPHOME/bin/pg_rewind --write-recovery-conf --slot="internal_wal_replication_slot" --source-server="host=node196 port=40001 dbname=template1 applocation_name=__gprecoverseg_pg_rewind__" --target-pgdata=/home/gpadmin_postgis/gpdata2/mirror/default/gpseg3 --progress 2>&1

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]: /images/20220829/d6e6261aed37429ca55c0122eb4059f1.png