Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 9B3F1633753 for ; Thu, 5 Mar 2009 09:56:01 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 36279-07 for ; Thu, 5 Mar 2009 09:55:58 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from locust.cns.vt.edu (locust.cns.vt.edu [198.82.169.14]) by mail.postgresql.org (Postfix) with ESMTP id 68B42632E9E for ; Thu, 5 Mar 2009 09:55:58 -0400 (AST) Received: by locust.cns.vt.edu (Postfix, from userid 986) id 54237118DD6; Thu, 5 Mar 2009 08:55:56 -0500 (EST) Date: Thu, 5 Mar 2009 08:55:56 -0500 From: Ray Stell To: Yauheni Labko Cc: pgsql-admin@postgresql.org Subject: Re: standby waiting for what? Message-ID: <20090305135556.GA9900@cns.vt.edu> References: <20090304200612.GA25611@cns.vt.edu> <200903041541.06149.yyl@chappy.com> <20090304213500.GE25611@cns.vt.edu> <200903041705.19794.yyl@chappy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903041705.19794.yyl@chappy.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/74 X-Sequence-Number: 31574 On Wed, Mar 04, 2009 at 05:05:19PM -0500, Yauheni Labko wrote: > No. %f is the WAL filename which is needed by the server to start recovery. my recovery command is: restore_command='/usr/local/pgsql/bin/pg_standby /data/pgsql/wals/alerts_oamp %f %p %r >> /home/postgresql/log/alerts_oamp/recovery.log' the process that is running is, from the ps command: sh -c /usr/local/pgsql/bin/pg_standby /data/pgsql/wals/alerts_oamp +00000002000000000000001C.00512178.backup pg_xlog/RECOVERYHISTORY 000000000000000000000000 >> +/home/postgresql/log/alerts_oamp/recovery.log there are 4 args to pg_standby: 1. /data/pgsql/wals/alerts_oamp the archive dir 2. 00000002000000000000001C.00512178.backup = %f 3. pg_xlog/RECOVERYHISTORY = %p 4. 000000000000000000000000 = %r Looks like %f to me. Right? So, how could it get set to a funky value like that? > 00000002000000000000001C.00512178.backup will give you start and end of WAL > segment, the WAL filename containing this segment and your label to identify > where it might be. That's why I asked you about your backup. I don't follow you here. How did you know that the string, 00000002000000000000001C.00512178.backup will provide the start and end of WAL segment? Please explain how you determined this? I suspect the standy is waiting for a WAL named 00000002000000000000001C and that file exists on the standby: ls -l /data/pgsql/wals/alerts_oamp/ total 114828 -rw------- 1 postgresql postgresql 16777216 Mar 4 11:28 00000002000000000000001A -rw------- 1 postgresql postgresql 16777216 Mar 4 11:29 00000002000000000000001B -rw------- 1 postgresql postgresql 16777216 Mar 4 12:24 00000002000000000000001C -rw------- 1 postgresql postgresql 16777216 Mar 4 12:25 00000002000000000000001D -rw------- 1 postgresql postgresql 16777216 Mar 4 12:26 00000002000000000000001E -rw------- 1 postgresql postgresql 16777216 Mar 4 14:45 00000002000000000000001F -rw------- 1 postgresql postgresql 16777216 Mar 4 14:45 000000020000000000000020 but, somehow I confused pg and the name being passed to pg_standby is wrong. I have a suspicion that if I mv /data/pgsql/wals/alerts_oamp/00000002000000000000001C to /data/pgsql/wals/alerts_oamp/00000002000000000000001C.00512178.backup that the recovery would pick up. If there is no understanding to be gained here, I might do that and then throw this out with the bath water and start over. > What is the archive_command for primary server? the archive command is working fine as you see above. It just runs a local script that does an rsync of the pg_xlog wal file over to the standby. I agree with you, something about the backup must have caused this confusion. I'm just rsyncing the cluster dir from the primary to the standby, removing pg_xlogs files, and setting recovery.conf. Is there a better way?