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.
--
- David Steele
david@pgmasters.net
