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.
On 8/3/16 3:51 PM, Kevin Grittner wrote:
Personally, I can't imagine running logical replication of
supposedly matching sets of data without something equivalent.
I think it depends heavily on the replication solution. I ran londiste
for 6+ years with no major issues, but of course there was at least one
other major company running that. I also took the time to completely
read all the source code; something that's a reasonable prospect with a
few thousand lines of python. For streaming rep it's difficult just to
draw the line at where the code is.
Ultimately, people really need to understand the trade-offs to the
different solutions so they can make an informed decision on which ones
(yes, plural) they want to use. The same can be said about pg_upgrade vs
something else, and the different ways of doing backups.
Something I think a lot of folks fail to understand is the value of
having a system that has simple technology in the mix. Keeping something
like londiste running has a non-zero cost, but the day you discover
corruption has replicated through your entire infrastructure you'll
probably be REALLY happy you have it. Similarly, I always encourage
people to run a weekly or monthly pg_dump if it's at all feasible...
just to be safe.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
