Re: Why we lost Uber as a user - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Why we lost Uber as a user
Date
Msg-id CANP8+jKy2EX=eS1_3gMPD4A0cK3WOqwLfMW7-Y1ys9uce_W5sw@mail.gmail.com
Whole thread Raw
In response to Re: Why we lost Uber as a user  (Greg Stark <stark@mit.edu>)
Responses Re: Why we lost Uber as a user  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Use pread and pwrite instead of lseek + write and read
Next
From: Tom Lane
Date:
Subject: Re: Bug in intarray bench script