Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UDQHS-0000fD-LS for pgsql-admin@arkaria.postgresql.org; Thu, 07 Mar 2013 02:10:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UDQHR-0001zc-9O for pgsql-admin@arkaria.postgresql.org; Thu, 07 Mar 2013 02:10:01 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UDQHE-0001oe-9R for pgsql-admin@postgresql.org; Thu, 07 Mar 2013 02:09:48 +0000 Received: from mail-pb0-f49.google.com ([209.85.160.49]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UDQHC-0007SF-ND for pgsql-admin@postgresql.org; Thu, 07 Mar 2013 02:09:47 +0000 Received: by mail-pb0-f49.google.com with SMTP id xa12so6904078pbc.36 for ; Wed, 06 Mar 2013 18:09:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type:x-gm-message-state; bh=Ih/OynPB8Ed+IdqBB7oGqMeKOdm/tQinqLWIomEj4rI=; b=mabJMvV1/5IZ9qcM8ZeeqjS4YNycJHVc3miBY5gsyPGGQH/CwkKAS97xxTl5XAYV2N Za5YCgXy7bc03AYr70DRHMt0J98kBdcq+tcFXoo/TyWzq5rKJ5Zk6Y7ve79KC3EUm7/D AJwiggzixUkgqD8b7UbsWmzxCnj4nZqpAoIejd1IeUCLRKgv0Ngae6CGFI4lNEcwHcvS nmv/yMAjIpvWicD7xIYrbZxQGoe+kcIxJyWp8rOCxZtUcg8E7UHnmw7h0tWimDy9MtAq HFQ76cNicumLaVutinHDWmRqi2d5gFu1ZwofhcR8MgExi4T3sSau7eH3H2ipan/+g0Hs VbmQ== X-Received: by 10.66.248.129 with SMTP id ym1mr362590pac.157.1362622185347; Wed, 06 Mar 2013 18:09:45 -0800 (PST) Received: from Kevins-MacBook-Pro.local (S01060014bf81f750.cg.shawcable.net. [174.0.118.21]) by mx.google.com with ESMTPS id hf4sm218462pac.3.2013.03.06.18.09.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 18:09:44 -0800 (PST) Message-ID: <5137F6E7.2000300@consistentstate.com> Date: Wed, 06 Mar 2013 19:09:43 -0700 From: CS DBA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Prashanth Ranjalkar CC: pgsql-admin@postgresql.org Subject: Re: HOT Standby - slave does not appear to be removing wal files References: <5137EE26.6010405@consistentstate.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080306020504080808010102" X-Gm-Message-State: ALoCoQkZbFeg4G/kLbtmnDofiWl9KURehEcQSlnXgSYMyhtWvK5jNb+Y88d1WwPK/tkxVjGS1AmT X-Pg-Spam-Score: -2.6 (--) 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 This is a multi-part message in MIME format. --------------080306020504080808010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/6/13 7:02 PM, Prashanth Ranjalkar wrote: > While setting up Hot Standby, it's not a method to copy the primary > database using dump and restore it on standby using restore command > as it's a logical backup. I doubt your WAL archiving is enabled and > files are copied to archive destination that set in archive_command > therefore keep accumulating under pg_xlog directory. > > For hot standby setup, archiving must be enabled and online backup > (file system level) needs to be taken for setting up Standby server > and recovery.conf need to be prepared on slave server. > > Please go through > http://www.postgresql.org/docs/9.2/static/high-availability.htmlfor > more details. > /*Thanks & Regards,*/ > //** > /*Prashanth Ranjalkar*/ > /*Database Consultant & Architect*/ > /*Skype:prashanth.ranjalkar*/ > */www.postgresdba.net /* > > > > On Thu, Mar 7, 2013 at 7:02 AM, CS DBA > wrote: > > All; > > We're doing a migration as follows: > > 1) we setup a HOT standby pair > > 2) we did an import of a db that wan backed up via pg_dump > > The pg_xlog directory has > 1700 files in it, It seems that the > slave is way behind which I get since we just imported a 55GB > database but the slave is not removing it's local pg_xlog wal files. > > We actually stopped the import when the slave hit 97% full for > the file system where we have it's pg_xlog directory mounted > after like 30minutes the file count in the slave's pg_xlog dir has > not changed. > > Any thoughts per why the slave is not removing these files? > > Thanks in advance > > > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org > ) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin > > We actually are in HOT standby mode, and it is working. However we are also migrating a second db from an older (8.4) server into this master so we did a dump (using the 9.2.2 pg_dump binary) from the 8.4 db and then restored it into our current 9.2 master --------------080306020504080808010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/6/13 7:02 PM, Prashanth Ranjalkar wrote:
While setting up Hot Standby, it's not a method to copy the primary database using dump and restore it on standby  using restore command as it's a logical backup. I doubt your WAL archiving is enabled and files are copied to archive destination that set in archive_command therefore keep accumulating under pg_xlog directory.

For hot standby setup, archiving must be enabled and online backup (file system level) needs to be taken for setting up Standby server and recovery.conf need to be prepared on slave server.

Please go through http://www.postgresql.org/docs/9.2/static/high-availability.html for more details.
Thanks & Regards,
 
Prashanth Ranjalkar
Database Consultant & Architect



On Thu, Mar 7, 2013 at 7:02 AM, CS DBA <cs_dba@consistentstate.com> wrote:
All;

We're doing a migration as follows:

1) we setup a HOT standby pair

2) we did an import of a db that wan backed up via pg_dump

The pg_xlog directory has > 1700 files in it, It seems that the slave is way behind which I get since we just imported a 55GB database but the slave is not removing it's local pg_xlog wal files.

We actually stopped the import when the slave hit 97%  full for the file system where we have it's pg_xlog directory mounted
after like 30minutes the file count in the slave's pg_xlog dir has not changed.

Any thoughts per why the slave is not removing these files?

Thanks in advance




--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

We actually are in HOT standby mode, and it is working. However we are also migrating a second db from an older (8.4) server into this master so we did a dump (using the 9.2.2 pg_dump binary) from the 8.4 db and then restored it into our current 9.2 master



--------------080306020504080808010102--