From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming-only Remastering |
Date: | 2012-06-17 19:55:57 |
Message-ID: | 4FDE364D.2030403@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon,
> The "major limitation" was solved by repmgr close to 2 years ago now.
> So while you're correct that the patch to fix that assumed that
> archiving worked as well, it has been possible to operate happily
> without it.
repmgr is not able to remaster using only streaming replication. It
also requires an SSH connection, as well as a bunch of other
administative setup (and compiling from source on most platforms, a not
at all insignificant obstacle). So you haven't solved the problem,
you've just provided a somewhat less awkward packaged workaround.
It's certainly possible to devise all kinds of workarounds for the
problem; I have a few myself in Bash and Python. What I want is to stop
using workarounds.
Without the requirement for archiving, PostgreSQL binary replication is
almost ideally simple to set up and administer. Turn settings on in
server A and Server B, run pg_basebackup and you're replicating. It's
like 4 steps, all but one of which can be scripted through puppet.
However, the moment you add log-shipping to the mix things get an order
of magnitude more complicated, repmgr or not.
There's really only too things standing in the way of binary replication
being completely developer-friendly. Remastering is the big one, and
the separate recovery.conf is the small one. We can fix both.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-06-17 20:11:05 | Re: Streaming-only Remastering |
Previous Message | Jeff Janes | 2012-06-17 19:27:53 | Re: Pg default's verbosity? |