|PostgreSQL Reference Manual - Volume 3 - Server Administration Guide|
by The PostgreSQL Global Development Group
Paperback (6"x9"), 204 pages
RRP £13.95 ($24.95)
Sales of this book support the PostgreSQL project! Get a printed copy>>>
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. In the original history of the database, perhaps you dropped a critical table at 5:15PM on Tuesday evening. 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 at all. But suppose you later realize this wasn't such a great idea after all, and would like to return to some later point in the original history. You won't be able to if, while your database was up-and-running, it overwrote some of the sequence of WAL segment files that led up to the time you now wish you could get back to. So you really want 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 these problems, PostgreSQL has a notion of timelines. Each time you recover to a point-in-time earlier than the end of the WAL sequence, a new timeline is created to identify the series of WAL records generated after that recovery. (If recovery proceeds all the way to the end of WAL, however, we do not start a new timeline: we just extend the existing one.) The timeline ID number is part of WAL segment file names, and 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 later abandoned.
Each 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 make your own notes about how and why this particular timeline came to be. 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 want 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.
|ISBN 0954612043||PostgreSQL Reference Manual - Volume 3 - Server Administration Guide||See the print edition|