On Thu, Jan 21, 2021 at 10:25:39AM +0900, Ian Lawrence Barwick wrote: > 2021年1月21日(木) 9:19 Mohamed Wael Khobalatte <mkhobalatte@xxxxxxxxxxx>: > > > > On Wed, Jan 20, 2021 at 2:37 PM Michael Lewis <mlewis@xxxxxxxxxxx> 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@xxxxxxxxxx> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
