For example, any tables (temporary or otherwise) that I should avoid replicating from ispconfigdb?

(In case you are wondering, the two servers being replicated are identical, i.e., they started as the very same virtual machine but in two different locations/networks so I do want their ispconfig databases/ip addresses (and everything else about them) to remain exactly the same.)

But, it seemed like the ISPConfig on the secondary server wasn't acting on the changes when they came over via replication (for example, add a new site, modify co-domains, etc etc etc). And I did verify that the items were replicated properly.

I will do more testing to verify (in fact I have a number of updates I will be making to the primary server to thoroughly test this out).

Thanks again

EDIT: BTW, I noticed that just one thing is not replicating in Drupal -- menu changes; if I change the menu structure/order/etc for a site, they don't seem to happen on the secondary server ... everything else is fine. Right now I can work around it by doing it manually, but I more than a little curious as to why since the entire Drupal database (except cache and search data) is being replicated)

It seems to me that the ispconfig on the secondary is not performing the actions like creating folders etc on the replicated information; even though the replicated information makes it over cleanly

Click to expand...

This happens because the backend (which reads the configuration from the database and writes it to the configuration files) is looking for the file /home/admispconfig/ispconfig/.run before it starts to act; if this file is missing, the backend doesn't do anything. This file is created automatically by the frontend whenever you do a change in the control panel. Since you don't use the control panel on the second server, it is missing there. Maybe you should set up rsync mirroring between the first and the second server as well.

Falko, is it possible then to setup a crontab to rsync the file over at regular intervals?

What is the interval that this file is wiped? i.e., is it erased after the actions are performed? Or on a regular schedule?

Would this work? Thanks

(Hmm, you are making me wonder if for some reason there is some similar type of semaphore being used by Drupal for the Menu changes -- the menu changes are the only thing that is not being replicated there ....)

This happens because the backend (which reads the configuration from the database and writes it to the configuration files) is looking for the file /home/admispconfig/ispconfig/.run before it starts to act; if this file is missing, the backend doesn't do anything. This file is created automatically by the frontend whenever you do a change in the control panel. Since you don't use the control panel on the second server, it is missing there. Maybe you should set up rsync mirroring between the first and the second server as well.

Question: Why even copy the file (unless it has information in it that pertains to the updates to be acted on)? Why not just create the file every 5 minutes via cron on the secondary server using "touch"?

So, in effect, ispconfig would "flush" its cache (i.e., perform any pending updates) every 5 minutes on the secondary ... no matter what.

Why? Because I am not convinced that even doing an rsync every 5 minutes is going to "catch" the the /home/admispconfig/ispconfig/.run semaphore file -- i.e., it might be created/acted upon/deleted within a 5 minute cycle and rsync might never get to copy it from the primary.

Thoughts? (Sorry for all the questions, but I want to do to make sure I understand + use the most expedient method possible + keep additional "traffic" to a minimum)

Why? Because I am not convinced that even doing an rsync every 5 minutes is going to "catch" the the /home/admispconfig/ispconfig/.run semaphore file -- i.e., it might be created/acted upon/deleted within a 5 minute cycle and rsync might never get to copy it from the primary.

Click to expand...

Good point. Yes, I think creating the file every five minutes or so makes sense.

2) I have the cron job creating the .run file every 10 minutes and that is working fine

3) However, I created a new Drupal site tied to webXdb1, and created the replication database stub on the secondary, etc. But, ISPConfig never creates the User/Group/etc in the OS (I checked /etc/passwd)

4) What I get from Drupal is:

Code:

Site off-line
The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.
If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider's database server is running. For more help, see the handbook, or contact your hosting provider.
The mysqli error was: Access denied for user 'webXu1'@'localhost' (using password: YES).

(and that is not because of any error in the settings.php, it is because that User/Group does not exist at the OS level so it can't authenticate with mysql using the credentials that are in the settings.php).

5) Reminder that I am not replicating the "/var/lib/mysql" database -- could this have anything to do with it?

Oh... I think that happens because the update status in the master database gets deleted after the backend has run, and that deletion of the update status gets replicated to the salve database before the backend on the slave server could do its job...

Oh... I think that happens because the update status in the master database gets deleted after the backend has run, and that deletion of the update status gets replicated to the salve database before the backend on the slave server could do its job...

Just a quick thought: perhaps it could work like this if your replication slave is doing its work with a delay time, so it gets the changes a bit later (i.e. the update flag ist still there)

Another thing may be to rsync passwd and shadow files. As you said, the machines were originally cloned from the same VM so it should always stay in sync and besides the database replication and the whole directory tree under /var/www that is the only thing together with the VHost file of apache2 to keep in sync.

So perhaps it would be a possibility to do a full replica of the DB, sync /var/www, /etc/apache2/vhost/ & /etc/passwd, /etc/shadow, /etc/groups

Just a quick one, but I think the better way for staying in sync is to use ISPConfig3s multiple server configuration. v2 wasn't exactly made for that.