ISPConfig3 Cluster Setup

[mattula]

Hallo Till oder wer auch immer das liest,

ich bin mal wieder am Aufsetzen einer ISPConfig Installation,
diesmal solls redundant werden und die Last verteilen.

Aber mir gelingt bislang nicht das perfekte Setup (trotz der diversen HowTos).
Aktuelle PDF Doku liegt auch vor.

Zum Setup:

Vorne stehen 2 Loadbalancer.
Hinten dran folgen 2 Webserver (mit ISPConfig)
und da hinten dran 2 DB Server (mit ISPConfig)
Nebendran steht ein ISPConfig-Server, der nur die Controlpanel
Funktion übernimmt und die vorgenannten Web- und DB-Server konfigurieren soll.

Das prinzipielle Setup habe ich denke ich korrekt durch exerziert..

Auf allen 5 Servern ist ISPConfig installiert, mit folgendem Setup:

• ispcfg: ISPConfig Controlpanel webcl1: web + ftp server, joined to ispcfg
• webcl1: web + ftp server, joined to ispcfg
• webcl2: web + ftp server, joined to ispcfg, is mirror of webcl1
• dbcl1: db server, joined to ispcfg
• dbcl2: db server, joined to ispcfg, is mirror of dbcl1

Im Controlpanel sehe ich alle Server. Soweit so gut.

Die beiden DB Server sind nach HowTo mit Master/Master Replikation aufgesetzt. Funktioniert auch erstmal soweit.

Nun kommen die Probleme:

Ich habe mal probeweise den dbcl1 runter gefahren.
Das Controlpanel bleibt grün. Nirgends ist zu sehen, dass ein Server fehlt.
Und er ist definitiv ausgeschaltet.

Ok, ich lasse ihn aus und lege im Controlpanel eine neue Test-DB an.
Dort wird mir nur dbcl1 zur Auswahl angezeigt, aber DB lässt sich per GUI ohne Fehler anlegen.

Ich schaue auf dbcl2: und siehe da, die Test-DB ist da. OK

Nachwievor ist im Controlpanel alles grün. Wenn ich's nicht besser wüsste, würde ich behaupten, dass alle Server laufen, aber dbcl1 ist definitiv aus.

Weiter geht's: Worst Case, ich schalte dbcl2 auch noch ab.
Control Panel bleibt grün.

Ich schalte dbcl1 wieder ein. Wohlgemerkt, den, der zum Zeitpunkt des Anlegens der Test-DB aus war.
Auch dort exitiert nun auf wunderbare Weise die Test-DB.

Jetzt starte ich dbcl2. Und nun das Dilemma: dbcl2 würde gerne auf dbcl1 die Test-DB anlegen, da er das bis dato ja noch nicht konnnte.
Dieses Begehr schlägt jedoch fehl, da die Test-DB schon existiert, weil sie nach Einschalten vom dbcl1 vorhin durchs Controlpanel angelegt wurde.

Meine Frage: ist das so gedacht?

Ist mein grundsätzliches Setup falsch? Wobei das DB setup und die ISPConfig Konfiguration dazu ja in
der Doku im Prinzip genau so beschrieben wird, nur dass dort alle Dienste auf 2 Servern laufen.

Und warum bleibt alles grün, wen nein Server aus ist?

Bessere Vorschläge, wie ich gewünschtes Setup (2 Webserver, 2 DB Server) realisieren kann?
Muss ich in dem Fall die DB Server als HB Cluster mit DRBD aufsetzen und
dem ISPConfig quasi als 1 Server unterjubeln, wenn ich auf DB Ebene die Redundanz benötige?

Für die Webserver sollte mein Setup ja passen, wenn ich die Datenverzeichnisse noch z.B. mit Unison synce.

Aber beim DB Setup hab ich den Eindruck, dass ISPConfig und Replikation sich beissen.
Das mag gut gehen, solange alle Server laufen, oder nur geregelt in der richtigen Reihenfolge ausfallen.

Beste Grüße,
Matthias

 

[Till]

Dass die DB nochmal angelegt werden soll ist an sich kein problem. Du kannst aber auch den 2. DB Server von ISPConfig abtrennen und nur über master/master Replikation laufen lassen.

Du kannst ja mal einen Feature request im Bugtracker posten dass man für solche Fälle noch einen Test ob die DB bereits existiert einbaut, damit ispconfig nicht versucht sie neu anzulegen.

 

[mattula]

Dass die DB nochmal angelegt werden soll ist an sich kein problem.

Im MySQL Master/Master Setup ist es ein Problem, da die DB ja zuvor schon auf dem anderen Node angelegt wurde und dort auf die Replikation wartet.
Wenn ISPConfig dann zuvorkommt ist die Replikation unterbochen.

Ausserdem: was ist, wenn die DB schon Tabellen enthielt? Dann legt ISPConfig auf dem anderen Node trotzdem nur eine leere DB an, was für noch mehr Verwirrung oder Inkonsistenz sorgt.

Du kannst aber auch den 2. DB Server von ISPConfig abtrennen und nur über master/master Replikation laufen lassen.

Na ja. Dann habe ich nicht viel gewonnnen, ausser einer Art Backup / Cold Standby Server. Ich möchte ja Redundanz. Bei Ausfall eines Nodes sollte ein autom. Failover stattfinden.
Das spricht dann in dem Fall doch eher für ein Active/Standby Heartbeat/DRBD CLuster, der über 1 gemeinsame IP angesprochen wird.

Oder Galera Replication. Das hört sich auch stabil an. Aber diese MySQL eigene Master/Master Replikation ist a) zu fehleranfällig und kann b) keine Konflikte lösen.

Du kannst ja mal einen Feature request im Bugtracker posten dass man für solche Fälle noch einen Test ob die DB bereits existiert einbaut, damit ispconfig nicht versucht sie neu anzulegen.

Auch das hilft in o.g. Fall nicht. Die auf dem einen Node angelegte DB konnte ja noch nicht auf den "toten" Node repliziert werden. D.h. wenn der tote Node zuerst wieder hoch kommt, existiert die DB dort nicht und ISPConfig legt sie an. Kommt anschl. der 2. Node hoch, scheitert die in der Queue stehende Replikation.

Davon abgesehen sollte bedacht werden, dass mit der "statement based replication" nicht alles repliziert werden kann (z.B. stored procedures).
Wer unbedingt MySQL Replikation verwenden will, sollte "row based replication" konfigurieren. Das kann allerdings zu unangenehm grossen Binlogs führen, da nicht mehr das einzelne SQL Statement, sondern jegliche Datenänderung geloggt wird.

Matthias

 

[Till]

Das sind bekannte Probleme die in der nicht wirklich guten Art der Replikation von mysql in master/master setups liegt, da können wir von ISPconfig nicht viel daran ändern. Du kannst dann nur den 2. DB Server aus ispconfig raus nehmen und nur über master/master mysql Replikation laufen lassen, dann sind Deine Datenbanken aus Sicht der Webseiten hoch verfügbar, sollte aber mal der node der an ISPConfig angebunden ist ausfallen würden alle Datenbank Änderungen für neue User und DB's so lange in der ispconfig queue liegen bis er wieder online ist.

 

[mattula]

Das sind bekannte Probleme die in der nicht wirklich guten Art der Replikation von mysql in master/master setups liegt, da können wir von ISPconfig nicht viel daran ändern. Du kannst dann nur den 2. DB Server aus ispconfig raus nehmen und nur über master/master mysql Replikation laufen lassen, dann sind Deine Datenbanken aus Sicht der Webseiten hoch verfügbar, sollte aber mal der node der an ISPConfig angebunden ist ausfallen würden alle Datenbank Änderungen für neue User und DB's so lange in der ispconfig queue liegen bis er wieder online ist.

Ok, danke. Aber ich werde dann lieber die klassische Variante mit Heartbeat und DRBD nehmen. Damit ist dann die DB für alle Beteiligten hoch verfügbar. Das evtl. nicht ganz so performante DRBD wird in dem Fall mit viel RAM ausgeglichen.

In eurer aktuellen PDF Doku wird das Mysql Master/Master Setup so beschrieben, wie ich es gemacht habe. Ich finde da gehört ein Hinweis rein, dass das Setup nicht unproblematisch ist.

Viele Grüße,
Matthias

 

[florian030]

Hallo Till,

könnte man nicht einfach in mysql_clientdb_plugin.inc.php vor dem CREATE DATABASE einen Check setzen, ob die DB vorhanden ist?

Etwas wie

if (!$link->query('USE DATABASE '.$link->escape_string($data['new']['database_name']))) {
  //* Create the new database
  if ($link->query('CREATE DATABASE '.$link->escape_string($data['new']['database_name']).$query_charset_table)) {
    $app->log('Created MySQL database: '.$data['new']['database_name'],LOGLEVEL_DEBUG);
  } else {
    $app->log('Unable to create the database: '.$link->error,LOGLEVEL_WARNING);
  }
} else {
  $app->log('Database already exists: '.$link->error,LOGLEVEL_WARNING);
}

 

[Till]

Das sollten wir auf jeden Fall einbauen wie ich im anderen Thread gesagt hatte, es behebt leider nur einen teil des problems, denn Du kannst so nur testen ob es die DB lokal schon gibt, es ist aber nicht ohne weiteres möglich herauszufinden ob es die DB schon in einem anderen mysql node gibt, der zur Zeit offline ist und ideses aber später versuchen würde auf den loklen node zu replizieren sobald er wieder online geht.

Die einzige Möglichkeit um die 2. Fehlervariante abzufangen wäre folgende vorgehensweise:

1) Bestimme alle Server die zusammen mit dem lokalen Server in einer mysql Replication und als mirrors in ispconfig verbunden sind.
2) Hole Dir den Wert der "updated" spalte aller dieser server und finde heraus on´b einer dieser Werte > dem aktuellen DB anlegen jon´b ist, denn wenn das der Fall ist muss ein anderer DB Server diese Aktion bereits ausgeführt haben.

Das Problem was bleibt ist dass die Server die Aktion nahezu gleichzeitig ausführen werden wenn sie alle über NTP die gleiche Zeit haben, es kann also sein dass der Status um ein paar Millisekunden veraltet ist und die DB so trotzden doppelt angelegt wird.

 

[florian030]

Man kann im Zweifel auch über

slave_skip_errors=1007

in der my.cnf das Problem umgehen. Dann läuft die Replikation auch weiter, wenn eine bereits existierende DB angelegt werden soll.
Und mit skip-error 1008 für die umgekehrte Richtung: eine nicht (mehr) existierende DB soll gelöscht werden.

 

[mattula]

Das sollten wir auf jeden Fall einbauen wie ich im anderen Thread gesagt hatte, es behebt leider nur einen teil des problems, denn Du kannst so nur testen ob es die DB lokal schon gibt, es ist aber nicht ohne weiteres möglich herauszufinden ob es die DB schon in einem anderen mysql node gibt, der zur Zeit offline ist und ideses aber später versuchen würde auf den loklen node zu replizieren sobald er wieder online geht.

Nur wenn auch das 2. Problem gelöst wird macht es meines Erachtens Sinn den o.g. Check einzubauen.

Die einzige Möglichkeit um die 2. Fehlervariante abzufangen wäre folgende vorgehensweise:

1) Bestimme alle Server die zusammen mit dem lokalen Server in einer mysql Replication und als mirrors in ispconfig verbunden sind.
2) Hole Dir den Wert der "updated" spalte aller dieser server und finde heraus on´b einer dieser Werte > dem aktuellen DB anlegen jon´b ist, denn wenn das der Fall ist muss ein anderer DB Server diese Aktion bereits ausgeführt haben.

Das Problem was bleibt ist dass die Server die Aktion nahezu gleichzeitig ausführen werden wenn sie alle über NTP die gleiche Zeit haben, es kann also sein dass der Status um ein paar Millisekunden veraltet ist und die DB so trotzden doppelt angelegt wird.

Zwei parallele Lösungsansätze dazu:

1. Beim Holen der "updated" Spalte einen WRITE LOCK auf die Tabelle setzen, bzw. und/oder beim Ausführen des Tabelle anlegens einen WRITE LOCK und einen Flag setzen, der signalisiert, dass die DB angelegt ist.

2. Den minütlichen Cron Job /usr/local/ispconfig/server/server.sh per Zufallsgenerator um bis zu 15 Sekunden verzögert ausführen.
Dazu z.B. diesen Code Schnippsel in's server.sh vor den Aufruf vom server.php einfügen:

# Generate random sleep time <= $RUNSLEEP in seconds
RUNSLEEP=15
SLEEP=$(($RANDOM % $RUNSLEEP))
sleep $SLEEP

 

[mattula]

Man kann im Zweifel auch über

slave_skip_errors=1007

in der my.cnf das Problem umgehen. Dann läuft die Replikation auch weiter, wenn eine bereits existierende DB angelegt werden soll.
Und mit skip-error 1008 für die umgekehrte Richtung: eine nicht (mehr) existierende DB soll gelöscht werden.

Interessante Idee. Schon getestet?

Funktioniert das auch mit row-based replication?

Aber irgendwie kann ich mich trotzdem nicht ganz mit der Idee anfreunden. Das ist doch auch nur ein Workaround.

Ich denke, die stabilste Lösung ist entweder der Heartbeat/DRBD Active/Passive Cluster für die MySQL DB oder der neue Galera Cluster mit wahlweise MySQl oder MariaDB. Wobei ich bei MariaDB + Galera am ehesten die Zukunft sehe.

 

[florian030]

Ja sicher habe ich das getestet. Gerade gestern zusammen mit 1008 auf einem Slave, der an einem Master-Master hängt. Funktioniert bis jetzt ohne Probleme.

1007 verwende ich im Mirror-Setup, wenn zwei Server auch als mysql-replikation laufen.
1008 habe ich gestern eher durch Zufall entdeckt. Macht m.E. aber auch Sinn. Allerdings hatte ich bis jetzt noch keine Probleme mit "drop database". Dürfte aber daran liegen, dass "create database" öfter vorkommt.

RBR habe ich nicht explizit getestet. Ich wüsste ad hoc aber nicht, warum das nicht gehen sollte.

Das ist m.E. kein workaround, sondern die einzige Möglichkeit, das ganze auf mysql-Ebene zu realisieren. Auch ohne ISPConfig kann es eine mysql-Replikation zerlegen, wenn bei einem Splitbrain auf verschiedenen Master-Servern die gleiche DB angelegt wird.

Und DRBD würde ich nicht für mysql verwenden.

 

[mattula]

RBR habe ich nicht explizit getestet. Ich wüsste ad hoc aber nicht, warum das nicht gehen sollte.

Bei einem einfachen DROP DATABASE sollte es wohl kein Problem sein.
Aber ich würde es vorher ausgiebig testen, wenn ich damit produktiv gehen wollte.

Das ist m.E. kein workaround, sondern die einzige Möglichkeit, das ganze auf mysql-Ebene zu realisieren. Auch ohne ISPConfig kann es eine mysql-Replikation zerlegen, wenn bei einem Splitbrain auf verschiedenen Master-Servern die gleiche DB angelegt wird.

Sorry, ich hab mich vielleicht nicht klar ausgedrückt: Die Idee an sich mit dem ignore_errors finde ich nicht schlecht. Aber wie du selbst schon andeutest - die Master/Master Replikations-Technik by MySQl ist ein fragiles Konstrukt. Zumal du nicht einmal ein Split-Brain benötigst, um es zu stören Das zeitgleiche Schreiben auf 2 Nodes kann ja schon ausreichen, da die Replikation asynchron ist.

Als Workaround sehe ich es in Verbindung mit ISPConfig. Das Ganze würde ich so höchstens einsetzen, wenn Kunde = DB-Admin, d.h. wenn nur ich (oder meine Firma) ISPConfig nutze, um meine eigenen Seiten und DBs damit zu betreiben. Dann weiss ich im Zweifel, wo was schief läuft, bzw. kann festlegen welche SQL Statements erlaubt sind und welche nicht.

Aber die Vorstellung 100 Kunden auf so einem Setup arbeiten zu lassen, ist mir nicht geheuer. Wie erkläre ich 99 Kunden, dass es 1 Kunde geschafft hat die DB Replikation zu stören? Und wie lange benötige ich, um herauszufinden welcher der 100 Kunden die DB so beschreibt, dass es dabei die Replikation aus dem Trab bringt?

Also für ein Multikunden-Setup muss das DB Konstrukt robuster und fehlertoleranter sein. Und da fällt mir halt nur entweder ein Heartbeat/DRBD Cluster ein oder die neue synchrone Multi-Master-Replikation mit Hilfe der Galera Library. Letzteres ist mir grade noch zu neu für den produktiven Einsatz, aber ich finde es eine hochinteressante Lösung.

Und DRBD würde ich nicht für mysql verwenden.

Warum? Perfomance? Mit genügend RAM lässt sich die MySQL Config so tunen, dass die Platten IO eine untergeordnete Rolle spielt.

Grüße,
Matthias

 

[florian030]

Hallo Matthias,

Das zeitgleiche Schreiben auf 2 Nodes kann ja schon ausreichen, da die Replikation asynchron ist.

Und warum sollte das zeitgleiche Schreiben die Replikation aus dem Tritt bringen?

Aber die Vorstellung 100 Kunden auf so einem Setup arbeiten zu lassen, ist mir nicht geheuer. Wie erkläre ich 99 Kunden, dass es 1 Kunde geschafft hat die DB Replikation zu stören? Und wie lange benötige ich, um herauszufinden welcher der 100 Kunden die DB so beschreibt, dass es dabei die Replikation aus dem Trab bringt?

M.E. tritt das Problem nur bei einem CREATE DATABASE auf; ob sich ein DROP DATABASE in der Praxis auch so auswirkt, habe ich nicht getestet. Wenn ich Error 1007 überspringe (und das mache ich seit Jahren so), dann hat ISPConfig bzw. MySQL master/master damit keine Probleme. Da ist es auch völlig egal, wie viele Kunden sich auf dem DB-Server tunneln. Das einzige Problem (jedenfalls bei mir) ist das Anlegen einer DB, da dies auf jedem Node ausgeführt wird.

Galera Library. Letzteres ist mir grade noch zu neu für den produktiven Einsatz, aber ich finde es eine hochinteressante Lösung.

Definitiv sehr interessant.

Warum? Perfomance? Mit genügend RAM lässt sich die MySQL Config so tunen, dass die Platten IO eine untergeordnete Rolle spielt.

Nö, DRBD an sich ist schon recht performant - jedenfalls solange man nicht mal eben schnell ein Website mit ein paar GB löschen will.

Damit eine Master-Master-Replikation über DRBD funktioniert, muss das ganze als Dual-Primary laufen. Schön, im Prinzip kein Problem, ich bin dann aber auf zwei Nodes limitiert (mal sehen, was DRBD 9 bringen wird). Wenn nun ein Node - warum auch immer - zum Secondary wird, ist es mit der DB-Replikation vorbei. Gleiches passiert auch bei einem Splitbrain.
Bei DRBD kann man sich dann entscheiden, von welchem Node die Daten übernommen werden soll, bei MySQL kannst Du mit dem Percona Toolkit die Änderungen abgleichen bzw. läuft die Replikation nach einem Re-Connect sauber weiter (vom Slavelag am Anfang mal abgesehen).
Wenn Du bspw. Indexes ändern willst, geht das mit einer Replikation über DRBD nicht; auf MySQL-Ebene ist das hingegen kein Problem.
Und was passiert eigentlich, wenn das FileSystem auf einer DRBD-Resource die Hufe reißt?

Ich bin einfach grundsätzlich kein Freund von eine MySQL-Replikation auf FileSystem-Ebene. Zumal die von MySQL mitgebrachte Lösung problemlos funktioniert. Ich kann so auch einen Slave an einen der Master hängen und dort die DB mit add-lock-tables dumpen ohne dass sich auch nur irgendein Master daran stört.

 

[Brainfood]

Einen guten Überblick der Replikationsproblematik verschafft:

MySQL :: MySQL 5.1 Referenzhandbuch :: 6.1 Einführung in die Replikation

Interessant sind auch die zusammenhängenden 4 Blogeinträge von:

Aus dem Rechenzentrum» Blogarchiv » MySQL-Backups, aber wie?


In einer meiner derzeitigen Produktivumgebungen laufen:

1x ISPConfig3 - Config-Server (3.0.4x)
2x ISPConfig3 - Web-Server (3.0.4x)
2x ISPConfig3 - DB-Server (3.0.4x)
2x ISPConfig3 - Mail-Server (3.0.4x)
2x ISPConfig3 - DNS-Server (3.0.4x)

Synchronisierung der www / mail und configs erfolgt per rsync.
die Backup-Kisten laufen im ISPConfig3 Slave-Modus, der sek. DB-Srv zieht sich einmal täglich ein mysqldump

Die Probleme von Inkonsistenten Informationen wie unterschiedlichen Apache SSL Cert. Key gen/anzeigen im ISPConfig hatte ich einmal als Bugreport betreffend Vers. 3.0.4x gemeldet … nun wollte ich demnächst die MySQL Replikation produktiv einsetzen.

Aufgesetzt sind derzeit 3 Kisten mit ISPConfig3 3.0.5.1 (Srv1 (MySQL Master) / Srv2 (MySQL Master Rep.) + Srv3 (ISPConfig3 Slave)

Das ganze hier von euch klingt ja nicht sonderlich vertrauenserweckend, wie macht es denn Falko bei seinem Timme-Hosting?

Laufen da die ISPConfigs in Live Migration fähigen/Failover_Cluster Hypervisor Umgebungen?

DRBD + Xen / VMware VSphere Zeugs etc?


Jedenfalls … ich fasse noch einmal kurz zusammen:

1. Verfügbarkeitsanzeige (GRÜN/ROT Status) funktioniert derzeit nicht richtig zu ISPConfig MySQL-Servern?
2. ISPConfig versucht erneut auf einem zuvor ausgefallenem und wieder verfügbarem MySQL (Master Rep.) Nodes (CREATE/DROP DATABASE) durchzuführen, was zu einem defekten Master/Master Replikationsstatus führt?
3. ISPConfig3 Cluster HowTo beinhaltet anweisungsbasierte Replikation (Statement-Based Replication) und nicht datensatzbasierte Replikation (Row-Based Replication) was nicht zwangsläufig zu einem vollständig konsistenten Status führt?
4. manuelle regelmäßige Prüfung der Konsistenz zwischen den 2 MySQL Instanzen?


Zu Punk1. kann ich bestätigen, wenn ich die DB_Slave Kiste runterfahre, wird sie weiterhin im ISPConfig (3.0.4x) des Main Control Panel Servers (GRÜN) angezeigt.
2. Lösung: slave_skip_errors=1007 / 1008 auf beiden Master MySQLs einstellen?
3. MySQL Config für Row-Based Replication anpassen? (benötigt wohl ./configure --with-row-based-replication) ?
4. Lösung: mit Hilfe des Percona Tools "pt-table-checksum" ?



Ist der Einsatz von MySQL Master/Master Replikation eigentlich ein gängiges Verfahren oder wird dies eher Stiefmütterlich behandelt um im Enterprise Segment MySQL Cluster Produkte zu pushen?

 

[florian030]

Synchronisierung der www / mail und configs erfolgt per rsync.

Wenn Dir das zeitnah genug ist.... mir persönlich ist da DRBD doch lieber. Kommt aber natürlich darauf an, ob Du Server 2 als Backup nimmst oder darüber auch Zugriffe laufen.

Die Probleme von Inkonsistenten Informationen wie unterschiedlichen Apache SSL Cert. Key gen/anzeigen im ISPConfig hatte ich einmal als Bugreport betreffend Vers. 3.0.4x gemeldet … nun wollte ich demnächst die MySQL Replikation produktiv einsetzen.

Ich habe überhaupt kein Problem mit SSL-Keys und Apache? Ich habe hier zwei Server für web und mail. Die Daten werden über DRBD/OCFS2 synchron gehalten, die Datenbanken über einer master-master-Replikation. Im Prinzip würde hier auch master-slave reichen. Dann müsste aber der (mysql)Slave-Server mysql nicht über localhost, sondern über Server 1 ansprechen. Du musst nur jedem Kunden erklären, dass es nicht localhost, sondern bspw. mysql.meinedomain.com ist.

2. ISPConfig versucht erneut auf einem zuvor ausgefallenem und wieder verfügbarem MySQL (Master Rep.) Nodes (CREATE/DROP DATABASE) durchzuführen, was zu einem defekten Master/Master Replikationsstatus führt?

Nein. ISPConfig legt auf jedem Node (ob nun ausgefallen oder nicht) eine neue Datenbank an. Das kann aber zu Problemen führen, wenn die DB aufgrund der MySQL-Replikation bereits vorhanden ist.

Daher skip 1007

4. manuelle regelmäßige Prüfung der Konsistenz zwischen den 2 MySQL Instanzen?

Die Konsistenz der einzelnen DB-Server sollte man grundsätzlich periodisch prüfen. Das hat aber aber nichts mit ISPConfig zu tun.

2. Lösung: slave_skip_errors=1007 / 1008 auf beiden Master MySQLs einstellen?

Das umgeht zumindest das Problem einer abgebrochenen Replikation, wenn eine bereits existente DB angelegt werden soll. Analog auch für DROP DATABASE.

Ist der Einsatz von MySQL Master/Master Replikation eigentlich ein gängiges Verfahren oder wird dies eher Stiefmütterlich behandelt um im Enterprise Segment MySQL Cluster Produkte zu pushen?

Ich fahre ganz problemlos mit Master-Master(-Slave). Für ein MySQL-Cluster brauchst Du in jedem Fall einen weiteren Server. Da DRBD im Moment aber nur dual-primary kann, reicht mir das eh.

Anyway, ISPConfig mit MySQL-Master-Master bringt keine Probleme mit sich, so lange Error 1007 und 1008 in der my.cnf übersprungen werden.

 

[Brainfood]

Die Inhaltsänderungen halten sich auf den Webservern in Grenzen, Lastenverteilung wird durch simples hinzufügen von mehreren DNS Einträgen realisiert, so rotieren dann stündlich die Clients per Round-Robin einmal durch die IPv4/IPv6 Adressen durch …

Die zweiten DB/Mail & DNS Server sind reine Backup-Kisten.



So Pass auf … wenn auch Offtopic:

1x ISPConfig3 Server als CP
1x ISPConfig3 Server als Web (1)
1x ISPConfig3 Server als Web (2) (Slave Modus)
ISPConfig 3.0.4.x

Erstellt man sich ein SSL Zertifikat für seine Seite, generiert ISPConfig unterschiedliche Apache SSL Keys, da ich zwar meinen Root-CA Anbieter zum unterzeichnen von Requests aber nicht zur Key_Generierung verwende, habe ich einfach den Cert.Request aus dem ISPConfig rauskopiert, von der Root-CA unterschreiben lassen und wieder per ISPConfig3 Webinterface Importiert … mit dem Ergebnis:

Web1 (lief) jedoch Web2 NICHT mehr …

(chain/sub.ca.crt wurden manuell eingebunden)

Zur Behebung des Problems habe ich dann die:

/var/www/domain.tld/ssl/www.domain.tld.key
/var/www/domain.tld/ssl/www.domain.tld.csr
/var/www/domain.tld/ssl/www.domain.tld.crt

vom funktionsfähigen Server auf den defekten kopiert / apache restart und alles war in Butter.

Bis zu dem Zeitpunkt, wo ich bei einer nächtlichen Administration paar Certs. importierte und dann auf einmal Web1 nicht mehr lief, jedoch Web2!

Keine Ahnung ob es einfach nur eine ungünstige Konstellation aus Browser + Cache und ISPConfig3 war oder ISPConfig selbst, wenn es als CP auf einem separaten Server läuft ... er sich dann nicht zwangsläufig immer die Zertifikatdaten vom (Main) sondern auch mal vom Slave-Server holt.

Fakt war, die SSL Requests waren von Web2 und bevor ich die Keys aus Web2 sichern konnte, hatte schon crontab / rsync drüber geballert …

Neben Zeit ging auch bares Geld flöten, da die SSL Revokes Geld kosteten ...



Zurück zu MySQL:

Ich werde jetzt mal eine Testumgebung aufsetzen und ERROR 1007 / 1008 mit in den MySQL Configs berücksichtigen, nach paar Härtetests werd ich noch einmal mein Senf abgeben ...

---
ISPConfig3 - Mini HowTos

 

[mattula]

Hallo Matthias,
Und warum sollte das zeitgleiche Schreiben die Replikation aus dem Tritt bringen?

Wenn z.B. zweimal das gleiche Staement abgesetzt wird und es aufgrund von Latenz bei der Replikation auf beiden Nodes zur Anwendung kommt.

M.E. tritt das Problem nur bei einem CREATE DATABASE auf; ...

Schreiben in eine Tabelle die nicht existiert, usw. unterbricht die Replikation doch genauso.

Damit eine Master-Master-Replikation über DRBD funktioniert, muss das ganze als Dual-Primary laufen.
...

Ouhh, Missverständnis, das wollte ich gar nicht. Ich setze in dem Fall einen Active/Passive Cluster ein. /var/lib/mysql liegt auf DRBD und der MySQL Dienst mitsamt Shared IP schwenkt mit dem Cluster. Damit habe ich zwar keine Lastverteilung, aber dafür Hochverfügbarkeit, was im aktuellen Projekt wichtiger ist.

Ich bin einfach grundsätzlich kein Freund von eine MySQL-Replikation auf FileSystem-Ebene. Zumal die von MySQL mitgebrachte Lösung problemlos funktioniert. Ich kann so auch einen Slave an einen der Master hängen und dort die DB mit add-lock-tables dumpen ohne dass sich auch nur irgendein Master daran stört.

Klar, es gibt durchaus Vorteile, der MySQLReplikation, die auf der Hand liegen. Vor allem die Idee mit dem Slave, der nur zum Dumpen dient. Das finde ich richtig gut. Und wenn da mal die Replikation nicht tut, dann ist wenigstens "nur" das Backup Müll, aber nicht die Produktiv Umgebung betroffen.

Aber wir haben bei uns schonmal schlechte Erfahrung mit der Mysql-Replikation gemacht, vor allem in Verbindung mit irgendwelchen Stored Procedures und Variablen Deklarationen, die nicht repliziert wurden.
Das mag mittlerweile mit RBR besser funktionieren, aber dafür nimmt man dann ggfs. riesige Binlogs in Kauf.

Nimms mir nicht übel, aber ich werd mich mit dem jetzigen Replikations Mechanismus als MAster/Master Setup nicht mehr anfreunden und stattdessen als nächstes Projekt irgendwann mal die Galera Geschichte testen.

Matthias

 

[florian030]

Hallo Matthias

Schreiben in eine Tabelle die nicht existiert, usw. unterbricht die Replikation doch genauso.

Und wie soll es dazu kommen? server.php läuft jede Minute. Bei einem sql-slave-lag > 60s wird die DB durch ISPConfig angelegt. Ansonsten durch die sql-Replikation.

Ouhh, Missverständnis, das wollte ich gar nicht. Ich setze in dem Fall einen Active/Passive Cluster ein. /var/lib/mysql liegt auf DRBD und der MySQL Dienst mitsamt Shared IP schwenkt mit dem Cluster. Damit habe ich zwar keine Lastverteilung, aber dafür Hochverfügbarkeit, was im aktuellen Projekt wichtiger ist.

Kleines Missverständnis. Das klingt schon besser.

Klar, es gibt durchaus Vorteile, der MySQLReplikation, die auf der Hand liegen. Vor allem die Idee mit dem Slave, der nur zum Dumpen dient. Das finde ich richtig gut. Und wenn da mal die Replikation nicht tut, dann ist wenigstens "nur" das Backup Müll, aber nicht die Produktiv Umgebung betroffen.

Wenn die Replikation steht, kannst Du dir Backups am Slave auch sparen. Die sind dann alles nur nicht konsistent. Ich mache meine SQL-Backups nur auf dem Slave, wenn slave-io-runnung und slave-lag < 5s. Ansonsten dumpt das Script lokal auf dem jeweiligen Master.

dafür nimmt man dann ggfs. riesige Binlogs in Kauf.

Die kann man schon limitieren. Wenn ich eine Master-Master-Replikation fahren will, dann muss der Rest natürlich auch passen. Und ein slave-lag sollte dann nicht zu groß werden.

Nimms mir nicht übel, aber ich werd mich mit dem jetzigen Replikations Mechanismus als MAster/Master Setup nicht mehr anfreunden und stattdessen als nächstes Projekt irgendwann mal die Galera Geschichte testen.

Ich bin da flexibel. Deine Erfahrungen würden mich sehr interessieren.

 

[Brainfood]

@Till

wie wäre es mit diesem Feature Request:

Ein Check von:

mysql> SHOW MASTER STATUS;

mit ins ISPConfig zu packen, für Leute die MA/MA Rep. usen wollen?

 

[mattula]

Und wie soll es dazu kommen? server.php läuft jede Minute. Bei einem sql-slave-lag > 60s wird die DB durch ISPConfig angelegt. Ansonsten durch die sql-Replikation.

Die DB soll nicht nur die lokale "dbispconfig" beherbergen, sondern den DB-Server für die Kunden darstellen. Wenn ich also den Kunden wahlweise

• beide DB-Server IPs gebe
• oder einen Loadbalancer vor die DB-Server stelle

dann ist doch Tür und Tor geöffnet für jegliche Art von Replikationsfehlern.

Oder nicht? Ich hab's ja bei rumspielen alleine schon ein paarmal geschaft die Replikation zu behindern.

Ich bin da flexibel. Deine Erfahrungen würden mich sehr interessieren.

Werde ich dann irgendwann hier posten.

Grüße,
Matthias