Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDzJM-0003nq-JL for pgsql-admin@arkaria.postgresql.org; Mon, 05 Dec 2016 19:52:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cDzJM-0007Dz-2p for pgsql-admin@arkaria.postgresql.org; Mon, 05 Dec 2016 19:52:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cDzJL-0007Dt-MO for pgsql-admin@postgresql.org; Mon, 05 Dec 2016 19:52:27 +0000 Received: from mail-yw0-x231.google.com ([2607:f8b0:4002:c05::231]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cDzJI-0004IB-TU for pgsql-admin@postgresql.org; Mon, 05 Dec 2016 19:52:27 +0000 Received: by mail-yw0-x231.google.com with SMTP id i145so260569354ywg.2 for ; Mon, 05 Dec 2016 11:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P4f7zWCsDHOSCMex2gI4HQVDxXf2UudY1vqH7u1prM8=; b=jP/6x4LnuH4mu0WW9Omjx4q+LFhtsq7BM4BdDXCNutBMlMOBKZQhn9tYgkiTIha6Z4 tIePnzWOR++vbNQNpFnn6w1Q7RrvnRTdiDvgGH1J02D9UOK7FlyArdp5uyNxsUA2O/QZ bqm8HMHDvS1I/mXv6duiePl9mznDlmeRX+qM026Dg3zNub130AuRqxeRarGPchJ3N+Qx CZIVL658s0rinxstwSTYbNUeUuSUFdEHcHFQx8NB6nkkNVmrWBTBV6tRB04wEfV7Ov3q kSk7POd+GZFhGVw+7z15d+W2l8oJipzIF44NUFHlYkfyfKiW3takM9LDFDxR2J1G1jyd FfvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P4f7zWCsDHOSCMex2gI4HQVDxXf2UudY1vqH7u1prM8=; b=UjzQxJrrDMZV4VU52SwCnsiSO8TEjPm7KSKi8R0KLQpzaI7C3DE1CLWAThg+iJjANU 87MCeW85s0+8En7ZtxAXSlBFo1C2AjWA2OFwqGQ5xkDDPVeTT7FbQss5swnmjUCsy3ET 3i8VRXqvpg2Z+90Xmjmad1LSaeQtcbamoT2WQVIG+4Eh0yBABwjXZzKMOVNHxskGPULM OPf+pLWDof+xqUUinUe5DjERTyzKlZI3Qt3T2SqLiJBYQxMNdZoLq5K6i9SzyyO7wLq+ NOjKLNqbVJlddu3ZL8OjWvaZVFtJUB3S9xnX2ExxvtLarMLFJO4mnBFZZ/lHZ0LDz2mQ JKUw== X-Gm-Message-State: AKaTC03V+HhHGnrsTkzU/fNeco8EwDR5r1crQp77ACd1YFlj4kCzZ/0va8YfpGmsBedrsg== X-Received: by 10.13.226.85 with SMTP id l82mr55926804ywe.43.1480967542974; Mon, 05 Dec 2016 11:52:22 -0800 (PST) Received: from [192.168.1.130] (71-12-86-250.dhcp.spbg.sc.charter.com. [71.12.86.250]) by smtp.gmail.com with ESMTPSA id c14sm7257611ywh.7.2016.12.05.11.52.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Dec 2016 11:52:22 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-38DE4603-0998-44BB-9BFA-393DB781F08E Mime-Version: 1.0 (1.0) Subject: Re: Req. for some help with resolving the error "pg_basebackup: could not get WAL end position from server: FATAL: requested WAL segment" From: John Scalia X-Mailer: iPad Mail (14B100) In-Reply-To: <873181a7a9164ffe8b74c6e425a1a724@Mail02.usask.ca> Date: Mon, 5 Dec 2016 14:52:22 -0500 Cc: "pgsql-admin@postgresql.org" Content-Transfer-Encoding: 7bit Message-Id: <11CEA700-3307-4425-8ADF-6E819447889E@gmail.com> References: <873181a7a9164ffe8b74c6e425a1a724@Mail02.usask.ca> To: "Tharmarajah, Sam" X-Pg-Spam-Score: -2.7 (--) 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 --Apple-Mail-38DE4603-0998-44BB-9BFA-393DB781F08E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable More than likely your keep_wal_segments setting is too low. How long is the p= g_basebackup taking? Remember that segments are generated about every 5 minu= tes, so if the backup takes an hour, you need at least 12 segments stored. A= t 2 hours, you need 24 etc., I'd set the value to about 12.2 segments/hour o= f backup. -- Jay Sent from my iPad > On Dec 5, 2016, at 1:57 PM, Tharmarajah, Sam wrote: >=20 > Hi > =20 > I am a newbie to postgres. We are on postgres 9.1 running on RedHat 6. Wh= en we do the postgres backups we are noticing the following errors > =20 > pg_basebackup: could not get WAL end position from server: FATAL: request= ed WAL segment 000000010000020B00000040 has already been removed > =20 > But when I look into pg_xlog, I notice > =20 > 000000010000020B00000040.00000118.backup > =20 > =20 > May I know how to resolve this error? Are the backups done with these erro= rs, recoverable? > =20 > =20 > Thanks in advance for your support. > =20 > Thanx, > Sam > =20 > =20 > =20 > =20 --Apple-Mail-38DE4603-0998-44BB-9BFA-393DB781F08E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
More than likely your keep_wal_segments setting is too low. How long is the pg_basebackup taking? Remember that segments are generated about every 5 minutes, so if the backup takes an hour, you need at least 12 segments stored. At 2 hours, you need 24 etc., I'd set the value to about 12.2 segments/hour of backup.
--
Jay


Sent from my iPad

On Dec 5, 2016, at 1:57 PM, Tharmarajah, Sam <sambavan.tharmarajah@usask.ca> wrote:

Hi

 

I am a newbie to postgres. We are on postgres 9.1 running on RedHat 6.  When we do the postgres backups we are noticing the following errors

 

pg_basebackup: could not get WAL end position from server: FATAL:  requested WAL segment  000000010000020B00000040 has already been removed

 

But when I look into pg_xlog, I notice

 

000000010000020B00000040.00000118.backup

 

 

May I know how to resolve this error? Are the backups done with these errors, recoverable?

 

 

Thanks in advance for your support.

 

Thanx,

Sam

 

 

 

 

--Apple-Mail-38DE4603-0998-44BB-9BFA-393DB781F08E--