[Slony1-general] Switching Slave VM

[Steve Singer]

On Thu, 23 Jul 2020, Sung Hsin Lei via Slony1-general wrote:

> Hello,
> I have a slave machine who's database I want to restore on a different machine
> with a different ip. Since the backup process takes several hours, I disconnect the master,
> backup the slave db and restore it on the new slave machine. Then I shutdown the slave
> machine and reconnect the master to the new slave machine. Finally, I run the following 
> script:
> 
> store path (server = 1, client = 2, conninfo = 'dbname = Securithor2 host = 192.168.1.101 user = slonyuser password =
> Ert3c5L221JKert  port = 5432');
> store path (server = 2, client = 1, conninfo = 'dbname = Securithor2 host = 192.168.1.102 user = slonyuser password =
> Ert3c5L221JKert  port = 5432');
> 
> REPAIR CONFIG (
>   SET ID = 1,
>   EVENT NODE = 2
> );
> 
> This procedure works but I would like the old slave to maintain replication while I perform 
> the backup and restore. II would also like the new slave to catch up replication
> after I close the old slave an switch the node to point to new slave.
> 
> Adding a node or changing node id is not an option for us.
> 
> My question is, do I have to stop replication to old slave while I setup new slave
> or was I too paranoid and the procedure will also work if I do not interrupt replication
> during backup and restore process.

If you let data replicate to the 'old node' while the 'new node' is 
restoring then change the paths to point at the 'new node' slony will think 
that all the data sent to the old node is already present on the 'new node'. 
So to answer your question, no that won't work if you can't assign a new 
node id.

>From a slony point of view the 'old node' and 'new node' are the same node. 
Your original procedure works because Slony sees it as just one node with a 
changing IP/hostname.

Depending on your circumstances you could take a physical backup (ie with 
pg_basebackup) of the slony replica node restore it to the new server, stop 
the slons, replay the remaining WAL so the new server is in-sync with the 
slony replica then continue with the procedure you outlined above.

Steve





> 
> 
> Thanks.
> 
>