From: | hydra <hydrapolic(at)gmail(dot)com> |
---|---|
To: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: replication consistency checking |
Date: | 2015-06-11 05:14:33 |
Message-ID: | CAG6MAzTPE+ZgFnyYuzZcYKxju2dRyMGRTb9v=mdRZs4kSTyRZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, Jun 9, 2015 at 9:47 PM, Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de> wrote:
>
>
>
>
> > 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.
>
>
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
From | Date | Subject | |
---|---|---|---|
Next Message | hydra | 2015-06-11 05:16:14 | Re: replication consistency checking |
Previous Message | hydra | 2015-06-11 05:12:36 | Re: replication consistency checking |