# ISPConfig3 - Mirror-Setup Verständnis-Problem



## celocore (6. Juni 2011)

Guten Morgen,

ich habe nach diesem Tutorial einen ISPConfig3-Mirror aufgebaut. Was ich nicht verstehe ist, warum auf dem 2. Server MySQL als Slave an den 1. angebunden wird. durch das Replizieren wird doch sowieso die DB von Server 1 auf Server 2 gespiegelt?


----------



## Till (6. Juni 2011)

Es geht dabeio um die Daten der client datenbanken und nicht um die Daten der ISPConfig Datenbank. ISPconfig repliziert seine Daten selbst, daher haben ja auch die Datenbanken auf master und slave unterschiedliche Namen. Aber wenn Du auch den Inhalt der Webseiten datenbanken (cms systeme etc.) replizieren möchtest, dann muss dies über eine Datenreplikation geschehen.


----------



## celocore (6. Juni 2011)

Hallo Till,

das ist soweit klar, das macht eine Master-Master-Replikation, da sich innodb immer noch nicht mit glusterfs verträgt. Aber damit hat auch MySQL (Oracle) Probleme. Die haben dafpr auch noch keine saubere Lösung.
Wenn ich aber eine Master-Master-Replikation fahre, dann bedeutet das ja, dass beide Server auch ISPConfig-Master oder Slave sein können (nicht gleichzeitig, ist klar ;-)) bzw. die Rollen Master-Slave tauschen können, da ja die ISPConfig-Datenbanken auf beiden Systemen vorhanden sind, oder?


----------



## Till (6. Juni 2011)

> Wenn ich aber eine Master-Master-Replikation fahre, dann bedeutet das ja, dass beide Server auch ISPConfig-Master oder Slave sein können (nicht gleichzeitig, ist klar ;-)) bzw. die Rollen Master-Slave tauschen können, da ja die ISPConfig-Datenbanken auf beiden Systemen vorhanden sind, oder?


Jein. Wenn Du ispconfig als master / slave betreibst, dann kann das nicht getauscht werden. Da ja master und slave unterschiedliche Datenbanknamen haben müssen. Sonst kommt die jobqueue durcheinander, wenn dann würde der erste Server keine jobs mehr abarbeiten, die der 2. Server bearbeitet hat und umgekehrt. Oder mit anderen Worten, wenn Du eine neue webseite anlegen würdest, würde sie per Zufall auf dem ersten oder 2. Server angelegt wedren, aber nicht auf beiden Servern.


----------



## celocore (6. Juni 2011)

Unterschiedliche Datenbanknamen haben Master und Slave ja, aber beide Datenbank(namen) sind doch auf beiden Servern vorhanden.

Normalstatus ist, Server1 -> ISPC-Master, Server -> ISPC-Slave
Durch Gluster und Replikation, sind beide Server datentechnisch auf identischem Stand.

Lege ich jetzt auf Server1 ein Web an, wird das in der MasterDB und der SlaveDB eingetragen mit den Stati. Durch Replikation sind MasterDB und SlaveDB auf beiden Servern gleich.

Wenn ich dann sage Server2 ist Master und Server1 Slave und dann eine Webseite anlege, wird auch das in der MasterDB und SlaveDB eingetragen. Durch Replikation sind MasterDB und SlaveDB auf beiden Servern wieder gleich.

Wechsle ich danach wieder den ISPConfig-Master auf Server1, hat er doch auch wieder den aktuellen Bearbeitungsstatus, so dass nichts durcheinander kommen kann.

Ich grüble da schon das genze Wochenende dran 

<edit>
Oder sind die Datenbanken zwar auf beiden Servern vorhanden, aber nicht wechselseitig nutzbar? Also eigentlich nur ein Nebenprodukt der Replikation der gesamten MySQL-Daten?
</edit>


----------



## Till (6. Juni 2011)

> Oder sind die Datenbanken zwar auf beiden Servern vorhanden, aber nicht wechselseitig nutzbar? Also eigentlich nur ein Nebenprodukt der Replikation der gesamten MySQL-Daten?


Genau so ist es  Du könntest sie an sich bei der mysql master/master Replikation ausklammern. Sie stören aber auch nicht.

Was Du theoretisch machen könntest wäre auf dem Slave Server das Interface and die Master Datenbank zu binden. Also dass Du in der datei /usr/local/ispconfig/interface/lib/config.inc.php auf die auf den slave replizierte master DB connectest während in der Datei /usr/local/ispconfig/server/lib/config.inc.php weiterhin die Daten von der Slave DB stehen. das könnte funktionieren (hab es noch nicht getestet) würde Dir aber spätestens beim nächsten Update auseinanderfallen, da der Updater damit nicht klar kommen wird.


----------



## celocore (6. Juni 2011)

Ja ok, soweit muß es dann nicht gehen ;-) Updatebar sollte schon alles bleiben.
Habe hier am Wochenende mal ein paar Tutorials gelesen, getestet und zusammen gefaßt und etwas mit Mirroring, HA, Load-Balancing und Replikation gespielt. Daher kamen die Fragen auf.


----------

