Re: Why we lost Uber as a user

Поиск
Список
Период
Сортировка
От Vitaly Burovoy
Тема Re: Why we lost Uber as a user
Дата
Msg-id CAKOSWN=8Vi=+hHjHh7MAVtw8ZudfANCPYq+2HnFGzosHKauTnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why we lost Uber as a user  (Geoff Winkless <pgsqladmin@geoff.dj>)
Ответы Re: Why we lost Uber as a user  (Geoff Winkless <pgsqladmin@geoff.dj>)
Список pgsql-hackers
On 7/28/16, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> On 27 July 2016 at 17:04, Bruce Momjian <bruce@momjian.us> wrote:
>
>> Well, their big complaint about binary replication is that a bug can
>> spread from a master to all slaves, which doesn't happen with statement
>> level replication.
>
> ​
> I'm not sure that that makes sense to me. If there's a database bug that
> occurs when you run a statement on the master, it seems there's a decent
> chance that that same bug is going to occur when you run the same statement
> on the slave.
>
> Obviously it depends on the type of bug and how identical the slave is, but
> statement-level replication certainly doesn't preclude such a bug from
> propagating.
>
> ​Geoff

Please, read the article first! The bug is about wrong visibility of
tuples after applying WAL at slaves.
For example, you can see two different records selecting from a table
by a primary key (moreover, their PKs are the same, but other columns
differ).

From the article (emphasizing is mine):
The following query illustrates how this bug would affect our users
table example:
SELECT * FROM users WHERE id = 4;
This query would return *TWO* records: ...


And it affected slaves, not master.
Slaves are for decreasing loading to master, if you run all queries
(even) RO at master, why would you (or someone) have so many slaves?

--
Best regards,
Vitaly Burovoy



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Geoff Winkless
Дата:
Сообщение: Re: Why we lost Uber as a user
Следующее
От: Geoff Winkless
Дата:
Сообщение: Re: Why we lost Uber as a user