Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XWSbI-0003E3-IJ for pgsql-admin@arkaria.postgresql.org; Tue, 23 Sep 2014 16:06:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XWSbI-0005dB-2Z for pgsql-admin@arkaria.postgresql.org; Tue, 23 Sep 2014 16:06:00 +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 1XWSbH-0005d5-18 for pgsql-admin@postgresql.org; Tue, 23 Sep 2014 16:05:59 +0000 Received: from mail-ig0-f175.google.com ([209.85.213.175]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XWSbD-0004jh-19 for pgsql-admin@postgresql.org; Tue, 23 Sep 2014 16:05:57 +0000 Received: by mail-ig0-f175.google.com with SMTP id h18so4876737igc.2 for ; Tue, 23 Sep 2014 09:05:53 -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=D7Fwai8EvazmN/MG2WTeS2FClaUczMdQErelGNfrCYI=; b=CVGUGphqyriIBfv9x1vyZk93BqSq4Jz939ELUJtHgGaWkbpNadPQgogirPU6Mvt4q0 O+RtKtZYTFooqKlxdBVQLn+kewkBvgndC9G/bQnL2WfFPT42+z2HDgxxFQzrRv/B/kF0 l62WvivavZ+VL8KoWUc/wrckXPZKG/ASBSEjOIog+xSXlKPbcQz0JIq8Q/HA1yW2IpN2 EmQogKL9wlut/S2l/KWhbxUaNTBoRwxnsQB0+S9gvlEv6t8Fr139NepSXDv0b5iofV/p zcL8fgAXhdEupVFV00ohfLluNgZA7vAzw00WrmLirkU/us/CMvhMO6q/f5H6/eCfjARI WZJg== X-Gm-Message-State: ALoCoQkHJqrn8F0GToJnBhRE38MKEZgSU60kxG4ZRPhNL4Umt+nz+UUyEO5nEDaQmFxg2A/5LYKON7LZJRo4U/WiTT+il6ppUI6DZDaYrBRlkP7EDkVuF3aeGzTsKXEjD94NuWUwPit0 X-Received: by 10.50.111.80 with SMTP id ig16mr4666676igb.43.1411488353705; Tue, 23 Sep 2014 09:05:53 -0700 (PDT) Received: from palos ([50.76.140.65]) by mx.google.com with ESMTPSA id an1sm1989614igc.7.2014.09.23.09.05.52 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 09:05:52 -0700 (PDT) Date: Tue, 23 Sep 2014 10:05:51 -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="54219a5f_41b71efb_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 --54219a5f_41b71efb_14be7 Content-Type: multipart/alternative; boundary="54219a5f_79e2a9e3_14be7" --54219a5f_79e2a9e3_14be7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Lance, 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 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 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 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 Make sense?=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 --=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. --54219a5f_79e2a9e3_14be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =
Hi Lance,

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

<= /div>
Using = the -x will get you to ONE POINT IN TIME. So if you backed up at 9PM you ca= n restore back to that point and that point ONLY. Some people call this poi= nt in time, but its only ONE point in time. 

If you are archiving the wal fil= es 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 s= tate 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 go= tten 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 its all good. Just make sure you have = the base backup + all wal files until the point in time you want. So in ord= er to keep three days of base backups you need at least three days of wal f= iles as well. 

Make sense? 

On Septem= ber 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 C= ampbell

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 se= nder at (303) 386-3955 or by return e-mail to the sender.

--54219a5f_79e2a9e3_14be7-- --54219a5f_41b71efb_14be7 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-ID: <04AB5E8A-1A03-48F1-868C-C93952DEA3D8> Content-Disposition: inline; filename="=?utf-8?Q?image001.png=4001CFD717.8CC62810?=" 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= --54219a5f_41b71efb_14be7--