工作原理

pg_rewind是postgres-server安装包中的一个工具，用于在集群timeline发生分叉之后将副本之间的数据同步，pg_rewind的典型场景是在故障转移后，将旧master作为standby主机重新上线。 pg_rewind运行时，会使用源目录替换目标数据目录，但替换动作只会Copy文件中发生变化的Blocks。因此pg_wind相比pg_basebackup等工具有极大的性能优势。

下面的内容为了叙述方便，将运行pg_rewind的postgres实例称为target（待同步），正在运行Postgres实例称为source（同步源）。

pg_rewind基本工作原理：

  • pg_rewind比较source和target的timeline记录，并在target的pg_wal目录中寻找发生分岔之前最后一次checkpoint之后的wal记录。这些wal记录中包含了其修改的block文件信息，即发生分叉之后target上发生的文件修改。

  • 从source复制所有发生修改的文件（包括关联的文件）到target（PS：这里会跳过部分特殊目录，比如pg_dynshmem/等等）。

  • 在target上回放故障发生之前最后一个Checkpoint开始的所有WAL。pg_rewind会创建一个备份标签（backup label file），target机器初次启动时会进行replay。

pg_rewind要求target开启以下配置：

1
2

wal_log_hints = 'on'
full_page_writes = 'on'

需要注意：pg_rewind 并不能保证100%成功，对于pg_rewind不可恢复场景官方推荐是删除数据目录，重新创建副本。

pg_rewind失败因素，可能包括以下几种：

  • target在切换后依然运行了很长时间，此时旧wal日志可能已经发生老化并被删除。此时pg_rewind无法在target上找到分叉之后的wal日志，也就无法知道那些文件在分叉之后发生了改变。

    • 这种情况下，用户如果配置WAL备份，那么可以将wal日志手工Copy到pg_wal目录，来确保pg_rewind能正常运行。

  • target在运行pg_rewind后第一次启动时，它将进入recovery模式并在分叉点之后重放WAL日志，此时wal数据已经被source删除。（PS：执行pg_rewind是成功的，但是target启动失败）

    • 用户可以通过restore_command从wal备份中获取这些数据。
    • 开启Replication Slot，此时source不会删除target中还未同步的wal记录。

这篇博客对pg_rewind的工作原理有更加深入的分析：http://mysql.taobao.org/monthly/2018/05/05/

pg_rewind 需要的权限

使用非postgres用户执行pg_rewind时，需要以下权限：

1
2
3
4
5
6

CREATE USER rewind_user LOGIN;
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;

参考