El jue, 11-06-2015 a las 07:14 +0200, hydra escribió: > > > 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. Are you or your company considering to fund "this tool"?, if yes, maybe you get some feedback at pgsql-hackers@xxxxxxxxxxxxxx > > > > > 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 > > -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
