Temporary and historical postgresql 9.1 files

Can someone explain to me the purpose of temporary and historical files and the setting of 'recovery_target_timeline' in the recovery.conf file.

The vague understanding I got from postgresql 9.1 documentation is that when a subordinate completes the recovery, it switches to a new timeline to prevent the WAL from overwriting the previous timeline. I do not understand how this is used in the recovery script, but also for the purpose of the .history file and the "recovery_target_timeline" parameter for the "last".

I am trying to understand what happens when I promote a slave to become a new master. It restores and launches a new timeline before accepting read / write requests.

Now, if I set up a new slave, since I advanced the existing slave to the master, he needs / to use the history file generated by the previous slave (new master) to read the new ones created by WAL (new master) for continuous archiving / recording of logs.

Many thanks.

+4
source share
1 answer

To understand the timing, you must understand that they should avoid problems with MVCC and diverging time frames. A good way to think about this is in the context of replication. In streaming Master / Slave replication, you don’t want someone to bring the slave as the master, insert a bunch of information, and then return it back to the subordinate. If you do this, the WAL segment binary logs will no longer work properly and you will get db corruption.

When you restore a subordinate new master, he completes the "restoration" and begins his own timeline. From now on, he is now the master and cannot return to being a slave without recovery. This creates some problems with failure and failure, but the way to do this is to periodically interrupt the work with the old master, restoring db (using pg_basebackup ) as a new slave. This means that each failover / failback is a new timeline.

Yes, this affects the rejection of multiple servers, since slaves must change the timing.

0
source

All Articles