Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZ8T-0005Ph-Ed for pgsql-admin@arkaria.postgresql.org; Tue, 07 Oct 2014 18:05:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XbZ8S-0000RW-TN for pgsql-admin@arkaria.postgresql.org; Tue, 07 Oct 2014 18:05:20 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XbZ8R-0000OE-IV for pgsql-admin@postgresql.org; Tue, 07 Oct 2014 18:05:19 +0000 Received: from resqmta-ch2-05v.sys.comcast.net ([2001:558:fe21:29:69:252:207:37]) by makus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XbZ8K-0007yD-1r for pgsql-admin@postgresql.org; Tue, 07 Oct 2014 18:05:17 +0000 Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-05v.sys.comcast.net with comcast id 0J3Y1p0042XD5SV01J5B4a; Tue, 07 Oct 2014 18:05:11 +0000 Received: from jerry.enova.com ([38.98.177.132]) by resomta-ch2-20v.sys.comcast.net with comcast id 0J4x1p00d2rmZlA01J51BY; Tue, 07 Oct 2014 18:05:08 +0000 Received: by jerry.enova.com (Postfix, from userid 1001) id 3C64C7401ED; Tue, 7 Oct 2014 13:04:57 -0500 (CDT) From: Jerry Sievers To: John Scalia Cc: "pgsql-admin\@postgresql.org" Subject: Re: Error messages in a hot standby server's logfiles In-Reply-To: <5434239E.50508@gmail.com> (John Scalia's message of "Tue, 07 Oct 2014 13:32:14 -0400") Date: Tue, 07 Oct 2014 12:56:14 -0500 Lines: 47 References: <5434239E.50508@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Message-ID: <8638azzrg6.fsf@jerry.enova.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412705111; bh=v5/I2CtLln4u2J+EACmhmAfYkKm0td2nGqYo7Cb1Euc=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=RPSfCkUs1kpXILKmQ7fERoqzfl4cykxT7XxVG5RD1g336iGUFxJEhv8NJh3F7x1Xf 1nGILQng7P9Hd1Rwp9acT2KtKv5HSQIPIALlpaSanfmSIqC94JzZsdEVpgCN8wwnwR 8hNI2AeB9P3NRRdtWYljRPvqjYWHjMTJXRsWUOQwuQysf09iKsemAKkU49IdgNWRie 5GtwocYYDTl249O1Lv1lZNRPXJQRYA2C4mRRAsV6Uflddjl8J6Z3TKx2P+aCqoV4pi 9+MtIP1XWBEaSaDMdjInSP5g6navar0b3QnzR5Lrz8xrFaqPAiE6hVBlFGomRbWCl0 LviADOI6xOHyw== X-Pg-Spam-Score: -1.0 (-) 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 Sorry, meant 'restore_command' not archive_command. See below... John Scalia writes: > Hi all, > > My setup is: postgresql V9.3.3 running on a CentOS 6.5 (kernel > 2.6.32-358.18.1.el6.x86_64) and I have 3 servers, one primary and two > hot standbys. In our failover and loss of communications testing, I > have seen a couple of issues that I'm hard to explain. For instance, > we took one hot standby out of service by shutting down postgresql on > it. Now, we're hot standby with log shipping as an insurance policy, > so the WAL segments continued to be copied onto that out of service > standby for a few minutes. On restart, I see: > > cp: cannot stat '/mnt/wallogs/archive/0000000C.history': No such file or directory > cp: cannot stat '/mnt/wallogs/archive/0000000B0000001900000077': No such file or directory > > Later in the logfile, I see another failure for 000000B.history. These .history files may or may not exist depending on whether timeline branching has been done. The only way Pg knows how to check for them is invoking archive_command which is your case is cp and thus the message. HTH > > In looking at the /mnt/wallogs/archive directory, those files aren't > there, but as the primary never had an issue and continued to copy WAL > segments to this directory, why was the standby looking for them? What > triggered this? Also, in that directory, I often see files generated > by the pg_basebackup command used to build the standby, files like > "0000000B0000001900000000.00000028.backup" or generally files ending > with .backup in their names. These never get removed automatically by > the standby server. We have to manually remove them. So, I'm guessing > they weren't necessary, so why did the primary copy them here using > its archive_command? Why aren't they removed by some mechanism on the > standby? > > -- > Jay -- 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