[Pgpool-general] Replication Flawed?

[Robert Ayres]

>These results are not very surprising. Since pgpool write to master
>THEN secondary, there is a timing window between them. If you want to
>retrieve(SELECT) exactly same results anytime from those servers while
>many transactions are running currently, you need to explictly lock
>the target table.

>Same thing can be said to DELETE. DELETE needs to retrieve target rows
>before deleting.

>I don't think this restriction is applied only to pgpool.
>--
>Tatsuo Ishii
>SRA OSS, Inc. Japan


Thanks for your reply Tatsuo,

Is the replication from master to secondary not flawed simply by the fact statements between the two are not synchronised?  You could lock tables as you suggest but if the LOCK TABLE statement is not guaranteed to execute on the secondary server in the same order (of all transactions) as the first, then a different transaction could potentially commit (before LOCK TABLE) on either server which would still result in inconsistent DBs.

I have run the same tests (and passed) using a JDBC based replication system, Sequoia (sequoia.continuent.org), which ensures replication consistency by ordering statements from all transactions based on ids assigned to them AFAIK.

Without guranteed synchronisation, the replication offering becomes meaningless.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pgfoundry.org/pipermail/pgpool-general/attachments/20060517/6979ee77/attachment.html