pg_rewind — 将一个PostgreSQL数据目录与另一个从其分叉而来的数据目录同步
pg_rewind [option...] { -D | --target-pgdata } directory { --source-pgdata= | directory--source-server= }connstr
pg_rewind是一个工具，用于在同一PostgreSQL集簇的两份副本时间线发生分叉后，将其中一份重新同步到另一份。典型场景是故障切换后，让旧主库重新上线，作为跟随新主库的备库。
其结果相当于用源数据目录替换目标数据目录。对于关系文件，只复制发生变化的块；其他所有文件（包括配置文件）都整体复制。pg_rewind相较于获取新的基础备份或使用rsync等工具，其优势在于pg_rewind无需通读集簇中未发生变化的块。当数据库很大而两个集簇之间只有少量块不同时，这使它快得多。
pg_rewind会检查源集簇和目标集簇的时间线历史，以确定它们发生分叉的位置，并且要求在目标集簇的pg_wal目录中能够找到一直追溯到该分叉点的 WAL。分叉点可能位于目标时间线、源时间线，或者二者共同的祖先时间线上。在典型的故障切换场景中，目标集簇会在分叉后不久关闭，因此这通常不是问题；但如果目标集簇在分叉后又运行了很长时间，旧的 WAL 文件可能已经不存在。在这种情况下，你可以手动把它们从 WAL 归档复制到pg_wal目录。pg_rewind的用途并不限于故障切换，例如，备库可以被提升，运行一些写事务，然后再回卷，重新成为备库。
运行pg_rewind之后首次启动目标服务器时，它会进入恢复模式，并重放源服务器在分叉点之后生成的全部 WAL。如果运行pg_rewind时，源服务器上的某些 WAL 已经不可用，因此无法由pg_rewind会话复制，那么在启动目标服务器时必须能够获取这些 WAL。这可以通过在目标数据目录中创建recovery.signal文件，并配置合适的restore_command（位于postgresql.conf中）来实现。
pg_rewind要求目标服务器满足以下条件之一：要么在postgresql.conf中启用了wal_log_hints选项，要么在用initdb初始化集簇时启用了数据校验和（默认即如此）。此外，full_page_writes也必须设置为on，不过它默认已启用。
如果pg_rewind在处理过程中失败，目标数据目录很可能已处于无法恢复的状态。在这种情况下，建议重新获取一份新的备份。
如果pg_rewind发现某些文件无法直接写入，它就会立即失败。例如，当源服务器和目标服务器对只读 SSL 密钥和证书使用相同的文件映射时，就会发生这种情况。如果目标服务器上存在这类文件，建议在运行pg_rewind之前将其移除。回卷完成后，其中一些文件可能已经从源复制过来，这种情况下可能需要删除复制过来的数据，并恢复回卷前使用的那组链接。
pg_rewind接受以下命令行参数：
-D directory--target-pgdata=directory此选项指定要与源同步的目标数据目录。在运行pg_rewind之前，目标服务器必须已正常关闭。
--source-pgdata=directory指定源服务器数据目录的文件系统路径，以便将目标与之同步。此选项要求源服务器已正常关闭。
--source-server=connstr指定一个 libpq 连接字符串，用于连接源PostgreSQL服务器，以便将目标与之同步。该连接必须是普通连接（非复制连接），所用角色要么拥有足够的权限以执行pg_rewind在源服务器上使用的函数（详见注解部分），要么是超级用户角色。此选项要求源服务器正在运行且不处于恢复模式。
-n--dry-run执行除实际修改目标目录之外的所有操作。
-N--no-sync默认情况下，pg_rewind会等待所有文件都安全写入磁盘。此选项会使pg_rewind不等待就返回，这样虽然更快，但也意味着如果随后发生操作系统崩溃，数据目录可能会损坏。通常，这个选项适合测试，但不应在生产环境中使用。
-P--progress启用进度报告。打开该选项后，在从源集簇复制数据时会给出大致的进度信息。
--debug打印详细的调试输出，这些输出主要对调试pg_rewind的开发人员有用。
-V--version显示版本信息，然后退出。
-?--help显示帮助，然后退出。
在使用--source-server选项时，pg_rewind也会使用libpq支持的环境变量（见Section 33.14）。
环境变量PG_COLOR指定是否在诊断消息中使用颜色。可能的取值是always、auto和never。
当使用在线集簇作为源执行pg_rewind时，可以使用一个具备足够权限以执行pg_rewind在源集簇上所用函数的角色，而无需使用超级用户。下面说明如何创建这样一个角色，这里将其命名为rewind_user：
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;
使用最近刚提升的在线集簇作为源来执行pg_rewind时，必须在提升后执行CHECKPOINT，使其控制文件反映最新的时间线信息。pg_rewind会使用这些信息检查能否利用指定的源集簇回卷目标集簇。
基本思路是将源集簇中所有文件系统级别的更改复制到目标集簇：
从源集簇的时间线历史与目标集簇分叉这一点之前的最后一个检查点开始，扫描目标集簇的 WAL 日志。对于每条 WAL 记录，记录它所触及的每个数据块。这样就能得到一份列表，其中包含源集簇分叉出去之后，目标集簇中所有发生过更改的数据块。
将所有这些发生过更改的块从源集簇复制到目标集簇，可以使用直接文件系统访问（--source-pgdata）或 SQL（--source-server）。
将所有其他文件，例如pg_xact和配置文件，从源集簇复制到目标集簇（关系文件除外）。与基础备份类似，目录pg_dynshmem/、pg_notify/、pg_replslot/、pg_serial/、pg_snapshots/、pg_stat_tmp/和pg_subtrans/中的内容不会从源集簇复制。任何以pgsql_tmp开头的文件或目录都会被省略，backup_label、tablespace_map、pg_internal.init、postmaster.opts和postmaster.pid也会被省略。
从故障切换时创建的检查点开始，应用源集簇的 WAL。（严格来说，pg_rewind并不应用 WAL，它只是创建一个备份标签文件，让PostgreSQL在启动时重放从该检查点起的全部 WAL。）