On 16/02/22 1:58 am, Marc Millas wrote:
another way would be to, while everything running, you create a second
slave on the new machine on rocky8 with a pg_basebackup
Thanks, I did consider this as well. Last night I did the move using
the rsync approach and it worked very well.
--
=-=-=-
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
On Tue, 2022-02-15 at 08:58 +1300, Glen Eustace wrote:
>
> 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 ?
>
Should be, yeah.
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 ELeva
On Tue, 2022-02-15 at 08:29 +1300, Glen Eustace wrote:
> I need to move my master postgresql deployment to a new server.
>
> I am comfortable with stopping all connections then doing a
> pg_dumpall >
> psql to move the databases, they are not huge so this completes in
> an
> acceptable time and
I need to move my master postgresql deployment to a new server.
I am comfortable with stopping all connections then doing a pg_dumpall >
psql to move the databases, they are not huge so this completes in an
acceptable time and I am not expecting any data loss but I am unsure of
what impact thi
