ISPConfig3 bei Cluster Setup (Interfaces, Ordner )

[Till]

Die Datenbank Plugins dienen nur zum anlegen von neuen Kunden Datenbanken. Mit FTP usern haben die nichts zu tun und mit der datenreplikation auch nicht.

Wie kann denn das Interface etas in eine SLAVE Datenbank schreiben von der es nichts weis?

Garnicht. Daher muss etwas an dem setup ganz im argen sein.

 

[rootfuchs]

Ah ok, dann sind die Plugins raus aus der Betrachtung.

Ich hab wie gesagt gerade mal einen neuen FTP-User angelegt über das Interface auf SRV1.
Jetzt stehen alle FTP-User in der Datenbank ispconfig_SRV1. Zumindest nachvollziehbar. Dafür steht jetzt nichts mehr in den beiden andern Datenbanken ispconfig_SRV2 und ispconfig_SRV3. Till bitte sag mir das Ihr die Tabellen der Slaves kurz TRUNCATED bevor Ihr Sie neu einlest *hoff*

Nach 5 Min sind die beiden immer noch leer, daher stelle ich jetzt mal die ISP-Server-Configs auf SRV2 und SRV3 ebenfalls auf die Domain anstelle von localhost um. Geh ich richtig in der Annahme, dass wenn es dann gehen sollte alle 3 Datenbanken die selben Inhalte haben müssten und der jeweilige Cronjob auch Rückwirkend noch die Änderungen übernehmen würde?

 

[Till]

Wieso truncate? Der kopiert nur die Änderungen die neu im sys_datalog als serialisierte objekte stehen und die werden mit mysql replace into in die Datenbanken der slaves geschrieben.

Nach 5 Min sind die beiden immer noch leer, daher stelle ich jetzt mal die ISP-Server-Configs auf SRV2 und SRV3 ebenfalls auf die Domain anstelle von localhost um. Geh ich richtig in der Annahme, dass wenn es dann gehen sollte alle 3 Datenbanken die selben Inhalte haben müssten und er auch Rückwirkend noch die Änderungen übernehmen würde?

dann kann sich wohl der server teil nicht mit dem master verbinden. das kannst Du so debuggen: http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/

 

[rootfuchs]

Wieso truncate? Der kopiert nur die Änderungen die neu im sys_datalog als serialisierte objekte stehen und die werden mit mysql replace into in die Datenbanken der slaves geschrieben.

Naja ich hatte gehofft das mit dem INSERT in die Master-DB die Slave-Db Tabellen geleert würden und sie neu zu befüllen; ich also nur kurz warten muss

as kannst Du so debuggen

Wunderbar danke.

 

[Till]

Naja ich hatte gehofft das mit dem INSERT in die Master-DB die Slave-Db Tabellen geleert würden und sie neu zu befüllen; ich also nur kurz warten muss

Wenn dem so wäre dann wäre es ja wohl sehr schlecht skalierbar

 

[rootfuchs]

Zugegeben, aber es wäre soo praktisch gewesen, weil es dann an mir liegen würde ^^

Also die Server.sh funktioniert auf beiden Servern!

• Es war eine Fehlannahme meinerseits davon aus zu gehen, dass die ispconfig-Datenbanken durch den Galera repliziert würden. Da ISP MyISAM als Tabellenformat nutzt, und Galera nur InnoDB repliziert, hat der damit gar nichts zu tun, sondern die Erwartung war falsch.
• wenn ich die server.sh jeweils manuell starte, läuft alles nach Handbuch.

Die Frage ist also warum der cronjob dafür nicht das tut was er soll. Ich kommentiere den Cronjob jetzt auf einem der Server nochmal ein. Vllt. löst das das Problem ja schon wenn die Crontab man neu installiert wurde. Aber gerade eben war das Fehlerbild folgendermaßen:

• SRV1 führt wie gewohnt Änderungen direkt in der Master-DB aus.
• SRV2 mit deaktivierten Cronjob. Repliziert die Änderungen des Masters, sofern die server.sh manuell gestartet wird.
• SRV3 mit aktivierten Cronjob. Tut auch nach 5 Minuten gar nichts. server.sh läuft aber Normal nach manuellem Start.

Immerhin. Ich dachte schon ich hätte ein schwarzes Loch konstruiert und das sei mir aufgrund der Zeitverzerrung noch nicht aufgefallen.

PS: Die Verwirrung bezüglich der Tabelleninhalte stammte auch daher, das Galera durchaus die CREATE Anweisungen der ispconfig-Datenbaneken repliziert. Nur eben nicht die Daten sobald Galera merkt das es sich um MyISMA Tabellen handelt. Daher sind auch alle 3 Datenbanken der Server erstmal überall sichtbar, zeigen aber nicht das Verhalten, das dadruch geweckt wird. Muss man sich auch erst mal merken.

 

[Till]

srv2: Cronjob problem.
srv3: Schau mal nach ob für den im master (interface) ausgewählt ist dass er ein mirror von srv1 ist.

und das mit dem nicht replizieren in galera erklärt auch warum die interfaces nicht gingen. Du musst also die config so ändern dass sie sich auf die master db remote verbinden oder Du änderst den ispconfig tabellentyp überall zu innodb, ist aber ein wenig blöd mit updates da du dann ggf. die sql patch files checken müsstest und dort auch innodb setzen, bevor du das update installierst.

 

[rootfuchs]

Schau mal nach ob für den im master (interface) ausgewählt ist dass er ein mirror von srv1 ist.

Ist gegeben. Du hast mich auch glaube ich missverstanden. Ich habe die Änderungen in der SRV1 gemacht und den Cronjob nach der Debugginganleitung nur auf dem SRV2 deaktiviert und die server.sh manuell gestartet. Der SRV3 habe ich erst einmal unangetastet weiter laufen lassen um zu sehen ob der cronjob dort irgendwann anspringt, was er nicht tat.

Also ist es zumindest auf allen Slave-Servern ein Cronjob Problem. Ich hab den Cronjob auf dem SRV2 jetzt wieder einkommentiert und seitdem tut er seinen dienst wie erwünscht. Offenbar akzeptiert Debian 7 nach der Erstinstallation als Slave die Crontab nicht? Erst ein manuelles öffnen und speichern installiert die crontab wirklich.

und das mit dem nicht replizieren in galera erklärt auch warum die interfaces nicht gingen.

Jepp. Es ist halt maximal verwirrend die Datenbanken und Tabellen von überall zu sehen, aber nicht deren Inhalte.

oder Du änderst den ispconfig tabellentyp überall zu innodb, ist aber ein wenig blöd mit updates

Ja weswegen ich genau das nicht tun werde
Aber ich wollte das eh noch fragen.
Angemommen ich würde das tun - offenbar gehst Du ja davon aus, das dass keine Auswirkungen im laufenden Betrieb hätte - könnte ich doch theorethisch zumindest alle 3 Server auf einer dbispconfig laufen lassen. 3x standard Install auf einen MariaDB-Galera-Cluster als Datenbank
und jeweils die Configs der ISPC-Interfaces und der ISPC-Server anpassen. Theoretisch zumindest. Oder mach ich nen Denkfehler?

 

[Till]

Angemommen ich würde das tun - offenbar gehst Du ja davon aus, das dass keine Auswirkungen im laufenden Betrieb hätte - könnte ich doch theorethisch zumindest alle 3 Server auf einer dbispconfig laufen lassen. 3x standard Install auf einen MariaDB-Galera-Cluster als Datenbank
und jeweils die Configs der ISPC-Interfaces und der ISPC-Server anpassen. Theoretisch zumindest. Oder mach ich nen Denkfehler?

Dann verlierst Du die Ausfallsicherheit da ja alles nur noch auf den master connected und Du verlierst die Skalierbarkeit da sich alle Dienste wie postfix etc. auf die DB connecten müssten und die wären dann auch down wenn Dein master ausfällt und es kann zu Problemen kommen dass Daten nicht atomar sind, also dass aus Sicht des slaves Daten "aus der Zukunft" in seiner DB stehen bevor er sie bearbeitet hat was alle möglichen negativen Seiteneffekte haben kann.

 

[rootfuchs]

Hallo Till,

hat leider ein paar Tage gedauert bei mir. Danke nochmal für Deine Unterstützung. Ohne Deine Mithilfe hätte ich mir sicher noch ein paar Tage den Wolf gesucht ^^

Dann verlierst Du die Ausfallsicherheit da ja alles nur noch auf den master connected

Ich glaube in dem Fall nicht.
Vorrausgesetzt ISP3 liefe auf InnoDB-Tabellen und würde repliziert, könnte jeder Server auf seine lokale Version der dbispconfig zugreifen und im Falle eines Ausfalles eines der Server, würden die restlichen einfach weiter machen. Galera ist ja eine multi Master Replikation.

Aber die Killer sind eh nicht weit:

1.)
Wie Du schon gesagt hast:

es kann zu Problemen kommen dass Daten nicht atomar sind, also dass aus Sicht des slaves Daten "aus der Zukunft" in seiner DB stehen bevor er sie bearbeitet hat was alle möglichen negativen Seiteneffekte haben kann.

2.)
Hinzu kommt das Maria-Galera nur Transaktionen akzeptiert aber LOCKs der Tabellen ignoriert. Was dann zu einigen inkonsistenzen führen würde denke ich.

3.) Wie Du ja gesagt hast ist allein der Verlust der Updatefähigkeit schon ein K.O-Kriterium für solche experimente.