On 01/08/2014 02:34 PM, Andres Freund wrote:
> I don't think you've understood synchronous replication. There wouldn't
> be *any* benefit to using it if it worked the way you wish since there
> wouldn't be any additional guarantees. A single reconnect of the
> streaming rep connection, without any permanent outage, would
> potentially lead to data loss if the primary crashed in the wrong
> moment.
> So you'd buy no guarantees with a noticeable loss in performance.
>
> Just use async mode if you want things work like that.
Well no. That isn't what I am saying. Consider the following scenario:
db0->db1 in synchronous mode
The idea is that we know that data on db0 is not written until we know
for a fact that db1 also has that data. That is great and a guarantee of
data integrity between the two nodes.
If we have the following:
db0->db1:down
Using the model (as I understand it) that is being discussed we have
increased our failure rate because the moment db1:down we also lose db0.
The node db0 may be up but if it isn't going to process transactions it
is useless. I can tell you that I have exactly 0 customers that would
want that model because a single node failure would cause a double node
failure.
All the other stuff with wal_keep_segments is just idea throwing. I
don't care about that at this point. What I care about specifically is
that a single node failure regardless of replication mode should not be
able to (automatically) stop the operation of the master node.
Sincerely,
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
"In a time of universal deceit - telling the truth is a revolutionary
act.", George Orwell
