Re: Standalone synchronous master

On 01/10/2014 03:38 PM, Joshua D. Drake wrote:
>
> On 01/10/2014 03:17 PM, Josh Berkus wrote:
>
>>> Any continuous replication should not be a SPOF. The current behavior
>>> guarantees that a two node sync cluster is a SPOF. The proposed behavior
>>> removes that.
>>
>> Again, if that's your goal, then use async replication.
>
> I think I have gone about this the wrong way. Async does not meet the
> technical or business requirements that I have. Sync does except that it
> increases the possibility of an outage. That is the requirement I am
> trying to address.
>
>>
>> The purpose of sync rep is to know determinatively whether or not you
>> have lost data when disaster strikes.  If knowing for certain isn't
>> important to you, then use async.
>
> PostgreSQL Sync replication increases the possibility of an outage. That
> is incorrect behavior.
>
> I want sync because on the chance that the master goes down, I have as
> much data as possible to fail over to. However, I can't use sync because
> it increases the possibility that my business will not be able to
> function on the chance that the standby goes down.
>
>>
>> What's a bad idea is adding an auto-degrade option without any tools to
>> manage and monitor it, which is what this patch does by my reading.  If
>
> This we absolutely agree on.


As I see it the state of replication in Postgres is as follows.

1) Async. Runs at the speed of the master as it does not have to wait on 
the standby to signal a successful commit. There is some degree of 
offset between master and standby(s) due to latency.

2) Sync. Runs at the speed of the standby + latency between master and 
standby. This is counter balanced by knowledge that the master and 
standby are in the same state. As Josh Berkus pointed out there is a 
loop hole in this when multiple standbys are involved.

The topic under discussion is an intermediate mode between 1 and 2. 
There seems to be a consensus that this is not unreasonable.

The issue seems to be how to achieve this with ideas falling into 
roughly two camps.

A) Change the existing sync mode to allow the master and standby fall 
out of sync should a standby fall over.

B) Create a new mode that does this without changing the existing sync mode.


My two cents would be to implement B. Sync to me is a contract that 
master and standby are in sync at any point in time. Anything else 
should be called something else. Then it is up to the documentation to 
clearly point out the benefits/pitfalls. If you want to implement 
something as important as replication without reading the docs then the 
results are on you.

>
> JD
>
>


-- 
Adrian Klaver
adrian.klaver@gmail.com