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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
