Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eg0Ej-00067l-FL for pgsql-admin@arkaria.postgresql.org; Mon, 29 Jan 2018 03:36:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eg0Eh-0002TL-WE for pgsql-admin@arkaria.postgresql.org; Mon, 29 Jan 2018 03:36:00 +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 1eg0Eh-0002TB-PO for pgsql-admin@lists.postgresql.org; Mon, 29 Jan 2018 03:35:59 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eg0EZ-00069p-Ia for pgsql-admin@postgresql.org; Mon, 29 Jan 2018 03:35:59 +0000 Received: from bruce by momjian.us with local (Exim 4.84_2) (envelope-from ) id 1eg0EX-0002bL-No; Sun, 28 Jan 2018 22:35:49 -0500 Date: Sun, 28 Jan 2018 22:35:49 -0500 From: Bruce Momjian To: Ray Stell Cc: "pgsql-admin@postgresql.org" Subject: Re: [ADMIN] standby upgrade questions Message-ID: <20180129033549.GB11620@momjian.us> References: <700537e7-9039-0bbd-61fb-b28af635121e@vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <700537e7-9039-0bbd-61fb-b28af635121e@vt.edu> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Oct 17, 2017 at 11:34:51AM -0400, Ray Stell wrote: > From:   https://www.postgresql.org/docs/9.6/static/pgupgrade.html Sorry for the late reply. > Q1 - Is there a procedure to force this "catch up?"   I suppose preventing db > activity with a pg_hba hack and running "select pg_switch_xlog()."   Maybe > there's a better way? Uh, if there was a better way than pg_hba.conf, we would document it. Do you have any ideas? > 1. Prepare for standby server upgrades > > If you are upgrading standby servers (as outlined in section step 10), > verify that the old standby servers are caught up by running pg_controldata >  against the old primary and standby clusters. Verify that the "Latest > checkpoint location" values match in all clusters. (There will be a > mismatch if old standby servers were shut down before the old primary.) > > Also, if upgrading standby servers, change wal_level to replica in the  > postgresql.conf file on the new master cluster. > > > Q2 - I was wondering what the end result is, in general, of this rsync of old > and new?  If the old db files and upgraded, new db files are meshed what do you > get on the other side of the rsync?  Again, I mean in general what is the goal? I added more detail on what happens with rsync in this commit: commit 2d4a614e1ec34a746aca43d6a02aa3344dcf5fd4 Author: Bruce Momjian Date: Tue Sep 12 13:17:52 2017 -0400 docs: improve pg_upgrade rsync instructions This explains how rsync accomplishes updating standby servers and clarifies the instructions. Reported-by: Andreas Joseph Krogh Discussion: https://postgr.es/m/VisenaEmail.10.2b4049e43870bd16.15d898d696f@tc7-visena Backpatch-through: 9.5 The new text is: https://www.postgresql.org/docs/10/static/pgupgrade.html What this does is to record the links created by pg_upgrade's link mode that connect files in the old and new clusters on the primary server. It then finds matching files in the standby's old cluster and creates links for them in the standby's new cluster. Files that were not linked on the primary are copied from the primary to the standby. (They are usually small.) This provides rapid standby upgrades. Unfortunately, rsync needlessly copies files associated with temporary and unlogged tables because these files don't normally exist on standby servers. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +