Re: Why we lost Uber as a user

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Why we lost Uber as a user
Дата
Msg-id CANP8+jKy2EX=eS1_3gMPD4A0cK3WOqwLfMW7-Y1ys9uce_W5sw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why we lost Uber as a user  (Greg Stark <stark@mit.edu>)
Ответы Re: Why we lost Uber as a user  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 17 August 2016 at 12:19, Greg Stark <stark@mit.edu> wrote:
> On Wed, Aug 17, 2016 at 1:36 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Something I didn't see mentioned that I think is a critical point: last I
>> looked, HOT standby (and presumably SR) replays full page writes. That means
>> that *any* kind of corruption on the master is *guaranteed* to replicate to
>> the slave the next time that block is touched. That's completely the
>> opposite of trigger-based replication.
>
> Yes, this is exactly what it should be doing and exactly why it's
> useful. Physical replication accurately replicates the data from the
> master including "corruption" whereas a logical replication system
> will not, causing divergence and possible issues during a failover.

Yay! Completely agree.

Physical replication, as used by DRBD and all other block-level HA
solutions, and also used by other databases, such as Oracle.

Corruption on the master would often cause errors that would prevent
writes and therefore those changes wouldn't even be made, let alone be
replicated.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Use pread and pwrite instead of lseek + write and read
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bug in intarray bench script