Everyone probably already noticed that in PostgreSQL 8.4 a
new database
mode appeared:
Warm standby . When it is running, the Write-Ahead database logs (WAL) are translated to a slave database, which are used in real-time as if it happened on the main system. Therefore, if the main database for some reason (lightning / tornado / third world war / other natural disasters) fails, you can instantly switch to a subordinate database (the data in which will be quite relevant compared to the main database) and use it further.
But, unfortunately, the “warm standby” implies that the database recovery process is continuously going on on the slave system; from which it follows that while the main base is alive, a subordinate base cannot be used.
If you read at least the
depesz blog (not to mention commit logs), then you already know where I am going; if not, then ... On December 19th of last year,
Hot standby functionality was added to the development version of PostgreSQL 8.5. Now, when setting up WAL replication, the slave database can also be used for SELECT queries (and only SELECT, for obvious reasons). If earlier the second server with the second database was idle waiting for force majeure, and the admin had to blush to the managers when it came to questions about the efficiency of using the equipment - now this server, with the correct construction of application logic, will help unload the main database.
Details on the operation of Hot standby can be found in the
relevant article from the documentation of the PostgreSQL version being developed.