Re: Synchronization levels in SR

From: Alastair Turner <bell(at)ctrlf5(dot)co(dot)za>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronization levels in SR
Date: 2010-05-26 12:37:40
Message-ID: AANLkTilhW5CON77lDmh_aQdQMB5ENFEhmLEPhhm7M-Th@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A suggestion, based on what I believe would be ideal default settings
for a fully developed SR capability. The thought being that as long as
the default behaviour was stable additional knobs could be added
across version boundaries without causing trouble.

Per slave the master needs to know:
- The identity of the slave, even if only to limit who can replicate
(this will have to be specified)
- Whether to expect an acknowledgement from the slave (as will this)
- How long to wait for the acknowledgement (this may be a default)
- What the slave is expected to do before acknowledging (I think this
should default to remote flush to disk - #3 in the mail which started
this thread - since it prevents data loss without exposing the master
to the possibility of locking delays)

Additionally the process on the master requires:
- How many acknowledgments to require before declaring success
(defaulted to the number of servers expected to acknowledge since it
will cause the fewest surprises when failing over to a replica)
- What to do if the number of acknowledgments is not received
(defaulting to abort/rollback since this is really what differentiates
synchronous from asynchronous replication - the certainty that once
data has been committed it can be recovered)

So in order to set up synchronous replication all a DBA would have to
specify is the slave server, that it is expected to send
acknowledgments and possibly a timeout.

If this is in fact a desirable state for the default behaviour or
minimum settings requirement then I would say it is also a desirable
target for the first patch.

Alastair "Bell" Turner
^F5

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-26 12:40:34 Re: Stefan's bug (was: max_standby_delay considered harmful)
Previous Message Robert Haas 2010-05-26 11:20:30 Re: mapping object names to role IDs