Re: Moving the master to a new server

Поиск
Список
Период
Сортировка
От Marc Millas
Тема Re: Moving the master to a new server
Дата
Msg-id CADX_1aYPE+HEVTt1TKmGLNeYimPJZsQidwgh0nJ07KAgH2rm=Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Moving the master to a new server  (Glen Eustace <geustace@godzone.net.nz>)
Ответы Re: Moving the master to a new server  (Glen Eustace <geustace@godzone.net.nz>)
Список 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



On Mon, Feb 14, 2022 at 8:59 PM Glen Eustace <geustace@godzone.net.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"



В списке pgsql-general по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Operator % and its meaning and use
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: increasing effective_cache_size slows down join queries by a factor of 4000x