PostgreSQL WAL LOG 与时间线timeline 与rejoin node 错误

问题的起因是，在做repmgr 恢复的时候，经常有同学说恢复的时候， repmgr rejion node 的时候pg_rewind 会报错，与时间线有关。（pg_rewind之前是写过的清参阅之前的文字）

正文———————————————————————————————

PostgreSQL 中的wal log 对于数据库是很重要的，基本wal log 解决的问题就是在数据写入到数据库的时候并没有必要非要立即写入到存储系统，通过wal log 及时记录 postgresql 中所作的事情，在出现数据库问题的时候，通过wal log 就可以将数据进行恢复。所以wal log 出现最主要的原因，（个人认为），保证数据安全性下的最大化数据库的性能。磁盘的顺序写的性能是一定比随即写要好的根本决定了上面的数据库建立的构思。

使用WAL可以显著减少磁盘写操作的数量，因为只需要将日志文件刷新到磁盘，以确保提交了事务，而不是事务更改的每个数据文件。日志文件是按顺序写入的，因此同步日志的成本远远低于刷新数据页的成本。对于处理许多涉及数据存储的不同部分的小事务的服务器来说尤其如此。

那时间线是什么，我们来一个直观的东西，打开pg_wal (pg11版本)，可以看到下图。

每次创建一个新的时间轴，PostgreSQL都会创建一个名为“.history”的“时间轴历史”文件。时间轴历史文件由原始时间轴历史文件中的内容和当前时间轴的切换记录组成。假设已启动恢复的数据库并切换到新的时间轴ID=5。然后将时间轴历史文件命名为00000005.history。该文件记录了文件分支的原因、时间轴和时间。该文件可能包含多行记录。

通过上面的时间轴的history 可以看到每个新的history文件随着数字的叠加，历史记录也是在一致添加的。

当数据库从包含多个时间轴的归档中恢复时，历史文件允许系统选择正确的WAL文件。历史文件也可以像WAL文件一样归档到WAL归档目录。历史文件是非常小的文本文件，因此需要很少的存储空间。如果希望通过在恢复中指定目标时间轴tli来恢复数据库。如果希望通过在恢复中指定目标时间轴tli来恢复数据库。conf中，程序首先查找.history文件，然后根据.history文件中记录的时间轴分支之间的关系，查找pg_control中从startTLI到tli的所有时间轴对应的日志文件，并恢复数据库。

而上面提到的问题，无法进行的原因有因为没有配备 PG_REWIND必要的使用的环境，例如打开 full page wal log hit 等等 如果使用repmgr 则必须要共享加载中也要配置repmgr 。而这些工作没有做，造成了使用 rejoin 时的错误。

另外一个问题我们是不是要使用PG_REWIND 来作为rejoin的一个选项，官方的文档上给出的命令是这样的。我想下面这句话可以来解释

当从级提升到新主级时，它会创建一个新的时间轴，以避免WAL名称重叠。history文件包含关于数据库时间轴分支的信息。恢复过程使用这些信息来确定它正在处理的时间轴。

所以使用pg_rewind 的原因也是要通过文件级别的方式来拷贝数据到原来的主，现在的从，来使数据一致，所以建议要使用PG_REWIND, 而使用PG_REWIND 则必须要进行 POSTGRESQL 安装时的一系列的设置，这都是一环套一环的。

所以学习PG 时间越长，使用的功能越多，个人发现PG的安装的确是一个需要做好的基础工作，相对其他的数据库的安装的难度，（SQL SERVER ,ORACLE ,MYSQL） 可以说是要求高的。能用，和 滴水不漏的用，是不同的，谁让POSTGRESQL 的功能太多。