From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade and rsync |
Date: | 2015-01-30 00:07:30 |
Message-ID: | 54CACB42.5050404@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/29/15 5:53 PM, David Steele wrote:
> On 1/29/15 12:42 PM, Josh Berkus wrote:
>> On 01/29/2015 09:11 AM, Bruce Momjian wrote:
>>> On Thu, Jan 29, 2015 at 12:09:58PM -0500, Andrew Dunstan wrote:
>>>> Then step 2 should specify that it's for the master.
>>> Right. Josh is just listing all the steps --- the pg_upgrade docs
>>> already have that spelled out in detail.
>> What I'm also saying is that, if we expect anyone to be able to follow
>> all of these steps, it has to be very explicit; just saying "Follow the
>> pg_upgrade docs but don't start the master yet" isn't clear enough,
>> because the pg_upgrade docs have a few alternative paths.
>>
>> On the whole, I personally would never follow this procedure at a
>> production site. It's way too fragile and easy to screw up.
>
> I'm in agreement with Josh - I would not use this method. I may be
> wrong, but it makes me extremely nervous.
>
> I prefer to upgrade the primary and get it back up as soon as possible,
> then take a backup and restore it to the replicas. If the replicas are
> being used for read-only queries instead of just redundancy then I
> redirect that traffic to the primary while the replicas are being
> upgraded and restored. This method has the least downtime for the primary.
>
> If you want less downtime overall then it's best to use the hot rsync /
> cold rsync with checksums method, though this depends a lot on the size
> of your database.
>
> Ultimately, there is no single best method. It depends a lot on your
> environment. I would prefer the official documents to contain very safe
> methods.
How do we define safe though? Your method leaves you without a backup server until your base backup completes and the replica catches up. I think we do a dis-service to our users by not pointing that out and providing a potential alternate *so long as we spell out the tradeoffs/risks*.
Ultimately, I think this thread really shows the very large need for a tool that understands things like LSNs to provide rsync-ish behavior that's actually safe.
FWIW, I personally am very leery of relying on pg_upgrade. It's too easy to introduce bugs, doesn't handle all cases, and provides no option for going back to your previous version without losing data. I much prefer old_version -- londiste --> new_version, and then doing the upgrade by reversing the direction of replication.
I also don't entirely trust PITR backups. It's too easy to accidentally break them in subtle ways.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Kelly | 2015-01-30 00:08:58 | Re: Exposing the stats snapshot timestamp to SQL |
Previous Message | Matt Kelly | 2015-01-30 00:01:51 | Re: Exposing the stats snapshot timestamp to SQL |