Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2Ikw-0008Mm-5F for pgsql-admin@arkaria.postgresql.org; Fri, 08 Mar 2019 16:53:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h2Iku-00031O-VF for pgsql-admin@arkaria.postgresql.org; Fri, 08 Mar 2019 16:53:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2Ij3-00055R-VS for pgsql-admin@lists.postgresql.org; Fri, 08 Mar 2019 16:52:02 +0000 Received: from smtp5-g21.free.fr ([212.27.42.5]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2Ij0-0007sa-VC for pgsql-admin@lists.postgresql.org; Fri, 08 Mar 2019 16:52:00 +0000 Received: from firost (unknown [92.88.251.125]) (Authenticated sender: ioguix) by smtp5-g21.free.fr (Postfix) with ESMTPSA id 964345FFA5; Fri, 8 Mar 2019 17:51:50 +0100 (CET) Date: Fri, 8 Mar 2019 17:51:49 +0100 From: "Jehan-Guillaume (ioguix) de Rorthais" To: M Jane Cc: Shreeyansh Dba , Pgsql-admin Subject: Re: Postgresql 9.6.12 switchover failing Message-ID: <20190308175149.02edbcc0@firost> In-Reply-To: References: X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, 8 Mar 2019 22:10:15 +0530 Shreeyansh Dba wrote: > Hi Marian, > > Yes, We have faced the same issue, generally, this type of issue occurs due > to missing of history file i.e(00000000.history) during the replication > setup using the pg_basebackup. > > To resolve this type issue you need to create an empty history file with > name 00000000.history on the master server then rebuild old master by > initiating the pg_basebackup. Uh, what? Do you have further info about this? I fail to understand how this is related to OP question... > On Fri, Mar 8, 2019 at 8:11 PM M Jane wrote: ... > > But bringing up the old primary as a slave doesn't work. I get errors ( > > like >FATAL: requested timeline 5 is not a child of this server's history) > > and the instances shuts down automatically. While doing a clean switchover, I never seen this (yet). How are you checking both servers are up-to-date? Do you check that the standby received everything from the old primary, including its shutdown checkpoint, before promoting? Make sure your standby staid connected to your old primary until the later is completely shutdown-ed. Nothing should disconnect them during the whole process. And make sure to use mode fast or smart to stop the old primary. Are you able to share with us the restart checkpoint on the old primary and the history file created by the new-primary? How far are the restart LSN and timeline fork from each other? Regards,