Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cu5JK-0003F1-F1 for pgsql-admin@arkaria.postgresql.org; Fri, 31 Mar 2017 22:46:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cu5JK-0003XU-1c for pgsql-admin@arkaria.postgresql.org; Fri, 31 Mar 2017 22:46:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cu5JI-0003WW-R2 for pgsql-admin@postgresql.org; Fri, 31 Mar 2017 22:46:25 +0000 Received: from resqmta-ch2-07v.sys.comcast.net ([2001:558:fe21:29:69:252:207:39]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cu5JD-0001KL-Vo for pgsql-admin@postgresql.org; Fri, 31 Mar 2017 22:46:24 +0000 Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-07v.sys.comcast.net with SMTP id u5J2c8p7kU9z5u5J5cAzOc; Fri, 31 Mar 2017 22:46:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1491000371; bh=eYJQHJQBvnp0mAOzr5buNGkrttqN1NRx2zZNYaP9pz0=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=InKlWWvlzYNn9GeJGkM7PiO6EQfGXU10q+I5JenQBQbtofb04zcpmqCGrsQZTpSF0 OtqzvKK3IR2BMCaSJPGVYhHE/kWsBSWQanh0/I+pVy5FXpBJNTwZf6F5bULQsrH6kF kbDS2wvbb7StbszSBB8Ifln5Bkqh7YMiRrGBM9A+m5OFnUOW5tCAaHr49BIChHQ7Km zAc4zHcHYBipGaR1A/mFEJeML/yTGht3Eg6AsKe0bsyeBwX6P3fKkyQ2tHknv9tWaf wtFsmjsyxZC1TlkG5HaORC7fSIKDk9RvXWKrUMWIB7t8l0luXetAyzGs3uYXz/a5eN mCWC7/T3tkQCQ== Received: from jerry.enova.com ([12.187.116.132]) by resomta-ch2-10v.sys.comcast.net with SMTP id u5IscgXVkX2Fju5IvcqINN; Fri, 31 Mar 2017 22:46:09 +0000 Received: by jerry.enova.com (Postfix, from userid 1001) id 6783F7401EB; Fri, 31 Mar 2017 17:45:58 -0500 (CDT) From: Jerry Sievers To: bricklen Cc: "Hammerman\, Joseph" , "pgsql-admin\@postgresql.org" Subject: Re: Failover with a tertiary read-only secondary References: Date: Fri, 31 Mar 2017 17:45:58 -0500 In-Reply-To: (bricklen@gmail.com's message of "Fri, 31 Mar 2017 11:40:12 -0700") Message-ID: <86y3vlqd3t.fsf@jerry.enova.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfO4nAp5hv02oiwwlmpPQcvsS+ZUOArj3UG+4oxZbhosQnwb3T5UxXCULx34RciVa5pfeo7RgJf0o4UNWNj+FQhfO8m1cjpOYDcMDiPrlkwG888Qea3N7 QS5jzJ9dXwyFMuDsv0VtHP4g5TFlWAHKjuJInpwzuoLwOJ7yR3b/D/6nxv84MY7TqpPBYgbhPYhUAqKs4NdkxzjDx0yKiNP0U2LO8QJ0mGF46rtgYvfiaTzb UjoWNaG/Lou66H6E7n1BW2zlRbrEi5zpHr1TDkC/RlE= X-Pg-Spam-Score: -1.5 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org bricklen writes: > On Fri, Mar 31, 2017 at 11:35 AM, Hammerman, Joseph 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