On 04.10.2010 10:03, Markus Wanner wrote:
> On 09/30/2010 04:54 PM, Yeb Havinga wrote:
>> Heikki Linnakangas wrote:
>>> You do realize that to be able to guarantee zero data loss, the master
>>> will have to stop committing new transactions if the streaming stops
>>> for any reason, like a network glitch. Maybe that's a tradeoff you
>>> want, but I'm asking because that point isn't clear to many people.
>> If there's a network glitch, it'd probably affect networked client
>> connections as well, so it would mean no extra degration of service.
>
> Agreed.
>
> I think the network glitch example is too general, it could affect any
> part of the whole network. Even just the connection between the master
> and the standby, in which case all client connections would keep up.
>
> Let's quickly think about that scenario. AFAIU in such a case, the
> standby would continue to answer read-only queries, independent of what
> the master does, right?
Right.
> Or does the standby stop processing read-only
> queries in case it looses connection to the master?
As far as the current proposals go, no.
> It seems to me the later is required, if we let the master continue to
> commit transactions. Otherwise the standby would serve stale data to its
> clients without knowing.
Yep. If you want to guarantee that a hot standby doesn't return stale
data, if the connection is lost you need to either stop processing
read-only queries in the standby, or stop processing commits in the master.
Note that this assumes that you use the 'replay' synchronization level.
In the weaker levels, read-only queries can always return stale data.
With 'replay' and hot standby combination, you'll want to set
max_standby_archive_delay to a very low value, or a read-only query can
cause master to stop processing commits (or the standby to stop
accepting new queries, if that's preferred).
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com