pg_rewind
文章目录
工作原理
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开启以下配置:
|
|
需要注意: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时,需要以下权限:
|
|
参考
文章作者 yoaz
上次更新 2022-01-07
许可协议 MIT