ISPConfig Cluster-Setup kann die MySQL-Replikation abbrechen 1

Gleich vorneweg: das hier beschriebene ist kein Fehler von ISPConfig, sondern eher eine Verkettung unglücklicher Umstände.

Wenn in ISPConfig mehrere Datenbank-Server eingerichtet sind und diese auf MySQL-Ebene in einer Replikation laufen (was wohl zwingend erforderlich ist), kann es unter bestimmten Umständen dazu kommen, dass die MySQL-Replikation mit dem Fehler 1007 (Can’t create database) abbricht.

Testen lässt sich das recht simpel: auf beiden Server den slave anhalten (wenn die Datenbank mysql von der Replikation ausgeschlossen ist, reicht es, den slave auf einem Server zu stoppen),
STOP SLAVE;

auf dem ersten die Datenbank testme anlegen.
CREATE DATABASE testme;
und auf dem zweiten Server die Datenbank ebenfalls anlegen:
CREATE DATABASE testme;

auf dem ersten Server den Slave wieder starten und den Status anzeigen:
START SLAVE;
SHOW SLAVE STATUS \G anzeigen.

Die Ausgabe sieht dann u.a. so aus:
Last_SQL_Error: Error 'Can't create database 'testme'; database exists' on query. Default database: 'testme'. Query: 'create database testme'

Damit die Replikation wieder läuft, auf dem ersten Server den Slave wieder anhalten, den Fehler überspringen und den Slave neu starten:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;


Das liegt daran, dass ISPConfig auf jedem Server eine neue Datenbank anlegt. Durch die Replikation auf MySQL-Ebene ist diese aber bereits vorhanden. Das CREATE DATABASE führt also zu dem Fehler 1007. Wirklich vermeiden lässt sich das leider nicht.

Es gibt aber ein paar Lösungsansätze:

Man könnte den 2. Datenbank-Server aus ISPConfig austragen und die Datenbanken lediglich über eine Master-Master-Replikation laufen lassen. Dadurch bleiben zwar die Datenbanken aus Sicht der Webseiten hoch verfügbar, Änderungen in ISPConfig würden aber ausfallen (neue Datenbank, geänderte User-Daten etc.), wenn der an ISPConfig angebundene Datenbank-Server ausfällt. Dann bleiben Änderungen so lange in der Queue, bis dieser wieder online ist. Das ist schon mal nicht besonders sinnvoll, kann aber bei kleineren Setups durchaus eine Option sein.

DRBD für die MySQL-Datenbanken wäre auch eine Möglichkeit. Ich halte aber nicht viel davon, eine MySQL-Replikation auf der Filesystem-Ebene abzubilden, zumal dadurch auch die Datenbank mysql auf beiden Servern identisch ist. Ich habe ganz gerne auf jedem Server unterschiedliche root-User.

Die dritte Möglichkeit ist, in mysql_clientdb_plugin.inc.php vor dem Erstellen der Datenbank zu prüfen, ob diese schon vorhanden ist. Das lässt sich relativ einfach realisieren:

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);
}
Aber auch hier bleibt das Problem eines Split-Brains bestehen. Ist ein DB-Server down, dann wird dieser, sobald er wieder online ist, versuchen, die entsprechende DB auch auf dem anderen Server anzulegen. Ergo: wieder bricht die Replikation weg.

Die vierte – und m.E. beste Variante – umgeht das Problem auf der MySQL-Ebene. Da das Problem nicht auf ISPConfig beruht, sondern auf MySQL, wohl auch der beste Weg.
In MySQL wird auf der Slave-Seite (eine Master-Master-Replikation besteht immer auf jedem Server aus einem Master- und einem Slave-Teil) der Fehler 1007 (DB angelegt, die bereits vorhanden ist) kurzerhand ignoriert. Gleiches sollte auch für 1008 eingetragen werden (Fehler bei DROP DATABASE, da diese bereits nicht mehr existiert). In die my.cnf wird unter mysqld

slave_skip_errors=1007,1008

eingetragen und MySQL neu gestartet. Ab jetzt bricht die Replikation nicht mehr ab, wenn eine bereits existierende Datenbank angelegt oder eine nicht mehr vorhandene Datenbank gelöscht werden soll.