（如果不知道在说什么的，请参见之前的 6期文字 谁说postgresql 没有靠谱的高可用 1-6）
清早有一个数友，提出了一个问题，参见上图。一般来说数据库如果做了高可用（主从，非支持分布式协议的那种，类似REPMGR），在主从切换后，是可以将主变为从，继续rejoin 到repmgr 的HA中的。
首先我们要确认的是，我们已经有了两台POSTGRESQL ， 并且已经安装了 REPMGR 并且，已经启用了 repmgrd 自动检测failover 的进程在两台机器上。
主库
secondary
问题应该就从这里开始，我们来捋一捋，如果主库挂了有几种情况
1 主库由于某些原因，短暂的不能工作，后面立即启动，在判断切换的时间以内，按照之前的 文字我们设置的是 6次 10秒， 整体应该是1 分钟后开始切换。
2 主库无法启动，主从已经切换，然后我们需要将主库在加入到集群中充当从库，这就是问题的开始
情况1 系统切换，但是在夜间系统并未进行大量的数据的DML 操作，并且主库也并未收到很严重的损伤，无法启动。
系统开始切换的准备和判断
最终 192.168.198.22 变成了主库
我们启动了 192.168.198.21 ,然后这就是问题中提到的出现的问题
我们怎么办，
repmgr node rejoin -f /etc/repmgr.conf -d 'host=192.168.198.22 dbname=repmgr user=repmgr' --force-rewind --config-files=postgresql.conf --verbose
执行上面的这条命令，失效的主节点就会在加入到，新的主节点22 中
并且系统的启动，以及repmgr 注册的信息都会通过这一条命令完成。
那到此就结束了吗，有没有可能执行失败，上面的命令到底的本质是什么
pg_rewind，pg_rewind做了什么
扫描目标集群的WAL日志，从源集群的时间轴历史与目标集群分叉之前的最后一个检查点开始。对于每一条WAL记录，记录每一个被触摸的数据块。这将生成在源集群分叉之后目标集群中更改的所有数据块的列表。
使用直接文件系统访问(-source-pgdata)或SQL (-source-server)将所有更改的块从源集群复制到目标集群。
将所有其他文件(如pg_clog和配置文件)从源集群复制到目标集群。
从故障转移时创建的检查点开始，从源集群应用WAL。(pg_rewind并不应用WAL，它只是创建一个备份标签文件，让PostgreSQL从这个检查点开始回放所有的WAL。)
那pg_rewind 的执行需要哪些条件，为什么我执行上面的命令就失败，请参考之前的关于 pg_rewind 的文字。
这里一句带过 wal_log hit 要开，full page 要开， 另外在执行这个命令的时候，如果失败很可能会毁掉当前要加入集群的节点再次可以启动数据库的可能性，所以建议运行这个命令时，做好其他准备。
问题，如果失败了怎么办。
可以重新将失败的节点的数据清空，然后参考 Postgresql 谁说没有靠谱的高可用 ·1-6 重新制作即可。然后在重新运行 上的命令 （另一个人有时候想不了周全，有些东西可能一带而过，见谅）
另外失败的原因还可能由于新主工作比较频繁，产生了大量wal log ，然后失效的库并未在最短的时间进行恢复，则有些 wal log 已经无法进行复制，（如果有archive 或许还能救一命），则只能重做。另外也与checkpoint 以及max_wal_size 设置的大小有关。
如果执行PG_REWIND 失败，是应该重做复制关系的。