Replacing the dead master server in ISPconfig multiserver mirror configuration

Hi Till,
I have in production two identical servers with Debian 9, in different datacenters, configured in mirror with ISPconfig 3.1 multiserver for email and web services.

Suddenly the master server for ISPconfig has died and I can not recover data in short time.

So as not to leave the slave server alone, I decided to install a new server from the beginning and copy the data from the current slave in order to restore the mirror as soon as possible. But how to do it? Which files of Apache, Postfix and PureFTPd should I copy? And for users and passwords (mailboxes, ftp) is it enough to copy the ispconfig database of the slave into the new master's one or must I copy some Debian files too? Is there an how-to to solve this situation?

Certainly I will have to copy the folders and files of /var/vmail/ - /var/www/ - /var/lib/mysql/ - /etc/bind/ - /etc/letsencrypt/ archive/ - /etc/letsencrypt/live/ and ISPconfig database from the slave to the master (after the new ISPconfig master installation).

Is there an easier way to do all this?

Thanks a lot

 

Old threads about situation:
https://www.howtoforge.com/community/threads/promote-slave-to-master-in-cluster.73430/

 

In my case the mysql master/master replication was interrupted about a month ago in one direction (ISPconfig master server -> ISPconfig slave server: stopped; the mail and webservices were public on the slave server, as now) and so now, on the server slave, I have both databases (dbispconfig and dbispconfig2) but noone is correct.
Also because I am continuing to make changes on the server slave in these days and I'm using the ISPconfig panel interface on the server slave. I see that ISPconfig interface, on the slave, write the change only on dbispconfig database: so I'm using the ISPconfig on slave server, the survivor, but the database updated is dbispconfig (in teory, the database of master server).
Can this be a problem for rebuilding the ISPconfig new sever master (and for the subsequent resynchronization of the slave)?

Could I use the ISPConfig Migration Toolkit to move everything from the slave server to the new master server?

 

Thanks Till.

I should understand better how ISPconfig multiserver works to decide what to do, because I noticed that from the web interface (of ISPconfig) installed on the slave server (of ISPconfig) I can not manage the slave server itself (ie the survivor). The panel works, but the changes are not writed on the services configuration files on the disk (and are written to dbispconfig database, instead of dbspconfig2 as I would expect), as if the slave could not act in the absence of the ISPConfig master installation up.

So I ask you:

1) Is it normal that the ISPconfig panel, actived on the slave, can not manage the services, if the server where ISPconfig's master is installed is down, or there is something wrong in my configuration?

2) To fix the situation quickly I could e.g. transform the slave installation of ISPconfig into a master, so I can operate on the surviving server?

3) You can explain me what happen between the two ISPconfig installations (master and slave) and which databases they writing, both when inserting a modification on the ISPconfig master panel, and when inserting a modification on the ISPconfig slave panel (the red sticker with the number of the changes, in ISPconfig, disappears because they are compared the two databases, dbispconfig and dbispconfig 2, both present on it mysql server)?

Thanks a lot

 

Thank you so much Till, now I know something more about how the multiserver works.

The good database was 'dbispconfig2' so I made it become 'dbispconfig'; I also made some changes to some tables and database permissions.
I changed the database name settings in the file /usr/local/ispconfig/server/lib/config.inc.php like you said, however, even if the panel seems to work fine, no changes are made to the disk and never appears, even for a moment, the red dot.
It seems that the server part of ISPconfig continues to work on dbispconfig2, any ideas?

About the red dot: in a functioning multiserver configuration, both the server part of the ISPconfig master and the server part of the ISPconfig slave, write (eg a flag) in the dpspconfig database on the master, to confirm to have performed the operations on disk, is it correct?

To avoid these inconveniences in the future, I'm thinking of changing the installation architecture of ISPconfig in this way. In a VM, on the physical machine A, I only will put the master version of ISPconfig and nothing else. On two VMs in two different physical machines (A and B) all services (DNS, emails and web sites) with a slave ISPconfig installation. Finally, in a VM on the physical machine B, a sleeping ISPconfig master installation that remains aligned, to the ISPconfig master in use, with the mysql replica of dbispconfig.
If the physical machine A should fall, it would be enough to change the IP address of eg. ispcmaster.myserver.net in the /etc/hosts file of the VM with the services on B and take it controls from the ISPconfig master on the VM on B. In this way I should be able to use ISPConfig 3 Migration Toolkit without problems if I'll have to migrate the services to one new machine.
Do you think it's a good solution?

Thanks for your patience