| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Alfred Perlstein <alfred(at)freebsd(dot)org>, Geoff Winkless <pgsqladmin(at)geoff(dot)dj>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why we lost Uber as a user |
| Date: | 2016-08-03 18:23:36 |
| Message-ID: | 2533.1470248616@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't think they are saying that logical replication is more
> reliable than physical replication, nor do I believe that to be true.
> I think they are saying that if logical corruption happens, you can
> fix it by typing SQL statements to UPDATE, INSERT, or DELETE the
> affected rows, whereas if physical corruption happens, there's no
> equally clear path to recovery.
Well, that's not an entirely unreasonable point, but I dispute the
implication that it makes recovery from corruption an easy thing to do.
How are you going to know what SQL statements to issue? If the master
database is changing 24x7, how are you going to keep up with that?
I think the realistic answer if you suffer replication-induced corruption
is usually going to be "re-clone that slave", and logical rep doesn't
really offer much gain in that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-08-03 18:42:58 | Re: Parallel tuplesort (for parallel B-Tree index creation) |
| Previous Message | Andrey Borodin | 2016-08-03 18:23:28 | Re: Optimizing numeric SUM() aggregate |