Re: upgrade using logical replication

On Thu, Jan 21, 2021 at 10:25:39AM +0900, Ian Lawrence Barwick wrote:
> 2021年1月21日(木) 9:19 Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com>:
>
>
>
> On Wed, Jan 20, 2021 at 2:37 PM Michael Lewis <mlewis(at)entrata(dot)com> wrote:
>
> Using pg_upgrade takes minutes for an in place upgrade. If you can
> allow 1+ hour of downtime, it seems overly complicated to use logical
> replication.
>
>
> I suppose the Atul's issue is what to do with the replicas. Once he does
> pg_upgrade, then he will need to provision new ones, no? I suppose in this
> case logical would be better, with the new instance itself having replicas.
> I haven't done it, and it's gonna require some setup time, definitely much
> longer than pg_upgrade then make do with one server until your new physical
> replicas are set up. 
>
>
> The replicas will need to be set up at some point anyway; with logical
> replication the new cluster is ready to go once the new primary is fully
> "seeded" (and the new replicas have caught up with that). Switchover can then
> take place whenever convenient, with minimal downtime, more time for testing,
> and the possibility of switching back if issues are encountered.
>
> Potential downsides to this approach are that the database schema may need to
> be
> modified to be suitable for logical replication, and additional resources may
> be
> needed to host the old and new clusters simultaneously during the migration
> process.

pg_upgrade docs have instructions on how to upgrade replicas in place
using rsync with hard links.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee