© gnbd, 123RF

Sind die Datenbankinhalte so wichtig, dass sie auch zwischen periodischen Datensicherungen nicht verloren gehen dürfen, dann ist Replikation ein Ausweg. Dieser Artikel beschreibt, wie sich die Doppelung mit Maria DB unter Zuhilfenahme von Xtra Backup bequem einrichten lässt.

Daten sind ja angeblich das neue Öl. Zwar sind sie im Unterschied zum Öl kein Verbrauchsgut, das sich nur einmal nutzen lässt, aber der Spruch unterstreicht zumindest: Daten sind wertvoll. Was wertvoll ist, wird sein Besitzer vor Verlust schützen wollen. Das erste Mittel der Wahl ist hier das Backup. Allerdings hat die klassische, periodische Datensicherung den Nachteil, dass Daten, die sich nach der letzten Sicherung geändert haben, verloren sind.

Ein Ausweg kann die Replikation sein, also die Übertragung aller Änderungen zum Speicherort einer Kopie. Gleichzeitig unterstützt dieser Ansatz die Lastverteilung, wenn auch das zweite System lesenden Benutzern zur Verfügung steht.

Spielarten

Zur Begriffsklärung zunächst ein kleiner Exkurs durch die Arten der Replikation (Abbildung 1). Eine allein stehende Instanz wird als Stand-alone bezeichnet – in diesem Fall wird natürlich auch nichts repliziert. Beim Cold Stand-by läuft das Reservesystem erst an, nachdem sein Pendant ausgefallen ist. Auch hier muss noch nicht zwingend repliziert werden, es reicht, wenn das Reservesystem auf einen Shared Storage zugreifen kann, den es sich mit dem ersten teilt.

Abbildung 1: Bei Stand-by-Lösungen lassen sich verschiedene Spielarten unterscheiden. Je nachdem, ob und in welchem Umfang der zweite Knoten mitzubenutzen ist.

Beim Warm Stand-by dagegen übernimmt zwar die primäre Maschine alle Schreib- und Leseaktionen, die sekundäre ist jedoch ebenfalls in Betrieb und empfängt fortlaufend Replikate. Sie kann zu jedem Zeitpunkt ohne Datenverlust einspringen. Wird die zweite Maschine darüber hinaus genutzt, um die erste beim Lesen zu entlasten, spricht man von Hot Stand-by. Schließlich können beide Seiten gleichzeitig lesend und schreibend mitarbeiten und die Änderungen pausenlos gegenseitig abgleichen. In diesem speziellen Fall ist von einem Master-Master-Setup die Rede.

Ein klassisches Hochverfügbarkeitsszenario besteht aus mindestens drei Rechnern, damit der Betrieb nicht von einer einzelnen Maschine abhängt, sollte eine ausfallen. Da oft auch Lastverteilung eine große Rolle spielt, schlägt die Replikation hier zwei Fliegen mit einer Klappe.

Daten duplizieren

MySQL bietet bereits seit über 15 Jahren eine einfach aufsetzbare Replikation. Heute arbeiten drei Firmen offiziell an ihrer Weiterentwicklung: Das ist zum einen MySQL selbst, das seit 2009 zu Oracle gehört. Weiter gibt es die Firma Maria DB, die einige Ur- und Kernentwickler von MySQL in Finnland nach der Übernahme durch Oracle gegründet haben. Und schließlich riefen bereits zuvor in den USA andere ehemalige MySQL-Mitarbeiter die Firma Percona ins Leben, die sich ebenfalls mit Themen wie Backup, Hochverfügbarkeit oder Replikation bei Oracles MySQL wie auch bei Maria DB beschäftigt.

In diesem Artikel wird Maria DB 10.1 unter Ubuntu 16.04 verwendet. Das vorgestellte Xtra Backup 2.4 von Percona funktioniert auch unter anderen Linux-Distributionen und mit MySQL in vergleichbarer Weise.

Voraussetzung für die Inbetriebnahme einer Replikation – egal ob warm oder hot – ist, dass identische Daten sowohl auf der Seite des primären Rechners, Master genannt, als auch auf Seite des sekundären Rechners, dem Slave, vorhanden sind. Diesen Gleichstand kann man etwa durch eine Kopie des Datenverzeichnisses von Maria DB/MySQL erreichen oder – das ist der bessere und hier beschriebene Weg – durch ein Backup.

Beim bloßen Kopieren ist nämlich Vorsicht geboten. Einige Tools versuchen einfach im laufenden Betrieb das Daten- und Logverzeichnis zu duplizieren, ohne den Cache und laufende Transaktionen zu berücksichtigen. Mit solchen Dateisystem-Backups lässt sich in der Regel kein Datenbanksystem wiederherstellen. Andere halten das Datenbanksystem an, sichern das Dateisystem und fahren dann die Datenbank wieder hoch. So ist zwar garantiert, dass sich das Backup wiederherstellen lässt, aber ein Systemstopp im 24/7-Betrieb ist für viele Anwendungen nicht akzeptabel. Wieder andere nutzen Dumps. Diese kosten jedoch sehr viel Performance und auch hier lässt sich das System nur maximal bis zum Zeitpunkt des Dump wiederherstellen.

Anders liegen die Dinge jedoch beim Backupsystem Xtra Backup von Percona: Mit seiner Hilfe lässt sich eine Maria DB/MySQL-Datenbank auch bis zu einem Zeitpunkt wiederherstellen, der nach dem letzten regulären Backup liegt (Point in Time Recovery). Einzige Bedingung: Es müssen die nötigen Logdaten vorhanden sein. Daher ist Xtra Backup auch hervorragend geeignet, um schnell und einfach einen neuen Replikationsknoten (Slave) aufzusetzen, ohne den Master oder einen bereits vorhandenen Slave herunterzufahren.

Einstellungen anpassen

Moderne Linux-Systeme nutzen standardmäßig UTF-8. Das heißt: Clients, die man auf der Konsole ausführt, etwa der Command Line Client von Maria DB/MySQL und auch die Befehle von Xtra Backup, sprechen zwar UTF-8. Voreingestellt ist bei MySQL und Maria DB aber häufig der Zeichensatz Latin-1. Es ist ratsam, diese Einstellung bei jeder Installation global zu ändern. Die Konfigurationsdatei »mariadb.cnf« liegt bei Ubuntu 16.04 unter »/etc/mysql/conf.d« . Die UTF-8-Character-Einstellungen sind dort schon auskommentiert enthalten. Es empfiehlt sich, sowohl den Client (Slave) als auch den kompletten Server (Master) auf UTF-8 umzustellen (Listing 1).

01 [...]
02 # MariaDB-specific config file.
03 # Read by /etc/mysql/my.cnf
04
05 [client]
06 # Default is Latin1, if you need UTF-8 set this (also in server section)
07 default-character-set = utf8
08
09 [mysqld]
10 #
11 # * Character sets
12 #
13 # Default is Latin1, if you need UTF-8 set all this (also in client section)
14 #
15 character-set-server   = utf8
16 collation-server       = utf8_general_ci
17 character_set_server   = utf8
18 collation_server       = utf8_general_ci
19 [...]

Daneben wird bei der Installation die Konfigurationsdatei »/etc/mysql/conf.d/mysql_safe_syslog.cnf« angelegt, die verhindert, dass ein Error-Log geschrieben wird. Um das Error-Log zu aktivieren, kommentiert der Admin »skip_log_error« aus und konfiguriert danach den Pfad (Listing 2).

01 [...]
02 [mysqld_safe]
03 #skip_log_error
04 log-error = /var/log/mysql/error.log
05 syslog
06 [...]

Wenn die Instanz später als Master laufen soll, ist darauf zu achten, dass in »/etc/mysql/my.cnf« der Parameter »bind-address« nicht auf »localhost« (»127.0.0.1« ) verweist. Damit Fehlermeldungen im Log landen, sollte der Datenbank-Admin in der »my.cnf« den Pfad für »log-error« setzen. Der Parameter »log_warnings« legt fest, was zu loggen ist. Der Wert » « deaktiviert das Logging. Ein Wert größer »1« loggt zusätzlich abgebrochene Verbindungen.

Bei einem Replikationssetup benötigt jeder Node eine eindeutige »server_id« bestehend aus einem positiven Integer. Beliebt ist hier das simple Hochzählen der Maschinen, alternativ kann man auch die letzten Stellen der IPv4-Adresse verwenden. Für Xtra Backup ist es – genau wie für den Replikationsmaster – erforderlich, dass das Binlog aktiviert ist. Hierfür setzt der Admin den entsprechende Pfad. Das System indiziert das Binlog. Die Indexdatei wird mit »log-bin-index« festgelegt.

Heute zeilenorientiert

Früher arbeitete man oft mit einer Statement-basierten Replikation. Die hat ein kleineres Logfile, aber auch Nachteile: So können sich etwa Werte, die benutzerdefinierte Funktionen oder Stored Procedures liefern, bei jedem Aufruf unterscheiden. Ein Beispiel wäre »NOW()« . Wird dieses Statement auf dem Slave wiederholt, muss es einen anderen Wert erzeugen als zuvor auf dem Master.

Sowohl »DELETE« als auch »UPDATE« – beide mit »LIMIT« , aber jeweils ohne »ORDER BY« – sind nicht-deterministische Funktionen, die auf beiden Seiten zu verschiedenen Ergebnissen führen können. Außerdem ist eine Reihe von Statements prinzipiell nicht replizierbar, darunter »SYSDATE()« , »UUID()« , »GET LOCK()« oder »RAND()« .

Deshalb greifen Admins heute lieber zur Zeilen-basierten Replikation. Die erzeugt zwar mehr Daten, kann dafür aber alle Änderungen replizieren. Hierfür wird das Binlog-Format auf »row« gesetzt. Je nach Anwendung wächst das Binlog-Verzeichnis aber sehr schnell. Die Variable »expire_logs_days« legt fest, nach wie vielen Tagen das System Binlog-Dateien löscht. Prinzipiell sollten alle Binlogs, die während und nach einem Backup entstanden sind, so lange erhalten bleiben, bis das nächste Backup im Kasten ist. Da sie aber viel Speicherplatz einnehmen, setzen Debian und Ubuntu ihre Aufbewahrungszeit per Default auf zehn Tage fest. Auch das mag zu lange sein. Üblich sind drei bis fünf Tage.

Die Variable »max_binlog_size« legt die Größe einer einzelnen Binlog-Datei fest. Der Defaultwert ist 1 GByte, aber Debian und Ubuntu-Installationen setzen »max_binlog_size« auf 100 MByte. Xtra Backup möchte zudem noch für jede Inno-DB-Tabelle eine eigene Datei angelegen. Das aktiviert die Variable »innodb_file_per_table« (Listing 3).

01 [...]
02 [mysqld]
03 [...]
04 #bind-address            = 127.0.0.1
05 [...]
06 log-error=/var/log/mysql/error.log
07 log_warnings            = 2
08 [...]
09 server-id                = 1
10 [...]
11 log_bin                 = /var/log/mysql/mariadb-bin
12 log_bin_index           = /var/log/mysql/mariadb-bin.index
13 binlog_format = row
14 [...]
15 expire_logs_days        = 10
16 max_binlog_size         = 100M
17 [...]
18 innodb_file_per_table   = 1
19 [...]

Jetzt sind alle Vorbereitungen getroffen. Damit das System die geänderten Konfigurationen anwendet, muss der Datenbankserver neu booten. Bei Debian oder Ubuntu geschieht dies durch:

sudo service mysql restart

Wenn der Admin später ein Replikationssystem aufsetzten will, empfiehlt es sich, eine extra Rolle (Nutzer) anzulegen. Da die Slaves die Verbindung herstellen, ist für die Rolle der entsprechende Host der Slaves anzugeben. Auch für das Backup ist es sinnvoll, eine eigene Nutzer-Rolle anzulegen. Weil Xtra Backup auf derselben Maschine läuft, reicht hier als Host »localhost« . Beide Rollen oder Nutzer brauchen Super-Userrechte und sollten durch ein Passwort gesichert sein. Das Beispiel in Listing 4 zeigt, welche SQL-Schritte dafür erforderlich sind.

01 CREATE USER replikation@'192.168.23.%';
02 CREATE USER backup@localhost;
03 GRANT ALL ON *.* TO replikation@'192.168.23.%' WITH GRANT OPTION;
04 GRANT ALL ON *.* TO backup@localhost WITH GRANT OPTION;
05 SET PASSWORD FOR replikation@'192.168.23.%' = PASSWORD('Ein_gutes_Passwort');
06 SET PASSWORD FOR backup@localhost = PASSWORD('Ein_gutes_Passwort');

Die von Ubuntu 16.04 mitgelieferte Version von Percona Xtra Backup funktioniert nicht mit Maria DB 10.1 für Ubuntu 16.04. Das ist aber kein Problem: Mit nur wenigen Schritten ist die Percona-Xtra-Backup-Version für das System direkt von Percona installiert und das System erkennt künftig auch alle Updates für diese Version. Die passende Installationsanleitung gibt es unter [1]. Listing 5 enthält die Schritte, die für die Beispielinstallation notwendig waren.

01 wget https://repo.percona.com/apt/percona-release_0.1-3.wily_all.deb
02 sudo dpkg -i percona-release_0.1-3.wily_all.deb
03 sudo apt-get update
04 sudo apt-get install percona-xtrabackup-24

Xtra Backup stellt eine Kopie des Datenverzeichnisses her – genügend Speicherplatz ist wichtig. Xtra Backup lässt sich mit »rsync« verwenden, inkrementelle Backups sind natürlich auch möglich. Ein Backup stößt der Admin durch den Befehl »innobackupex« an:

innobackupex --user=backup --password=Ein_gutes_Passwort --throttle=60 --parallel=3 --safe-slave-backup "/mnt/backup/mariadb/" >> /mnt/backup/mariadb/backup.log 2>&1

Der Befehl muss auch die Verbindungsdaten zum Datenbankserver erhalten. Der Parameter »–throttle« bestimmt, wie viele I/O-Operationen pro Sekunde erlaubt sind. Das verhindert, dass das laufende System zu sehr durch die I/O-Last des Backup-Prozesses eingeschränkt wird. Der Parameter »–parallel« legt fest, wie viele Threads das Backup zeitgleich verwendet.

Um bereits laufende Replikationen nicht zu behindern, stoppt die Option »–safe-slave-backup« die aktiven Slave-Threads, sobald die laufenden Transaktionen beendet sind. Nach dem Backup starten die Slave-Threads automatisch wieder. Per Default legt das Backup im angegebenen Verzeichnis ein Unterverzeichnis mit dem aktuellen Zeitstempel als Namen an. Das lässt sich mit »–no-timestamp« verhindern. Günstig ist die Umleitung von Warnungen und Fehlermeldung in eine Datei.

Um die Änderungen nachzuführen, die während des Kopierens des Datenverzeichnisses erfolgen, ist »innobackupex« erneut mit der Option »–apply-log« auszuführen. Durch die Option »–use-memory« kann der Admin noch festgelegen, wie viel Arbeitsspeicher während der Operation zur Verfügung stehen soll. Für das Log-Apply gibt er den Pfad zum Backup an:

innobackupex --user=backup --password=Ein_gutes_Passwort --safe-slave-backup --use-memory=1GB --apply-log "/mnt/backup/mariadb/2016-05-17-21_26_32" >> /mnt/backup/mariadb/backup_apply.log 2>&1

Ein Slave kann die gleiche oder eine neuere Version des DBMS benutzen wie der Master. Es ist aber ratsam, stets die neueste stabile Version zu installieren, auch wenn in der Distribution eine ältere Version vorhanden wäre. Maria DB steht auf mehreren Spiegelservern bereit. Eine genaue Anleitung, wie die DB auf den unterschiedlichen Betriebssystemen zu installieren ist, gibt es unter [2].

Die Konfigurationen, die auf Seiten des Slave bei Debian oder Ubuntu unter »/etc/mysql« liegen, sind ähnlich wie beim Master anzupassen (siehe oben). Wichtig ist eine eindeutige »server_id« . Binlogs brauchen für den Slave nicht aktiviert zu sein. Da die Replikation auch die User und Passwörter vom Master überträgt, ist das Passwort in der »debian.cnf« für den Zugriff des »debian-sys-maint« vom Master zu kopieren oder nach Aufsetzen des Slave mit Hilfe des SQL-Befehls »SET PASSWORT« auf das in der Konfigurationsdatei gesetzte Passwort zu ändern. Dazu den Server stoppen:

sudo service mysql stop

Jetzt tauscht der Admin das Datenverzeichnis, das bei Debian/Ubuntu in der Regel unter »/var/lib/mysql« zu finden ist, gegen das gleiche Verzeichnis aus dem Backup aus. Er sollte vor dem Löschen einmal nachschauen, welcher User und welche Gruppe als Eigentümer der Dateien und Unterverzeichnissen auftauchen. Diese Rechte passt er gegebenenfalls an. Bei einer Standardinstallation sollten alle Dateien und Unterverzeichnisse sowie das Verzeichnis »/var/lib/mysql« dem User »mysql« gehören. Dann startet er den Server wieder:

sudo service mysql start

Auch wenn keine andere Version installiert wurde, ist es empfehlenswert, einmal »mysql_upgrade« mit »–force« beziehungsweise »-f« laufen zu lassen. Unbedingt beachten: Auch das Passwort des Superusers Root hat der Master übernommen:

sudo mysql_upgrade -f -u root -p Root_Passwort_vom_Master

Im Datenverzeichnis findet sich die lesbare Datei »xtrabackup_binlog_info« . In ihr ist festgehalten, an welcher Position in welcher Binlog-Datei die Replikation starten muss:

mariadb-bin.000008      615822  0-1-625

Mit Hilfe dieser Information und der IP-Adresse des Masters lässt sich jetzt der Slave per SQL konfigurieren (Listing 6). Der Server startet mit dem SQL-Befehl »START SLAVE« , der SQL-Befehl »SHOW SLAVE STATUS« (Listing 7) überprüft den Status des Slave.

01 CHANGE MASTER TO
02 MASTER_USER='replikation',
03 MASTER_PASSWORD='ein_gutes_passwort',
04 MASTER_HOST='192.168.23.192',
05 MASTER_LOG_FILE='mariadb-bin.00008',
06 MASTER_LOG_POS=615822;

01 *************************** 1. row ***************************
02                Slave_IO_State: Queueing master event to the relay log
03                   Master_Host: 192.168.23.192
04                   Master_User: replikation
05                   Master_Port: 3306
06                 Connect_Retry: 60
07               Master_Log_File: mariadb-bin.000008
08           Read_Master_Log_Pos: 140927111
09                Relay_Log_File: mysqld-relay-bin.000002
10                 Relay_Log_Pos: 11109399
11         Relay_Master_Log_File: mariadb-bin.000008
12              Slave_IO_Running: Yes
13             Slave_SQL_Running: Yes
14               Replicate_Do_DB:
15           Replicate_Ignore_DB:
16            Replicate_Do_Table:
17        Replicate_Ignore_Table:
18       Replicate_Wild_Do_Table:
19   Replicate_Wild_Ignore_Table:
20                    Last_Errno: 0
21                    Last_Error:
22                  Skip_Counter: 0
23           Exec_Master_Log_Pos: 11724682
24               Relay_Log_Space: 140312671
25               Until_Condition: None
26                Until_Log_File:
27                 Until_Log_Pos: 0
28            Master_SSL_Allowed: No
29            Master_SSL_CA_File:
30            Master_SSL_CA_Path:
31               Master_SSL_Cert:
32             Master_SSL_Cipher:
33                Master_SSL_Key:
34         Seconds_Behind_Master: 94154
35 Master_SSL_Verify_Server_Cert: No
36                 Last_IO_Errno: 0
37                 Last_IO_Error:
38                Last_SQL_Errno: 0
39                Last_SQL_Error:
40   Replicate_Ignore_Server_Ids:
41              Master_Server_Id: 1
42                Master_SSL_Crl:
43            Master_SSL_Crlpath:
44                    Using_Gtid: No
45                   Gtid_IO_Pos:
46       Replicate_Do_Domain_Ids:
47   Replicate_Ignore_Domain_Ids:
48                 Parallel_Mode: conservative
49 1 row in set (0.01 sec)

Wenn »Slave_IO_Running« und »Slave_SQL_Running« auf »Yes« stehen, dann läuft der Slave. Enthält einer der beiden Parameter den Wert »No« , sollte unter »Last_IO_Error« beziehungsweise unter »Last_SQL_Error« eine Fehlermeldung zu finden sein.

Wichtig ist die Information »Seconds_Behind_Master« . Bei einem frischen Slave dauert es etwas, bis er alle Binlogs nachgezogen hat. Der Slave ist aufgesetzt und lässt sich zur Lastverteilung lesend einsetzen. (jcb)