Re: replication consistency checking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux