So after successfully implementing "How To Set Up MySQL Database Replication With SSL Encryption On Debian Lenny" and applying these tweaks for Drupal, I wanted to setup replication of the "ispconfigdb" -- any issues or concerns I should be aware of? 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.) Thanks in advance for your feedback.
Strange, I received notification of a reply from Till, but now it is gone Till, I received an email notification of a reply from you a few hours ago but now it is gone ... I also searched around and found this post from waaaaay back in 2006: which sounds like this shouldn't be a problem ... can someone confirm if this is valid for ISPConfig v2 today? Thanks in advance
Thanks Falko I couldn't wait so I set it up ... the replication is working fine. 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)
There is a problem with the ispconfigdb replication Falko, as I mentioned, there does seem to be a problem. The database changes replicate fine; no issue there. But, ispconfig doesn't seem act on those changes Example: It did not create the webX group (as in the owner of /var/www/webX would normally be: www-data:webX -- that group is not created) Here was my test: Verify that replication is working via SHOW SLAVE STATUS \G; Create new Drupal multisite on the primary server (BTW, for some reason the ispconfig internal counter jumped a few positions from web58 to web66, for example) Setup the new Drupal site from the web interface (i.e., create 1st user, setup DB name, user and password) Verify that the various ipsconfigdb updates made it to the secondary (i.e., new site, admin user, email address, co-domains, etc etc etc -- everything in your Drupal/ISPConfig/Debian HowTo) Go over to the secondary and try to call up the web site It defaults to SharedIP html page Even manually copied over settings.php etc. 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 Any ideas?
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 ....)
Yes; for example, you could set up a cron job that runs every 5 minutes. This tutorial should give you the idea: http://www.howtoforge.com/mirroring_with_rsync Yes, it gets erased after the actions are performed.
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) Thanks
Thanks again Falko, I have set it up on both Primary & Secondary to do every 5 minutes so all bases are covered in both environments.
Creation of new site not working Falko, it is not working. 1) Replication is working fine (ispconfigdb and Drupal databases) 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? Any thoughts or suggestions?
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...
Is it a specific table? OK, Can you suggest a Table within ISPConfigdb that should not be replicated then, so the Slave can act on the .run but not have the completion flag set via replication before it acts? Thanks
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.
