Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fUxZ9-0007Gq-Hs for pgsql-admin@arkaria.postgresql.org; Mon, 18 Jun 2018 17:03:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fUxZ7-0001KN-Jm for pgsql-admin@arkaria.postgresql.org; Mon, 18 Jun 2018 17:03:41 +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.89) (envelope-from ) id 1fUxZ7-0001KB-C9 for pgsql-admin@lists.postgresql.org; Mon, 18 Jun 2018 17:03:41 +0000 Received: from mailout.easymail.ca ([64.68.200.34]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fUxYz-00040v-Sy for pgsql-admin@lists.postgresql.org; Mon, 18 Jun 2018 17:03:40 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 1BBF12131D; Mon, 18 Jun 2018 17:03:31 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOTVfZgMZIGA; Mon, 18 Jun 2018 17:03:31 +0000 (UTC) Received: from [192.168.2.16] (unknown [8.39.228.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 6C6B720FBD; Mon, 18 Jun 2018 17:03:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Replication lag from transaction logs From: Scott Ribe In-Reply-To: Date: Mon, 18 Jun 2018 11:03:27 -0600 Cc: pgsql-admin@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <37FEEBC3-CA72-46B4-ABA3-ADDDD8FF4316@elevated-dev.com> References: <975db215-0ba1-0a36-178d-dd4078fc0d50@portavita.eu> To: Debraj Manna X-Mailer: Apple Mail (2.3445.8.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Jun 18, 2018, at 9:56 AM, Debraj Manna = wrote: >=20 > Thanks Keith this is useful. >=20 > One more query if I need to know that if a have fallen too far behind = and the WAL is not available. I guess I can do this. Let me know if my = understanding is correct. > =E2=80=A2 Run pg_controldata on the slave node which = has been down for long. > =E2=80=A2 It will output the details about the WAL along with = the WAL file name from where it will start the replication. (Field to = look for in the output=E2=80=93 'Latest checkpoint's REDO WAL file') > =E2=80=A2 Then check if the file mentioned in ` 'Latest = checkpoint's REDO WAL file' is present in master `pg_wal` directory. If = not then slave have fallen too far behind and will not be able to = recover from WAL. =20 You could also try bringing the slave back up, and monitoring the log = for the error about needed WAL file not being available--this avoids the = race condition between checking that all WAL is available and restarting = the slave. -- Scott Ribe scott_ribe@elevated-dev.com https://www.linkedin.com/in/scottribe/