Re: A Modest Upgrade Proposal - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: A Modest Upgrade Proposal
Date
Msg-id CAB7nPqQorVtGeCGL3ro-21N7iUh7XYeyW_4wqOwZ3uaZQq-b-w@mail.gmail.com
Whole thread Raw
In response to Re: A Modest Upgrade Proposal  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jul 28, 2016 at 10:22 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> It might, actually. One approach for online upgrade is to:
>
> * pg_basebackup the master
> * start the replica and let it catch up
> * create a logical replication slot on the master
> * replace the replication.conf on the basebackup so it stops recovery at the
> lsn of the replication slot's confirmed_flush_lsn
> * stop the replica and pg_upgrade it
> * have the upgraded replica, now a master, replay from the old master over
> logical replication
> * once caught up, switch over
>
> This means a full dump and reload with a full rebuild of all indexes, etc,
> isn't needed. All shared catalog stuff is copied (until we switch to logical
> rep for the final catch-up).

This is a per-database logic to perform an upgrade of a single
database, right? If a cluster has multiple databases you need one
logical slot per database to complete an upgrade, which is where
sync_synchronous_names which is able to take now multiple entries
helps as well to ensure that the former master is in sync with the all
the logical slots in place.
-- 
Michael



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: A Modest Upgrade Proposal
Next
From: Thomas Munro
Date:
Subject: Re: LWLocks in DSM memory