On 04/08/2013 12:34 PM, Samrat Revagade wrote:
Hello,
We have been trying to figure out possible solutions to the following
problem in streaming replication Consider following scenario:
If master receives commit command, it writes and flushes commit WAL
records to the disk, It also writes and flushes data page related to
this transaction.
No data page flushing takes place. All data page writing is delayed to
bgWriter and/or checkpoints.
The master then sends WAL records to standby up to the commit WAL
record. But before sending these records if failover happens then,
old master is ahead of standby which is now the new master in terms
of DB data leading to inconsistent data .
The master sends WAL records to standby continuously, not "upon commit
wal record".
In case of syncrep the master just waits for confirmation from standby
before returning to client on commit.
One solution to avoid this situation is have the master send WAL
records to standby and wait for ACK from standby committing WAL files
to disk and only after that commit data page related to this
transaction on master.
Not just commit, you must stop any *writing* of the wal records
effectively killing any parallelism.
The main drawback would be increased wait time for the client due to
extra round trip to standby before master sends ACK to client. Are
there any other issues with this approach?
Min issue is that it will make *all* backends dependant on each sync
commit, essentially serialising all backends commits, with the
serialisation *including* the latency of roundtrip to client.
With current sync streaming the other backends can continue to write wal,
with proposed approach you can not write any records after the one
waiting an ACK from standby.
Thank you,
Samrat
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
