为了理解引入时间线的背景，我们来分析一下，如果没有时间线，会有什么问题？先举个将数据库恢复到以前时间点的例子。假设在一个数据库的运行过程中，DBA在周三12:00AM删掉了一个关键的表，但是直到周五中午才发现这个问题。这个时候DBA拿出最初的数据库备份，加上存在归档目录的日志文件，将数据库恢复到周三11:00AM的时间点，这样就能正常启动和运行。但是，DBA后来意识到这样恢复是不对的，想恢复到周四8:00AM的数据，这时会发现无法做到：因为在数据库不断运行中，会产生与旧的WAL文件重名的文件，这些文件进入归档目录时，会覆盖原来的旧日志，导致恢复数据库需要的WAL文件丢失。为了避免这种情况，需要区分原始数据库历史生成的WAL文件和完成恢复之后继续运行产生的（重名的）新WAL文件。整个过程如图1所示：

为了解决这个问题，PostgreSQL引入了时间线的概念。每当归档文件恢复完成后，创建一个新的时间线用来区别新生成的WAL记录。WAL文件名由时间线和日志序号组成，源码实现如下：

例如：

  2. 00000003.history
  4. 00000003000000000000001B

有时间线数据库恢复

新的时间线会在什么情况下出现呢？

  1. 即时恢复(PITR) 配置recovery.conf文件：

    设置好recovery.conf文件后，启动数据库，将会产生新的timeline，而且会生成一个新的history文件。恢复的默认行为是沿着与当前基本备份相同的时间线恢复。如果你想恢复到某些时间线，你需要指定的recovery.conf目标时间线recovery_target_timeline，不能恢复到早于基本备份分支的时间点。

每次创建一个新的时间线，PostgreSQL都会创建一个“时间线历史”文件，文件名类似.history，它里面的内容是由原时间线history文件的内容再追加一条当前时间线切换记录。假设数据库恢复启动后，切换到新的时间线ID＝5，那么文件名就是00000005.history ，该文件记录了自己从什么时间哪个时间线什么原因分出来的，该文件可能含有多行记录，每个记录的内容格式如下：

例如：

  1. $ cat 00000004.history
  2. 1    0/140000C8    no recovery target specified

当数据库在从包含多个时间线的归档中恢复时，这些history文件允许系统选取正确的WAL文件，当然，它也能像WAL文件一样被归档到WAL归档目录里。历史文件只是很小的文本文件，所以保存它们的代价很小。

PG中通过timeline机制能够方便地实现数据库恢复到任意时间点，这对我们数据库备份有重要的作用。我们可以在数据库的使用中合理地备份和归档我们的数据，一旦数据出现丢失或损坏，我们都能有条不紊的使用timeline机制恢复出来我们需要的数据。