I probably should have said WAL archiving, but this is the act of sending the WAL segments to a standby server. Technically, using synchronous streaming setup, this is not really required, but it's still a good insurance policy, especially if for whatever reason, the standby loses its connection to the primary. Also, synchronous streaming replication uses a walreceiver process to send transactions, one at a time, to the standby servers. This is not the act of shipping a WAL segment to that standby, but if you're still sending them to that standby, then when connectivity is restored, the standby can effectively catch back up to the primary. This is one of the major improvements in V9.4.x where the primary keeps track of the segments and you no longer have to guess how many to keep on your primary in the event of connectivity loss. In 9.3.x and below, you had tell PostgreSQL how long to hang onto WAL segments and guess correctly that this would be longer than any outage.
On 4/8/2015 11:35 AM, Wei Shan wrote:
Hi Jay,
I totally agree with you that having a pair hot standbys will be good. What do you mean by "using WAL shipping in addition to WAL receivers"?According to the documentation, if I configure replication slot, "the master does not remove WAL segments until they have been received by all standbys". In sync replication, if the standby is down, the transaction will not be able to commit. However, if we have a pair, as long as 1 of the hot standby is up, the transaction will still go through.
Hi Jan,
Technically, 2 instance of pg-pool will suffice. However, if we have to bring 1 instance down for maintenance, there's no standby if the master crashes.
Anyway, I do realise a tiny flaw in my design, pg-pool is not a active/active design. It means there's a wasted resource. At least my pair of hot standbys could serve read queries..