Cluster migration and adding additional features

Discussion in 'ISPConfig 3 Priority Support' started by stefanm, Aug 27, 2013.

  1. stefanm

    stefanm New Member HowtoForge Supporter


    just upgraded my small cluster setup with 2 machines from Squeeze/ISPConfig 3.0.3 to Wheezy/latest ISPConfig and everything works like a charm.

    Now I have to migrate this setup to two new machines and have two questions left:

    a) Since this is an old setup that was upgraded, it is currently lacking some of the newer features that were introduced with the newer ISPConfig versions and Debian Wheezy (php-fpm, Mailman, Munit&monit,aps,...). Can I install these on a running ISPConfig cluster or do they need to be installed before ISPConfig? Can I directly migrate from my current setup to the new machines with having all the new features installed. Will ISPConfig recognize the new features or what will I have to do? Would I have to install everything onto the old server before migration?

    b) Is there a way for a soft migration, lets say I have my old machine s1 (master) and s2 (slave) and the new machines n1 (new master) and n2 (new slave). Would be something possible like
    adding n1 as new slave,
    promoting n1 as new master,
    remove s1,
    add n2 as new slave
    remove s2
    or do I have to migrate everything from old master to new master directly with shutting down the old master until mail/web services on the new master are running again? BTW, do I also have to migrate everything from old slave to new slave or can ISPConfig "recreate" the slave?

    Lot of questions, many, many thanks for your help!
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Yes. Just run the ispconfig update.php script again after you installed them and choose to reconfigure services.

    b) I would install the new master under a new ip address and migrate all data from old master to it. When you are finished, either switch the ip address so that the new server uses the old ip or you change the nds records and /etc/hosts file on the slave to connect to the new master instead of the old one.
  3. stefanm

    stefanm New Member HowtoForge Supporter

    Hi Till,

    many thanks for your help!
    One last questions concerning the slave. The old slave is also to be replaced with a new slave (much better hardware). After installing the new slave, do I have to migrate all data from the old slave, too, or can the master "rebuild" the slave? Can this be done with the "resync" feature of ispconfig?

    Again, many thanks for your help!
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    Better migrate the slave as well (especially the system users and groups + the web data off course) and then use the resync tool just to write the vhost files and bind zones and similar config files again. The linux users are important to keep the same uid's for the website users.
  5. stefanm

    stefanm New Member HowtoForge Supporter

    Hi Till,

    sorry to bother you again with the migration stuff, but while setting up the servers I got some new questions specific to the migration of a cluster:
    I read for example your post at and this seems pretty clear if you migrate to a new server while keeping ip and all passwords, but I am migrating to new master and (single) slave with new IPs and new passwords for system root, mysql root,...

    Currently I am at the point where all prerequisites are installed on master and slave and the new master has ispconfig running. Now there appear two major concerns regarding the migration of the system databases (both mysql and ispconfig).

    * Beacuse of the new IPs and the new passwords I cannot simply restore the mysql system database on the new master, however the user table of the old master contains all the database users created by ispconfig (for the client databases). Do I need to transfer them manually to the mysql.user table on the new master or are these entries recreated by the "resync" tool of ispconfig?

    * The ispconfig database has several data records containing the IPs of the old servers, e.g. the server configuration. If I would simply restore the ispconfig database from the old server, I would overwrite everything in the new master. What adjustments would I have to make before importing the ispconfig database to the new master? Or is this handled by running the ispconfig updater /or "resync", too? For example the table dbispconfig1.server has entries for both the old master and the old slave. Do I hve to remove the old slave and change the ip of the master before importing the database or is this done by the updater script or resync?

    * When ispconfig is installed on the slave, it creates the internal ispconfig database user and gets connected to the master . To prevent this information from being overwritten with the data from the old master, does this mean I must wait with installing the slave until the master is migrated?

    * When in this process should I run an ispconfig update and when the "resync" tool? What exactly does the resync tool recreate?

    * With the migration I also want to move from courier to dovecot. I guess I will do this at the very end when everything else has been done (with the courier to dovecot script you posted on the forums)?

    Sorry for more migraton questions and again many,many thanks for your help!
    Last edited: Sep 1, 2013
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Export the recors of the mysql.user and mysql.db tables on the old server with phpmyadmin. Choose a format were each record has its own line. Then copy only the lines for the client database users and execute the in phpmyadmin on the new server. you can copy all lines in one chunk.

    . Import the whole dbispconfig database. You can change the IP addresses in ispconfig later.

    Yes, the master should be migrated first.

    The resync tool emulates a update of a record. For a website E.g. it does the same as if you would open the website settings, change a value and press save.

    Yes. I would do this as last step.

Share This Page