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"
>
>
>
>
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 |