Re: replication consistency checking

Поиск
Список
Период
Сортировка
От hydra
Тема Re: replication consistency checking
Дата
Msg-id CAG6MAzTPE+ZgFnyYuzZcYKxju2dRyMGRTb9v=mdRZs4kSTyRZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: replication consistency checking  (Jan Lentfer <Jan.Lentfer@web.de>)
Ответы Re: replication consistency checking  (jaime soler <jaime.soler@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: hydra
Дата:
Сообщение: Re: replication consistency checking
Следующее
От: hydra
Дата:
Сообщение: Re: replication consistency checking