I have a bunch of servers in a cluster environment.. I wish for my master server to be a bit more stable, so it needs to be moved to another provider.. there are currently around 15 website installations and a few databases on there. Is there anything i need to be aware of before i go about backing it all up, and sending it over to a new installation? What will happen to my slave servers? I have seen a few people move installations over, but not with a cluster setup.
Do you move the server physically over or do you want to migrate the installation (software) of the master to a new server?
And the server is just the master that runs the ispconfig interface, it does not run any websites or email accounts locally?
It runs 9 websites, and a few databases.. but it's not a problem if i change these over to the main webserver and just have a 'ispconfg master VPS' or something.. Ideally, i would like to take the whole installation over across to a new server, including the websites and databases. There is no mail, DNS
In this case, you should be able to use the instructions from various threads here in the forum about moving a ispconfig install. For the master setup you should just ensure that you move over all mysql databases to the new master (dump everything with e.g.: mysqldump -uroot -p -cCeQ --hex-blob --quote-names --routines --events --triggers --all-databases -r all_databases.sql and import it on the new servers so that all the ispcsrv* users in mysql get moved as well as thats the users that the slaves need to connect to the master. On the slaves you should check if the hostname of the master is in /etc/hosts, if thats the case, then dont forget to set the new IP there as well.
Great thanks for the tips, i'll go ahead and make a test install - do you think it's pretty easy to switch between masters> i.e. if the new installation fails, i can just revert back to the original installation (providing i change nothing of coures)
As long as you don't add new sites, clients etc, it should be no problem to switch the master force and back.
I've ran into a few problems These are my steps: 1) Install ispconfug 3 on the debian server. It has to be the same version then on the old server. 2) copy all lines of the web* users from /etc/passwd and /etc/shadow to the new server. 3) copy all lines of the client* groups from /etc/group and /etc/gshadow to the new server. 4) Move the directories /var/www and /var/vmail to the new server (with preserved permissions). 5) import dump file. However i sucessfully logged into the control panel and saw all my data.. but to test if the ispconfig is fetching data from the servers I tried to view log files from the monitor section, in which they were outdated.. How do the slaves connect back to the control panel? Where would i need to configure my slaves to connect to my new control panel?
I believe the slaves use settings in the 2 files /usr/local/ispconfig/server/lib/config.inc.php and /usr/local/ispconfig/interface/lib/config.inc.php (on each slave server) to know where to connect to. As @till mentioned above, if the hostname of your master server is the same, you might just need to change the ip addr in /etc/hosts (on each slave server). Also the master server needs to allow your slaves to connect to its mysql server, so tcp port 3306 should allow connections from the slaves, and you have appropriate entries in the mysql.user table (on the master server). @till's comment above mentioning "all the ispcsrv* users in mysql get moved" covers this, and if you dumped all databases with the command he provided you should be covered.
Thanks, OK. Ill restart the whole installation again. One thing though, i ran the update.php in the ispconfig to reconfigure the services.. and it remove the ability to log in, my old username/pass no longer worked. I've since restored the server back to a vanilla deb installation so i can't look into it.. but im thinking something must have gone wrong. ?
OK i finally figured it out why it didn't update.. silly me: after importing the mysql file, of course a mysql reload is required to re-hash the user tables.