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
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 |