From: | Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de> |
---|---|
To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
Cc: | Igor Neyman <ineyman(at)perceptron(dot)com>, hydra <hydrapolic(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: replication consistency checking |
Date: | 2015-06-09 19:47:57 |
Message-ID: | 191E0C02-9DE3-4B1E-AED3-16F53D19C195@web.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> Am 05.06.2015 um 16:56 schrieb Scott Ribe <scott_ribe(at)elevated-dev(dot)com>:
>
>> On Jun 5, 2015, at 8:42 AM, Igor Neyman <ineyman(at)perceptron(dot)com> wrote:
>>
>> The problem I see with “checksum utility” is that for it to work both compared servers should be “static”: not transactions while it does its job.
>
> Indeed, and that was brought up before and OP seems to be ignoring it. What magic does MySQL (supposedly) use to compare databases without interfering with updates?
>
Also, if I remember the Postgres SR bug correctly, this kind of check that Percona provides would not have helped with this kind of bug. The corruption did not occur *during* replication but only if you restarted the slave because transactions were falsely marked as commited or non-commited when the slave came up again. You might have noticed the corruption earlier, though.
> One could imagine a built-in feature in PG which depends on using MVCC and having both sides look at the same snapshot. (Which would require repeatable reads.)
I actually think this would a need thing to have (for pre-production) test environments, like alpha or beta testing.
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Lentfer | 2015-06-09 20:15:01 | Re: replication consistency checking |
Previous Message | Jan Lentfer | 2015-06-09 19:20:53 | Re: replication consistency checking |