Dear all, I want o replicate ispconfig database from debian between Master and Slave, will follow http://www.howtoforge.com/mysql_master_master_replication document for setting. I want to know that if the master server configured ispconfig database called dbispconfig1, is it the slave server called the same name (dbispconfig1) for replicate or call other name ??
ISPConfig has its own replication mechanism. Using the tutorial above is not nesceassyr and also incompatible with ispconfig. If you want to setup a slave in ispconfig, then install your server exactly as described in the multiserver tutorials.
If you look at this link http://www.howtoforge.com/forums/showthread.php?t=50068 you will see that he has tried it without success as have I, following the Mirror Server Setup in the new manual. Each time I tried, I started from scratch installing Debian Lenny and all the rest and went step by step. I usually ended up getting corrupted MYSQL table(s).
till - Thanks for reply, i will try this for replicate mysql using ispconfig mechanism. Jtheed - It is true, I followed the step with mirror setting that will cause the mysql table corrupted. I need to do repair the db after the setting.
It seems that the Mirror Setup in the ISPConfig 3 manual that uses GlusterFS, the GlusterFS is the problem that Keith and I are having. It even warns that the Shared MySQL Data may be a problem. So if I want to just replicate ISPConfig, I would setup both servers as per the Perfect Server Setup up to step 6 (Debian Lenny) and then follow the mirror setup but do not included the GlusterFS portion and directories associated withe GlusterFS? If the above is correct, this is what I would like to do. Have ISPConfig replicate itself as above, NOT using GlusterFS at all. Then use the MYSQL Master - Master setup to copy the other databases, then use RSync to copy the web sites and Emails. Is this do able? I can only guess that on the MYSQL Master - Master setup instead of Master - Slave only, is if the Master had to be replaced the databases would update from the slave back to the master, is that correct? Setting it up as described above, if the Master fails, I can just change my router to point to the slave instead of the master. (No fail over switch) When setting up dovecot on the slave, should it have the same mail name as the master? Will the copied 'undelivered' emails using Rsync get to the recipient if it has a different original server name? I ask because I don't quite understand how that works and I have copied (straight copy) undelivered emails from an old server to a new but they were not recognized by the new server and never delivered to the recipient.
You mix things up here. ISPConfig dont use glusterfs for replication. You mix up here the client databases with the ispconfig database. Thats what ispconfig is always doing whith its database.
Till, I am just going by the ISPConfig 3 Manual for Installing a Mirror Setup. I've tried doing it using the GlusterFS method with no luck, so I was wondering if what I have above would work. ISPconfig will take care of itself and MySql Master-Master and Rsync would do the rest. My main concern is about the email getting delivered if the slave takes over.
As I stated in the other thread that I mentioned in the 1st post I made in this thread, Keith and I have tried the glusterfs setup, myself 5 times with no luck. We have asked anyone if they have successfully done this and no one has responded that they have using the glusterfs setup from the manual.
You mix up things again. I talk about glusterfs for /var/vmail and not for mysql. I know quite a few production setups that use glusterfs for /var/www and /var/vmail and they work pretty well, the manual mentions only problems for using glusterfs for /var/lib/mysql which is a completely different thing.
I guess I am not wording it correctly. I tried to setup up a mirror server the way it says to in the ispconfig3 manual. In the ispconfig3 manual there is a setup to also mirror the mysql data as well. This is FROM the IspConfig3 Manual... Create the data directories for the GlusterFS volumes: mkdir /data/ mkdir /data/export-mysql mkdir /data/export-mysql-ns mkdir /data/export-vmail mkdir /data/export-vmail-ns mkdir /data/export-www mkdir /data/export-www-ns Create the GlusterFS server configuration file: # Configuration for the mysql server volume volume posix-mysql type storage/posix option directory /data/export-mysql option background-unlink yes end-volume volume locks-mysql type features/locks option mandatory-locks on subvolumes posix-mysql end-volume volume brick-mysql type performance/io-threads option thread-count 8 subvolumes locks-mysql end-volume Now we create the three client volume files that we need to mount the GlusterFS filesystems volume remote1-mysql type protocol/client option transport-type tcp option remote-host 192.168.0.105 option remote-subvolume brick-mysql option username user-mysql option password 7wQav7ExkFg6eW end-volume volume remote2-mysql type protocol/client option transport-type tcp option remote-host 192.168.0.106 option remote-subvolume brick-mysql option username user-mysql option password 7wQav7ExkFg6eW end-volume volume replicate-mysql type cluster/replicate subvolumes remote1-mysql remote2-mysql end-volume volume cache-mysql type performance/io-cache option cache-size 25MB subvolumes replicate-mysql end-volume So what you are saying, is to use the glusterfs setup but leave out the MYSQL part, right? Use the Master-Master Mysql replication to backup, NOT DBISPCONFIG1 but the other sql datafiles that are associated with the web sites.
