Re: Moving the master to a new server

From: Marc Millas <marc(dot)millas(at)mokadb(dot)com>
To: Glen Eustace <geustace(at)godzone(dot)net(dot)nz>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Moving the master to a new server
Date: 2022-02-15 12:58:40
Message-ID: CADX_1aYPE+HEVTt1TKmGLNeYimPJZsQidwgh0nJ07KAgH2rm=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

another way would be to, while everything running, you create a second
slave on the new machine on rocky8 with a pg_basebackup.

and start the new slave.

when low activity, you just stop the master, then promote the slave => new
master up
then modify the connection line in your recovery.conf file in the old
slave, and restart it.
maybe adding first:
recovery_target_timeline latest in the recovery.conf file

Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com

On Mon, Feb 14, 2022 at 8:59 PM Glen Eustace <geustace(at)godzone(dot)net(dot)nz>
wrote:

>
> On 15/02/22 8:39 am, Alan Hodgson wrote:
> > pg_dump -> restore will break your streaming replication. You'll need
> > to set it up again.
> That's what I thought might be the case.
> >
> > If the PG version isn't changing and you're still on the same version
> > of Linux, rsync would be easier.
>
> I did an ELevate upgrade on the slave from CentOS7 to Rocky8 and then
> just rename 10/data to data and that seemed to work just fine.
>
> But upgrading that way takes too long for the master so I build a new
> server instead. So, if I shutdown both postgresql instances old and new,
> rsync the data directory and restart on the new. I should be OK ?
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Glen Eustace,
> GodZone Internet Services, a division of AGRE Enterprises Ltd.,
> P.O. Box 8020, Palmerston North, New Zealand 4446 Ph +64 6 357 8168, Mob
> +64 27 542 4015
>
> “Specialising in providing low-cost professional Internet Services since
> 1997"
>
>
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tomas Vondra 2022-02-15 13:55:42 Re: increasing effective_cache_size slows down join queries by a factor of 4000x
Previous Message Laurenz Albe 2022-02-15 12:05:22 Re: Operator % and its meaning and use