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

From Greg Stark
Subject Re: Why we lost Uber as a user
Date
Msg-id CAM-w4HPdBuy+D10G7bHKZ0umsHHRdrqfd+_rNDpp+-W+Ef6x-A@mail.gmail.com
Whole thread Raw
In response to Re: Why we lost Uber as a user  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Why we lost Uber as a user  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
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.

Picture yourself as Delta, you have a fire in your data centre and go
to fail over to your secondary site. Your DBAs inform you that the
secondary site has "fixed" some corruption that you were unaware of
and wasn't causing any issues and now, in the middle of the business
crisis, is when you're going to need to spend time identifying and
repairing the problem because your business logic has suddenly started
running into problems.

Physical replication tries to solve the same use cases as physical
backups. They both provide you with exactly what you had prior to the
recovery. No more or less. That's what you want when recovering from a
disaster.

-- 
greg



pgsql-hackers by date:

Previous
From: Victor Wagner
Date:
Subject: Re: Use pread and pwrite instead of lseek + write and read
Next
From: Amit Kapila
Date:
Subject: Re: [sqlsmith] Failed assertion in joinrels.c