Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X6gkr-0007D9-VJ for pgsql-admin@arkaria.postgresql.org; Mon, 14 Jul 2014 13:57:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X6gkq-0000Hj-So for pgsql-admin@arkaria.postgresql.org; Mon, 14 Jul 2014 13:57: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 1X6gkp-0000Hc-Mo for pgsql-admin@postgresql.org; Mon, 14 Jul 2014 13:57:19 +0000 Received: from mail-yk0-x22d.google.com ([2607:f8b0:4002:c07::22d]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1X6gki-0001K6-9D for pgsql-admin@postgresql.org; Mon, 14 Jul 2014 13:57:17 +0000 Received: by mail-yk0-f173.google.com with SMTP id q200so1398520ykb.32 for ; Mon, 14 Jul 2014 06:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5+rBk9fXj2Ot2wM3WXdkGBi/25WvRrUypLcN9K3wTDw=; b=VOUZ248ozlD31ZKLs+G8wNN83L6pPmTs1Xt8aBVkbIY2qzpDZI1n6IyXwjO6WvuXnz BqKgnfnaqkyV/kE8GEPuGFz6KjRUsTj83yZ3Ddv2GY8o7FifdFgcL6clkXGl76UfCyeN UR8DmYuXIC5AfVXprQ+faLwaHUK8/5HOftrBXfSxe+S5Ig0cMWVZvARMAnAPaJhqDcZx 1TBYZdYdjJH7QX8CN1dmjUYFIrwrkZGy811/QVCSM9fZQLZyVMBPSPVZWb8gyhrPCiMG X+Y59xGC0S8xE9B/JsvftEM7kfuVQL+b0g9PZphWWymTx1kZTKHWngzpX3OEYUsbILWN 8Kiw== X-Received: by 10.236.53.163 with SMTP id g23mr28750282yhc.15.1405346230691; Mon, 14 Jul 2014 06:57:10 -0700 (PDT) Received: from [192.168.254.2] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id p55sm21427039yhh.34.2014.07.14.06.57.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 06:57:10 -0700 (PDT) Message-ID: <53C3E1AC.60704@gmail.com> Date: Mon, 14 Jul 2014 09:57:00 -0400 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Craig Ringer , "pgsql-admin@postgresql.org" Subject: Re: WAL segment management on a standby References: <53C015AA.5070908@gmail.com> <53C33DE8.7000902@2ndquadrant.com> In-Reply-To: <53C33DE8.7000902@2ndquadrant.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.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 Thanks Craig, I didn't know about pg_archivecleanup. (it's hard to figure out every utility when you're not given the time to thoroughly study the system.) I altered the recovery.conf per the suggestion on the documentation page for it. It does seem a little aggresive, but I'm guessing that because all the transactions have been recorded from the streaming walreceiver. If I might, I'd like to ask one final question on this matter. In looking through the standby after configuring this and restarting the system, the log file shows a few warnings. First, it whined about no history.0000004 file, which as the last WAL segment is 0000000030000000E00000004E, I'm guessing the standby thought the timeline might have been changed, but it was not. Then, it complained about no history.00000003 file in the archive area. This file had already been copied up into pg_xlog and deleted from the archive. Finally, the last complaint was that it couldn't find 0000000030000000E00000004F in the archive. It appears that under streaming a standby server will write concurrently with the primary any WAL segment the primary is still generating. I say this as that missing WAL segment ("...4F") was already in the pg_xlog directory, but it hadn't yet made it into the archive area. Eventually, 10 minutes later, 4F did appear in the archive. Is my interpretation here correct, that a standby will concurrently write a WAL segment in streaming replication mode? I just want to be able to explain this thoroughly to my QA folks. -- Jay On 7/13/2014 10:18 PM, Craig Ringer wrote: > On 07/12/2014 12:49 AM, John Scalia wrote: >> Again, thanks to all to have assisted me with getting the WAL segments >> to both my standby servers. Everything with that is now working quite >> well. I do have a related followup question, however. On these standby's >> nothing is built in to manage those WAL segments in the archive >> directory. Thus, that directory can grow to the point where it fills up >> the disk rather quickly. Any good strategies for dealing with the WAL >> segments that get put in there. Do I really need them after postgresql >> has copied them up into the pg_xlog directory? If so, how far back >> should I keep them? Yes, I know about keeping everything between >> backups. So, if my directory looks like: >> >> 00000000300000000C000000A1 >> 00000000300000000C000000A2 >> 00000000300000000C000000A3 >> 00000000300000000C000000A3.backup >> 00000000300000000C000000A4 >> >> Could I safely delete the *A1, *A2, and maybe even the *A3 files? > Take a look at the pg_archivecleanup tool. > > You might also want to look at PgBarman to automate this. > > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin