Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XWT6s-0004cZ-52 for pgsql-admin@arkaria.postgresql.org; Tue, 23 Sep 2014 16:38:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XWT6r-0002HX-4x for pgsql-admin@arkaria.postgresql.org; Tue, 23 Sep 2014 16:38:37 +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 1XWT6p-0002HP-NQ for pgsql-admin@postgresql.org; Tue, 23 Sep 2014 16:38:35 +0000 Received: from mail-ie0-f177.google.com ([209.85.223.177]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XWT6k-0007NC-CJ for pgsql-admin@postgresql.org; Tue, 23 Sep 2014 16:38:34 +0000 Received: by mail-ie0-f177.google.com with SMTP id x19so9417617ier.8 for ; Tue, 23 Sep 2014 09:38:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type; bh=oNjEkCBG+xEsb/fGDfGP+dT5F0qT+MYoRplPThAkd58=; b=NGL9L3gPhfHbNQ/XHgaKJpuvc0vmInfYzZimLevNqb6hc9DJmByt6Ztez4lhhvy/rc 71TNNghmiAaBoCUUSBb85MVD5OPZdmlWivruLx/lvUdOiwg/96pyAAGy0fkIqqkafXlY o5o1oVE9fKo+JE5YUeQdeWYjKHgh3Xr6kuDblWp5DoIvx1lW9z49IdGSWngiz7s/1JaK MEei08BCNoVqRCeWchxf9E4OupDYXe1qJmbT9YvbLXY6tbXmJXzsM0CUCDok5Ufu8mN2 do+4vU/ndmTDkJucAUrsSKiBh50/dgSVvaebG27D5en2Z25jNODUZBydwmjZvto5rXtp 1FZw== X-Gm-Message-State: ALoCoQl1ixSzH/VLir9cpqqYCuj4996c3qpGXPhARcWLciDm+StN1R5ixQ/PDSAX/VStjkc1NgYegJTluUbQGnYtdnNgLQ87HIW7J+6PvMB03xgdMkzcH+Hl5ko0+nBYsJCJrcsNepcA X-Received: by 10.42.227.10 with SMTP id iy10mr4292880icb.3.1411490306556; Tue, 23 Sep 2014 09:38:26 -0700 (PDT) Received: from palos ([50.76.140.65]) by mx.google.com with ESMTPSA id v2sm2050195igs.11.2014.09.23.09.38.25 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 09:38:25 -0700 (PDT) Date: Tue, 23 Sep 2014 10:38:24 -0600 From: Jason Mathis To: "=?utf-8?Q?pgsql-admin=40postgresql.org?=" , =?utf-8?Q?Campbell=2C_Lance?= Message-ID: In-Reply-To: References: Subject: Re: Clarification on pg_basebackup X-Mailer: Airmail (247) MIME-Version: 1.0 Content-Type: multipart/related; boundary="5421a200_515f007c_14be7" X-Pg-Spam-Score: -2.8 (--) 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 --5421a200_515f007c_14be7 Content-Type: multipart/alternative; boundary="5421a200_5bd062c2_14be7" --5421a200_5bd062c2_14be7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline yep that sounds good! On September 23, 2014 at 10:18:36 AM, Campbell, Lance (lance@illinois.edu) = wrote: Jason, Thanks so much.=C2=A0 That makes sense.=C2=A0 That was what I was trying to= communicate.=C2=A0 OPIT vs APIT.=C2=A0 =C2=A0 So if I am doing a APIT I can do a pg_basebackup each night without the =E2= =80=93X option.=C2=A0 I save all WAL files.=C2=A0 If I need to restore duri= ng the day I then only have to restore from the last basebackup and apply a= ll of the WAL files from that time forward.=C2=A0 Did I get that correct?= =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 Thanks, =C2=A0 Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 =20 =C2=A0 =C2=A0 From: Jason Mathis [mailto:jmathis@redzonesoftware.com] Sent: Tuesday, September 23, 2014 11:06 AM To: pgsql-admin@postgresql.org; Campbell, Lance Subject: Re: [ADMIN] Clarification on pg_basebackup =C2=A0 Hi Lance, =C2=A0 Maybe you want another view on it but I fear there is a slight miscommunica= tion from our back and forth last week.=C2=A0 =C2=A0 Using the -x will get you to ONE POINT IN TIME. So if you backed up at 9PM = you can restore back to that point and that point ONLY. Some people call th= is point in time, but its only ONE point in time.=C2=A0 =C2=A0 If you are archiving the wal files then you can restore to ANY POINT IN TIM= E. See the difference, its a big deal:) So if you backed up at 9PM and you = need your database back to the state at 10am, no problem! Restore your 9PM = and all the wal files until 10am. This is ANY POINT IN TIME. I feel the ter= m "point in time=E2=80=9D has gotten diluted and now there is two different= =E2=80=9Cpoint in time;=E2=80=9D one or any and that a huge difference. = =C2=A0 =C2=A0 =C2=A0 In all honestly it sounds to me you want ANY POINT IN TIME. So forget about= the =E2=80=9C-x=E2=80=9D and just archive your wal files and its all good.= Just make sure you have the base backup + all wal files until the point in= time you want. So in order to keep three days of base backups you need at = least three days of wal files as well.=C2=A0 =C2=A0 Make sense?=C2=A0 =C2=A0 On September 23, 2014 at 9:18:37 AM, Campbell, Lance (lance@illinois.edu) w= rote: PostgreSQL 9.3 Would someone be able to clarify if one should use the =E2=80=93X option wi= th pg_basebackup when your intention is to include all WAL files created?= =C2=A0 There are two scenarios.=C2=A0 The first scenario listed below makes= sense using the =E2=80=93X option.=C2=A0 Bus scenario #2 has me a little c= onfused.=C2=A0 I don=E2=80=99t want to cause any issues when restoring. =C2=A0 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Use pg_basebackup for a fully standalone r= estorable snapshot of the database using the =E2=80=93X parameter.=C2=A0 Wh= en a failure occurs you restore the database to that exact point in time. 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You restore from a pg_basebackup and you a= lso apply all of the WAL files since the last pg_basebackup.=C2=A0 Do you w= ant to use the =E2=80=93X option when doing the pg_basebackup if your inten= tion is to have all of the WAL files since you backed up last?=C2=A0 Or doe= s it matter.=C2=A0 Would PostgreSQL just ignore the duplicate WAL files tha= t were created by the =E2=80=93X option during the pg_basebackup?=C2=A0 =C2=A0 Thanks for your clarification.=C2=A0 This is a hard scenario to test. =C2=A0 Thanks, =C2=A0 Lance Campbell Software Architect Web Services at Public Affairs 217-333-0382 =20 =C2=A0 =C2=A0 =C2=A0 This transmission contains confidential and privileged information intended= solely for the party identified above. If you receive this message in erro= r, you must not use it or convey it to others. Please destroy it immediatel= y and contact the sender at (303) 386-3955 or by return e-mail to the sende= r. --=20 =20 This transmission contains confidential and privileged information intended= =20 solely for the party identified above. If you receive this message in=20 error, you must not use it or convey it to others. Please destroy it=20 immediately and contact the sender at (303) 386-3955 or by return e-mail to= =20 the sender. --5421a200_5bd062c2_14be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =
yep that sounds good!


On S= eptember 23, 2014 at 10:18:36 AM, Campbell, Lance (lance@illinois.edu) wrote:

Jason,

Thanks so much.  That makes sense.  That was what I was trying to communicate.  OPIT vs APIT. 

 

So if I am doing a APIT I can do a pg_basebackup each night without the =E2=80=93X option.  I save all WAL files.  If I need to restore during the day I then only have to restore from the last basebackup and apply all of the WAL files from that time forward.  Did I get that correct?    

 

 

Thanks,

 

Lan= ce Campbell

Software Architect

Web Services at Public Affairs

217-333-0382

3D"University

 

 

From: Jason Mathis [mailto:jmathis@redzonesoftware.com]
Sent: Tuesday, September 23, 2014 11:06 AM
To: pgsql-admin@postgresql.org; Campbell, Lance
Subject: Re: [ADMIN] Clarification on pg_basebackup

 

Hi Lance,

 

Maybe you want another view on it but I fear there is a slight miscommunication from our back and forth last week. 

 

Using the -x will get you to ONE POINT IN TIME. So if you backed up at 9PM you can restore back to that point and that point ONLY. Some people call this point in time, but its only ONE point in time. 

 

If you are archiving the wal files then you can restore to ANY POINT IN TIME. See the difference, its a big deal:) So if you backed up at 9PM and you need your database back to the state at 10am, no problem! Restore your 9PM and all the wal files until 10am. This is ANY POINT IN TIME. I feel the term "point in time=E2=80=9D has gotten diluted and now there is two different =E2=80=9Cpoint in time;= =E2=80=9D one or any and that a huge difference.    

 

In all honestly it sounds to me you want ANY POINT IN TIME. So forget about the =E2=80=9C-x=E2=80=9D and just archive your wal files and i= ts all good. Just make sure you have the base backup + all wal files until the point in time you want. So in order to keep three days of base backups you need at least three days of wal files as well. 

 

Make sense? 

 

On September 23, 2014 at 9:18:37 AM, Campbell, Lance (lance@illinois.edu) wrote:

PostgreSQL 9.3

Would someone be able to clarify if one should use the =E2=80=93X option with pg_basebackup when your intention is to include all WAL files created?  There are two scenarios.  The first scenario listed below makes sense using the =E2=80=93X option.  Bus scenario #2 has me a little confused.  I don=E2=80=99t want to cause any issues when restoring.

 

1)      Use pg_basebackup for a fully standalone restorable snapshot of the database using the =E2=80=93X parameter.  When a failure occurs you restore the database to that exact point in time.

2)      You restore from a pg_basebackup and you also apply all of the WAL files since the last pg_basebackup.  Do you want to use the =E2=80=93X option when doing the pg_basebackup if your intention is to have all of the WAL files since you backed up last?  Or does it matter.  Would PostgreSQL just ignore the duplicate WAL files that were created by the =E2=80=93X option during the pg_basebackup? 

 

Thanks for your clarification.  This is a hard scenario to test.

 

Thanks,

 

Lance Campbell

Software Architect

Web Services at Public Affairs

217-333-0382

3D"University

 

 

 

This transmission contains confidential and privileged information intended solely for the party identified above. If you receive this message in error, you must not use it or convey it to others. Please destroy it immediately and contact the sender at (303) 386-3955 or by return e-mail to the sender.


This transmission contains confidential = and privileged information intended solely for the party identified above. If you receive = this message in error, you must not use it or convey it to others. Please destroy it immediately and contact the se= nder at (303) 386-3955 or by return e-mail to the sender.

--5421a200_5bd062c2_14be7-- --5421a200_515f007c_14be7 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-ID: <8DD68B07-A24E-4D55-9DF3-7671569DDC2D> Content-Disposition: inline; filename="=?utf-8?Q?image001.png=4001CFD720.0B34AAC0?=" iVBORw0KGgoAAAANSUhEUgAAAJYAAAAZCAYAAADT59fvAAAFkElEQVRoge2aQWjbVhjH/xop85hD lMuQ2WEKdcG7rNKtYQmxTovZITIkdIVCLXoqZLi+ubQQB1aWm2Ma6KmVC4WsJBCH0dmnWiEt6Wl+ vQXqEfUUMQZVmQZqN3g7ODJ2otSSY3uk0w9MYiN9+kv663t63/eYhftP6GJRQy9YSMWRUySmJ8EC TjVDAPBV2MTlyB7e/HOmqyAjQ3/j4f5YT4UFnG6GAGDkzDv8/Mfn2H79WVdBJkd/x8iZdz0VFnC6 +ei/FhDwYTLk9mNc4JGeG8eLutH8bUrg27aR0mpfhQWcblyNtaBI4DkWpmWD51gADbMBgGnZKD3d HZjAgNOJq7G2iA5+WsBWbQ+vIqMYCYeaxpLSKkhLJgsIcMP1HSunVjF2MY9ihWBK4PHGsgEAGtED UwV4wtfLu26Y/dIR8IHhy1ivAmMFeCQoNwT0hcBYAX3BdVbYazIrFUpe7gMA2OEQ0rPjiAv8e3uK umHSxaIGff91c7/8fAI8x/rqRRbLNfqgQprfZyZiuD437itGt1pK27u0sL4DoFEHdOujKksl6sTl I6NQs7InbaZl0+W1HTyokGZJiNQN8ByL9OwFpBKi53PUiE4X1Wrzu3Augvz8tGcdytIG9H0TbDgE jehIJcTBGCs/P81IaZVqRMfeo4wnc/Acy6hZGeLVu5TUDbx+fANsOOS7wZ1KiAwb/oQmb63i+ty4 b1OdRIs8GWP4CEvFq3ehER1xcYwefqDUrMwkb61S538vekzLplJaBR9hUbt3ranFtGyaWalAWSph 68Ur6jVeXOAZKBKV0iquz417NhUAJG+ugh0OoXbvGgMApG5Q8erdwQ2FTuXeb8ZhwyHnb9erJtjh RoyRTz/uNkTXWoQoxzj7Jm+ugtQNenib82c5nD/LedYhpVWYlg01m2zTwoZDjJqVGXkyhmK5hpxa PXKsTvi5RrphUo3ouPKN2PxNiHKMmpX9GWvk4MIG+EfNJmFaNpQfN2Batu8b7lAs1yipG0jPXjjW 4Pn5BACgsP6828P4whnuHVIJkfFlLCHq/akKaEeejDFqVgapG07G6cpcm88a7TThXOTYbXiOZYQo B9OyoRG9axN3gudYJi7w0IgOKa1S3TCbxwqMNUBSCZFJJUSQugFlaaOrGOafjS5Ip3vBDmh02bh9 CUKUg0Z0jF3MN4ffY40lT8SQUyTohokvDmYdbDiEnCINRPCHipqVmVRCRGl7F8pSqets0qm1dng1 Sr9gwyGmdu8as5CKAwAWixoyKxXqaix5IoaZyS8xJfDgObY5nQUay4/3HmWC7HUC8vPTEKJcVy/Y zkTEKVEcxxbRG9sPKHPlFIk5mKFieW3HPWNNiWNtZgIaDWjnE/QMTwYbDjHVggIhymGxqGHTxzKk ma9jAIDW2pwbTk3LmZX2g9L2bttDIUS5ZuZyrWNl7pR7LuLNX297Gk8jOi2s72Djh0snunBSWqX5 7xN9vQFAY2reWmphwyFGvZGkzjKkmYmYpziphMgU1p9TjegolmvUrRCaU6vUtGxs3L7UwzM4SmF9 B+xwqK02x3OjAAbU0jEtm2q1PQBwreO8bz8nOy6v7VCN6M1P5k4ZU+d5T3Gcqv/m0120xlhe26Gk bngyVauW1tlPx2MfnK9z/q0IUY6pFhTfw5WT7ZSlkmMi6mjMqVVaWH8ONSt37G604gytL37zvixq SuDbanOmZdPFYhXyZAzMwv0ntPjTY1yOHD1xPzzcH0Pqu29d2xZSWm27EVemhY4tB1I3aKfMqd5I diy4traT3Diu1dJJi5csd3i/41olxXKNmpbtuytQLNfo5rNdkJcGTMuGEOUgnIsgPXvBVyH6cNsL AKoFxdPDllmpgLzch26Y4DnWaZmBUX/59UjQbvFimID/B/8CO2CIAn28iA0AAAAASUVORK5CYII= --5421a200_515f007c_14be7--