HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Tips/Tricks/Mods (http://www.howtoforge.com/forums/forumdisplay.php?f=19)
-   -   Any issues with replication of ISPConfigdb? (http://www.howtoforge.com/forums/showthread.php?t=48694)

tester321 11th September 2010 06:12

Any issues with replication of ISPConfigdb?
 
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.

tester321 11th September 2010 15:05

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

falko 12th September 2010 23:09

No, there will be no problems replicating the ISPConfig db. :)

tester321 12th September 2010 23:21

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)

tester321 13th September 2010 04:16

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?

falko 13th September 2010 13:54

Quote:

Originally Posted by tester321 (Post 239124)
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

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.

tester321 13th September 2010 17:04

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 ....)

Quote:

Originally Posted by falko (Post 239167)
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 14th September 2010 16:17

Quote:

Originally Posted by tester321 (Post 239191)
Falko, is it possible then to setup a crontab to rsync the file over at regular intervals?

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

Quote:

Originally Posted by tester321 (Post 239191)
What is the interval that this file is wiped? i.e., is it erased after the actions are performed? Or on a regular schedule?

Yes, it gets erased after the actions are performed.

tester321 15th September 2010 12:13

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

Quote:

Originally Posted by falko (Post 239264)
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.


falko 16th September 2010 14:59

Quote:

Originally Posted by tester321 (Post 239319)
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.

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


All times are GMT +2. The time now is 11:47.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.