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@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.
Are you or your company considering to fund "this tool"?, if yes, maybe
you get some feedback at pgsql-hackers@postgresql.org
>
>
>
> > 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
>
>
