Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X0DHX-0003XM-Mr for pgsql-admin@arkaria.postgresql.org; Thu, 26 Jun 2014 17:16:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X0DHW-0007bY-Cr for pgsql-admin@arkaria.postgresql.org; Thu, 26 Jun 2014 17:16:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X0DHV-0007bK-9S for pgsql-admin@postgresql.org; Thu, 26 Jun 2014 17:16:17 +0000 Received: from mail-yk0-x22e.google.com ([2607:f8b0:4002:c07::22e]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1X0DHS-0006FS-6H for pgsql-admin@postgresql.org; Thu, 26 Jun 2014 17:16:16 +0000 Received: by mail-yk0-f174.google.com with SMTP id 19so2179951ykq.19 for ; Thu, 26 Jun 2014 10:16:11 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QjJl1ECNb9Qzt/qXOFJVDNJQTKTzVuXVC20URQ+BBEg=; b=uA4WQUB3cxpZQRrhULmHKtSO3N0nVrQxKftGj1hy3WDCIkb/mjlvywb1vXGHsSuN4E Q/neQ8WU9CvR489vHDdxFp8fqwhb/ALMaKVXxMmllEQo/YqZZJUekDPbXSqwgFnuMRf5 l3zrK6vifKRn9IZGb5OeJT5ejrCt5Png+QcizkgdI3E07YOHYZEC3K+3oNcljOBYc2Dz 1BjoJd0POt/B5K7/4F9nEIe1lflT06LZaiyzHX4r6s79Q6hzvfoD6fkCwg3EC2v598VV gK5vWDQ9hcEn0J3P6y7u8hQlwMKmm87yGI2LCcYvUtNkwu7clUdgIigQ7iZSP6228Qs+ e+kQ== X-Received: by 10.236.97.101 with SMTP id s65mr10174931yhf.51.1403802971701; Thu, 26 Jun 2014 10:16:11 -0700 (PDT) Received: from [192.168.254.4] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id n68sm10812193yhe.23.2014.06.26.10.16.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 10:16:11 -0700 (PDT) Message-ID: <53AC5554.2030603@gmail.com> Date: Thu, 26 Jun 2014 13:16:04 -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: Matheus de Oliveira , thomas simon CC: "pgsql-admin@postgresql.org" Subject: Re: Pg_basebackup does not do aything References: <53AB29E8.6010209@neteven.com> <53AB4C02.1030907@neteven.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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 From your last message: > It is recommended to configure it to grab archive files from somewhere (can be from other node) if you have archiving enabled. So, if the receiver can't keep up with the sender > (e.g. when the WAL files are rotated and the sender does not have the files the receiver wants anymore), it can get the files it need from archiving. > According to the postgresql documentation at 25.2.3 Preparing the Master for Standby Servers, Set up continuous archiving on the primary to an archive directory accessible from the standby. I took this to mean the archive_command = "scp %p postgres@:/" And yes, you can add a ";" at the end of this and specify a second server. That's what I'm doing. Oh, and you have to setup ssh keyrings so the scp will not prompt for a password. Anyway, I got the impression that the primary should push and the standby's should not pull WAL segments from this part of the docs. Although, I can see how you could just specify the scp in the restore_command and do the pull. I just don't know the safety of doing that. -- Jay -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin