PostgreSQL timeline

磨礪技術珠磯，踐行數據之道，追求卓越價值

回到上一級頁面： PostgreSQL基礎知識與基本操做索引頁     回到頂級頁面：PostgreSQL索引頁

關於timeline，有以下的說法

http://www.postgresql.org/docs/current/static/continuous-archiving.html

24.3.5. Timelines

The ability to restore the database to a previous point in time creates some complexities that are akin to science-fiction stories about time travel and parallel universes. For example, in the original history of the database, suppose you dropped a critical table at 5:15PM on Tuesday evening, but didn't realize your mistake until Wednesday noon. Unfazed, you get out your backup, restore to the point-in-time 5:14PM Tuesday evening, and are up and running. In this history of the database universe, you never dropped the table. But suppose you later realize this wasn't such a great idea, and would like to return to sometime Wednesday morning in the original history. You won't be able to if, while your database was up-and-running, it overwrote some of the WAL segment files that led up to the time you now wish you could get back to. Thus, to avoid this, you need to distinguish the series of WAL records generated after you've done a point-in-time recovery from those that were generated in the original database history.

To deal with this problem, PostgreSQL has a notion of timelines. Whenever an archive recovery completes, a new timeline is created to identify the series of WAL records generated after that recovery. The timeline ID number is part of WAL segment file names so a new timeline does not overwrite the WAL data generated by previous timelines. It is in fact possible to archive many different timelines. While that might seem like a useless feature, it's often a lifesaver. Consider the situation where you aren't quite sure what point-in-time to recover to, and so have to do several point-in-time recoveries by trial and error until you find the best place to branch off from the old history. Without timelines this process would soon generate an unmanageable mess. With timelines, you can recover to any prior state, including states in timeline branches that you abandoned earlier.

Every time a new timeline is created, PostgreSQL creates a "timeline history" file that shows which timeline it branched off from and when. These history files are necessary to allow the system to pick the right WAL segment files when recovering from an archive that contains multiple timelines. Therefore, they are archived into the WAL archive area just like WAL segment files. The history files are just small text files, so it's cheap and appropriate to keep them around indefinitely (unlike the segment files which are large). You can, if you like, add comments to a history file to record your own notes about how and why this particular timeline was created. Such comments will be especially valuable when you have a thicket of different timelines as a result of experimentation.

The default behavior of recovery is to recover along the same timeline that was current when the base backup was taken. If you wish to recover into some child timeline (that is, you want to return to some state that was itself generated after a recovery attempt), you need to specify the target timeline ID in recovery.conf. You cannot recover into timelines that branched off earlier than the base backup.

通過個人實驗，發現是這樣的，一旦開始第一次的restore，那麼就產生了一個交叉點，因而"平行宇宙"誕生了。可是還有一個問題：

參見下圖：

若是我當初在A點與B點之間插入數據，又在B點和C點之間插入數據。

而後，在B點所在的時間點處Restore，那麼，Timeline2就產生了。

我能夠接着在B點和D點至今插入數據，又在D點和E點之間插入數據。

能夠說A到B是 timeline2， B到D到E是timeline1。

到達了D點或E點後，我是沒法再次Restore到 B點和C點之間了。

這是由於：

B點到C點已經成爲不存在了。

（雖然全部的archive wal log我都有，可是某些數據是保留在online wal log中，這部分的數據變化，通過timeline2的處理後，實際上是永遠失去了）

回到上一級頁面： PostgreSQL基礎知識與基本操做索引頁     回到頂級頁面：PostgreSQL索引頁

磨礪技術珠磯，踐行數據之道，追求卓越價值