Re: replication consistency checking - Mailing list pgsql-admin

From hydra
Subject Re: replication consistency checking
Date
Msg-id CAG6MAzTPE+ZgFnyYuzZcYKxju2dRyMGRTb9v=mdRZs4kSTyRZQ@mail.gmail.com
Whole thread Raw
In response to Re: replication consistency checking  (Jan Lentfer <Jan.Lentfer@web.de>)
Responses Re: replication consistency checking  (jaime soler <jaime.soler@gmail.com>)
List pgsql-admin


On Tue, Jun 9, 2015 at 9:47 PM, Jan Lentfer <Jan.Lentfer@web.de> wrote:




> Am 05.06.2015 um 16:56 schrieb Scott Ribe <scott_ribe@elevated-dev.com>:
>
>> On Jun 5, 2015, at 8:42 AM, Igor Neyman <ineyman@perceptron.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.


Ok but we do restart our slaves from time to time (upgrades) so sooner or later you would discover if that would be the problem. But maybe it will discover bugs/problems that occur *during* replication.
 

> 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

pgsql-admin by date:

Previous
From: hydra
Date:
Subject: Re: replication consistency checking
Next
From: hydra
Date:
Subject: Re: replication consistency checking