On Thu, Jun 21, 2012 at 10:10 AM, David Pirotte <dpirotte@gmail.com> wrote:
>
> 2ndQuadrant's repmgr uses the second option so that the async slave can
> "follow" the new master, saving you from having to do a new base backup.
> Additionally, the old master is able to start streaming replication from the
> new master without a new base backup. (Repmgr does not actually support the
> latter behavior out of the box, but it seemed to work.)
>
is not safe to make old master to start SR from new master without any
additional action.
if the old master crashed/disconnected before some info was sent to
the slave, then the old master has info not in the slave so when it
converts in new master that piece of info is lost... if now the old
master tries to connect to the new master he will except that info to
exists...
> So, given a hard failure (i.e. power loss) of the master, `pg_ctl promote`
> provides availability more quickly, but `pg_ctl restart` provides data
> redundancy more quickly. Is this an accurate assessment of the tradeoffs
> between the two approaches?
yes, i think that's pretty much the difference
> Are there risks associated with the `pg_ctl
> restart` approach, or is it safe to use?
>
it's safe as long as you let repmgr do it ;)
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación