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