Monday, August 29, 2011

Postgresql - Streaming replication / Hot standby


  • Lately,I've been reading a lot about streaming replication. The concept is very straightforward and clear: one master sends WAL transactions to some slave(s) which in term receives and applies those transactions in an asynchronous fashion. With streaming replication you've got an exact backup from one postgresql cluster into an auxiliary server (no restrictions about ddl commands, large objects, etc). The difference with log shipping is that streaming replication works at WAL record level whilst log shipping sends entire WAL archives (16MB) at a time. The advantage with this approach is that in the case of failure, the stand by (slave) servers are behind just a few records (transactions), also in the documentation they explain that this kind of replication generates minimal overhead on the main (primary) server. The downside of this kind of replication is  that you don't have control over which objects are to be replicated. I need to think about situation where is behavior is unwanted, for the most part I don't really see it as an important disadvantage.


hot standby

  • The term refers to the ability of a slave node (wal receiver) to allow clients to perform read-only queries. This concept is important as the default settings of streaming replication won't allow you to  query slave servers.


No comments:

Post a Comment