Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1Gqd-0006V2-9m for pgsql-admin@arkaria.postgresql.org; Wed, 17 Dec 2014 15:49:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Y1Gqc-0007yw-NB for pgsql-admin@arkaria.postgresql.org; Wed, 17 Dec 2014 15:49:10 +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 1Y1Gqb-0007yg-GT for pgsql-admin@postgresql.org; Wed, 17 Dec 2014 15:49:09 +0000 Received: from mail.journyx.com ([209.163.206.41] helo=mail.int.journyx.com) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Y1GqX-0006RC-FL for pgsql-admin@postgresql.org; Wed, 17 Dec 2014 15:49:07 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.int.journyx.com (Postfix) with ESMTP id 0997130004A; Wed, 17 Dec 2014 09:49:02 -0600 (CST) Received: from mail.int.journyx.com ([127.0.0.1]) by localhost (mail.int.journyx.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rKS_0SsDQ08t; Wed, 17 Dec 2014 09:49:01 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.int.journyx.com (Postfix) with ESMTP id C7057300050; Wed, 17 Dec 2014 09:49:01 -0600 (CST) X-Amavis-Modified: Mail body modified (using disclaimer) - mail.int.journyx.com X-Virus-Scanned: amavisd-new at mail.int.journyx.com Received: from mail.int.journyx.com ([127.0.0.1]) by localhost (mail.int.journyx.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RhUZwjvY-WwX; Wed, 17 Dec 2014 09:49:01 -0600 (CST) Received: from mail.int.journyx.com (zimbra.int.journyx.com [192.168.100.5]) by mail.int.journyx.com (Postfix) with ESMTP id 6BAB330004A; Wed, 17 Dec 2014 09:49:01 -0600 (CST) Date: Wed, 17 Dec 2014 09:49:01 -0600 (CST) From: Scott Whitney Reply-To: Scott Whitney To: John Scalia Cc: pgsql-admin@postgresql.org Message-ID: <1081051590.1153520.1418831341390.JavaMail.zimbra@mail.int.journyx.com> In-Reply-To: <1467885182.1153493.1418831257019.JavaMail.zimbra@mail.int.journyx.com> References: <5491A3F8.8000509@gmail.com> Subject: Re: Standby server startup question - not broken, just curious MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1153519_957065624.1418831341388" X-Mailer: Zimbra 8.5.0_GA_3042 (ZimbraWebClient - GC39 (Win)/8.5.0_GA_3042) Thread-Topic: Standby server startup question - not broken, just curious Thread-Index: fQrBGjgL9wr2ygk1mL6pqiI7GhTjLw== X-Pg-Spam-Score: -1.9 (-) 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 ------=_Part_1153519_957065624.1418831341388 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit My understanding is this: Once the standby stops (restarts, HUP, whatever), it needs to connect to the primary and get anything that didn't happen during the down time. This is _always_ somewhere in a WAL, hence wal_keep_segments. If this is set sufficiently high, you don't _need_ WAL archiving. It will find the missing pieces from those, replay, and get back into streaming mode. In the event that it's missing pieces it needs to replay, you'll need to reinitialize your standby from a base backup and start it back up. Someone please correct me if I am wrong. ----- On Dec 17, 2014, at 9:40 AM, John Scalia wrote: > Hi all, > I've got 3 PostgreSQL servers in a streaming standby configuration: 1 primary > and 2 standby. These have been running great for a long time, and they are all > running WAL archiving > as an insurance policy to the stream. My questions relate to when any standby is > started up, I always see in the logs that it tries to read a couple of WAL > segments that should be > present. What would happen if these weren't using WAL archiving - that is the > primary wasn't sending them segments? How many segments is a standby usually > looking for (I think I > always see two)? I've also seen that if one of these segments is broken or > malformed, that the standby errors on start and often fails to start. Could I > just remove the segment > causing the problem? After all with streaming working aren't WAL archives just > superfluous? > -- > Jay > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin Journyx, Inc. 7600 Burnet Road #300 Austin, TX 78757 www.journyx.com p 512.834.8888 f 512.834.8858 Do you receive our promotional emails? You can subscribe or unsubscribe to those emails at http://go.journyx.com/emailPreference/e/4932/714 ------=_Part_1153519_957065624.1418831341388 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My understanding is this:

Once the standby stops (restarts, HUP, whateve= r), it needs to connect to the primary and get anything that didn't happen = during the down time.

This is= _always_ somewhere in a WAL, hence wal_keep_segments. If this is set suffi= ciently high, you don't _need_ WAL archiving. It will find the missing piec= es from those, replay, and get back into streaming mode.

In the event that it's missing pieces it needs = to replay, you'll need to reinitialize your standby from a base backup and = start it back up.

Someone ple= ase correct me if I am wrong.

----- On Dec 17, 2014, at 9:40 AM, John Scalia <ja= yknowsunix@gmail.com> wrote:
Hi all,
<= br>I've got 3 PostgreSQL servers in a streaming standby configuration: 1 pr= imary and 2 standby. These have been running great for a long time, and the= y are all running WAL archiving
as an insurance policy to the stream. M= y questions relate to when any standby is started up, I always see in the l= ogs that it tries to read a couple of WAL segments that should be
prese= nt. What would happen if these weren't using WAL archiving - that is the pr= imary wasn't sending them segments?  How many segments is a standby us= ually looking for (I think I
always see two)? I've also seen that if on= e of these segments is broken or malformed, that the standby errors on star= t and often fails to start. Could I just remove the segment
causing the= problem? After all with streaming working aren't WAL archives just superfl= uous?
--
Jay


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

=


Journyx, Inc.
7600 Burnet Road #300
Austin, TX 78757
www.journyx.com

p 512.834.8888 
f 512-834-8858 

Do you receive our promotional emails? You can subscribe or unsubscribe to those emails here. 

=0A
= ------=_Part_1153519_957065624.1418831341388--