pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jerry Sievers <gsievers19@comcast.net>
To: bricklen <bricklen@gmail.com>
Cc: Hammerman\, Joseph <JosephHammerman@iheartmedia.com>
Cc: pgsql-admin\@postgresql.org <pgsql-admin@postgresql.org>
Subject: Re: Failover with a tertiary read-only secondary
Date: Fri, 31 Mar 2017 17:45:58 -0500
Message-ID: <86y3vlqd3t.fsf@jerry.enova.com> (raw)
In-Reply-To: <CAGrpgQ8chc67K0M+XYRfAAjyHcRp5tEjHd-FYOh4o+E4zLBM9w@mail.gmail.com>
References: <D503FB0C.6C95%JosephHammerman@iheartmedia.com>
	<CAGrpgQ8cbQJc3iFq2KQ2dA5O76-r3t_EB1MiApY2oNRt6UYnRg@mail.gmail.com>
	<D5041934.6CA6%JosephHammerman@iheartmedia.com>
	<CAGrpgQ8chc67K0M+XYRfAAjyHcRp5tEjHd-FYOh4o+E4zLBM9w@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>

bricklen <bricklen@gmail.com> writes:

> On Fri, Mar 31, 2017 at 11:35 AM, Hammerman, Joseph <JosephHammerman@iheartmedia.com> wrote:
>
>      1. Not a bad idea, but that only delays the necessity of a resync until the next failover…. Unless I’m missing something?
>
> I've used cascading replication extensively over the past few years and rarely had to resync a downstream replica. The several thousand Postgres clusters I'm
> administering now are almost exclusively set up with the primary replica streaming from the master and the master shipping WALs to the secondary replica in DR data
> centre, so I can't test any cascading replication promotions at the moment. My suggestion is to test your replication setup in a cascade and see what happens, I don't
> expect you'll need to resync. If you do, report back with how you've set up your replication settings.

Repointing tertiary standbys to a promoted peer should not be difficult
if same tertiary standby was at or trailing the log position when new
master promoted... and recovery.conf has recovery_target_timeline=latest.

Also, the new promoted master needs to have been already configured to
archive and wal_level set not minimal on promotion.

In other words, there shall be no break in the WAL stream in regards to
adequate wal level which depends on the tertiary standby's needs.

HTH

>

-- 
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



view thread (5+ messages)

Message-ID: <86y3vlqd3t.fsf@jerry.enova.com>
Permalink:  ../86y3vlqd3t.fsf@jerry.enova.com/
Also on:    postgresql.org/message-id/86y3vlqd3t.fsf@jerry.enova.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: gsievers19@comcast.net, bricklen@gmail.com, JosephHammerman@iheartmedia.com
  Subject: Re: Failover with a tertiary read-only secondary
  In-Reply-To: <86y3vlqd3t.fsf@jerry.enova.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox