11 Datenbank
In diesem Kapitel finden Sie Basisstrategien für die Aufgaben, denen Sie bei Datenbanken regelmäßig gegenüberstehen.
An Datenbanksystemen mangelt es in der Linux-Welt nicht. Die Entscheidung, in diesem Kapitel ausschließlich MariaDB zu behandeln, fiel aus zwei Gründen. Zum einen ist MariaDB mittlerweile das Linux-Datenbanksystem mit der weitesten Verbreitung in neuen Distributionen.
Zum anderen ist es als Fork von MySQL spätestens seit der Version 5.0 endgültig den Kinderschuhen entwachsen und enthält Funktionen, die früher nur teuren kommerziellen Systemen vorbehalten waren.
11.1 MariaDB in der Praxis
Alle populären Linux-Distributionen enthalten MariaDB-Pakete, bei vielen wurde MySQL durch MariaDB ersetzt. In CentOS 7 findet sich die Version 5.5.60, in Debian die Version 10.1.26, in Ubuntu die Version 10.1.34 und in openSUSE Leap 10.2.15.
[+] Bitte beachten Sie, dass wir – wenn nicht explizit auf eine andere Konfigurationsdatei verwiesen wird – alle Konfigurationen in der Datei adminbuch.cnf in dem Verzeichnis /etc/mysql/mariadb.conf.d für Debian und Ubuntu bzw. im Verzeichnis /etc/my.cnf.d unter CentOS und openSUSE Leap vornehmen.
11.1.1 Installation und grundlegende Einrichtung
Unter Debian und Ubuntu installieren Sie MariaDB mit dem folgenden Kommando:
apt install mariadb-server
Listing 11.1 Installation des Pakets »mariadb-server« unter Debian und Ubuntu
Unter CentOS wird das Paket folgendermaßen installiert:
yum install mariadb-server
Listing 11.2 Installation des Pakets »mariadb-server« unter CentOS
Unter openSUSE heißt das gewünschte Paket nicht mariadb-server, sondern schlicht mariadb. So installieren Sie es:
zypper install mariadb
Listing 11.3 Installation des Pakets »mariadb« unter openSUSE
Abhängig von der verwendeten Linux-Distribution werden Sie möglicherweise bereits während der Installation nach einem Passwort für den MariaDB-Benutzer root gefragt. Er ist nicht identisch mit dem Superuser, also dem root-Account Ihres Linux-Systems, sondern repräsentiert lediglich den Administrator des MariaDB-Servers.
In allen von uns unterstützten Distributionen starten Sie den Datenbankserver mit systemctl start mariadb. Allerdings werden bei allen hier behandelten Distributionen die MySQL-Clients, wie beispielsweise mysql und mysqladmin, verwendet. Sollte die Installationsroutine Sie nicht nach einem Passwort fragen, vergeben Sie es unmittelbar nach der Installation und dem Start des Servers mit dem folgenden Kommando:
/usr/bin/mysqladmin -u root password 'NeuesPasswort'
Listing 11.4 Passwort für den »root«-Account des MariaDB-Servers vergeben
Zusätzlich ist es sinnvoll, ein weiteres Administrationskonto einzurichten. Dazu loggen Sie sich zunächst als root auf dem MariaDB-Server ein:
mysql -u root -p
Listing 11.5 Login auf dem MariaDB-Server
Nach der erfolgreichen Eingabe des Passworts ändert sich Ihr Kommandozeilenprompt in MariaDB [(none)]>. Jetzt können Sie das neue Benutzerkonto anlegen:
GRANT ALL ON *.* TO 'ich'@'localhost' IDENTIFIED BY 'MeinKennwort' WITH GRANT OPTION;
Listing 11.6 Ein neues Benutzerkonto mit weitreichenden Rechten anlegen
Achten Sie besonders auf das abschließende Semikolon; es ist unbedingt erforderlich, wird aber häufig vergessen. Mit exit verlassen Sie den MariaDB-Kommandoprompt wieder.
[+] Per Default bindet sich MariaDB unter Debian, openSUSE und Ubuntu unmittelbar nach der Installation nur auf die IP-Adresse 127.0.0.1 (localhost). Wenn Sie diese Einstellung ändern möchten, erstellen Sie bitte unter Debian, openSUSE und Ubuntu eine Datei namens /etc/mysql/mariadb.conf.d/adminbuch.cnf, in die Sie unterhalb des Eintrags [mysqld] einen Eintrag bind-address = 0.0.0.0 aufnehmen.
[ ! ] Mit der Einstellung bind-address = 0.0.0.0 bindet sich MariaDB an alle auf dem Server konfigurierten IP-Adressen. Prüfen Sie vor einem solchen Schritt genau, ob diese Konfiguration notwendig und – gerade unter Sicherheitsgesichtspunkten – sinnvoll ist.
Nach einem Neustart des Datenbankservers sollte Ihnen lsof Informationen analog zur folgenden Ausgabe liefern:
# lsof -i tcp:3306
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mysqld 11735 mysql 14u IPv4 28487 0t0 TCP *:mysql (LISTEN)
Listing 11.7 Feststellen, auf welche IP-Adressen der Datenbankserver hört
Wie Sie sehen können, heißt das Kommando trotz Abspaltung vom MySQL-Projekt immer noch mysqld und nicht wie erwartet mariadb.
11.1.2 Replikation
Durch Replikationsmechanismen können Sie Datenbanken, die sich auf unterschiedlichen MariaDB-Servern befinden, auf dem gleichen Stand halten.
Das bietet eine Reihe von Vorteilen. So können Sie beispielsweise die Last gezielt auf mehrere Server verteilen:
-
Eine Datenbank erhält nur Aktualisierungen, eine andere nur Abfragen.
-
Eine Datenbank erhält nur Aktualisierungen, mehrere andere erhalten Abfragen.
-
Mehrere Datenbanken erhalten sowohl Aktualisierungen als auch Abfragen.
Mittels Replikation ist es auch möglich, eine Datenbank auf den Notebooks von Außendienstmitarbeitern automatisch mit einer Datenbank in der Firmenzentrale abzugleichen, damit die Mitarbeiter stets über den neuesten Datenbestand verfügen.
Wir werden folgende Replikationsmethoden betrachten:
-
Master-Slave-Replikation
Ein Master-Server kann einen oder mehrere Slaves haben. Der Master speichert Updates auch in Binlogs (binären Log-Dateien). Wenn ein Slave eine Verbindung zum Master herstellt, teilt er ihm mit, bis zu welcher Position er die Binlogs beim letzten Update gelesen hat. Der Master repliziert daraufhin alle Änderungen, die seit diesem Zeitpunkt aufgelaufen sind, auf den Slave. Danach wartet der Slave, bis er vom Master über weitere Änderungen informiert wird. Während dieser Zeit kann er Anfragen beantworten, Aktualisierungen werden aber immer nur auf dem Master vorgenommen. -
Master-Master-Replikation (Ring-Replikation)
Hier dürfen Schreibvorgänge auf allen beteiligten Servern durchgeführt werden, aber das birgt auch die Gefahr, dass auto_increment-Felder auf allen Mastern gleichzeitig inkrementiert werden und so doppelte Werte auftreten. Daher müssen für diesen Fall Vorkehrungen getroffen werden.
[ ! ] Die erwähnten binären Logfiles zeichnen von dem Moment an, an dem das Logging gestartet wird, alle Änderungen an den Datenbanken des Master-Servers auf. Wenn Sie einen Replikationsverbund aufbauen, ist es wichtig, dass zum Start der Replikation alle Server den Stand der Master-Datenbanken zu dem Zeitpunkt haben, an dem die binären Logfiles aktiviert wurden. Weichen die Stände voneinander ab, wird es sehr wahrscheinlich zu Fehlern bei der Replikation kommen. Achten Sie auch auf mögliche Versionsunterschiede bei den MariaDB-Servern, die Sie einsetzen. Neuere Slaves können in der Regel mit älteren Mastern zusammenarbeiten, aber nicht umgekehrt.
Konfiguration eines Master-Servers
Legen Sie zunächst einen Benutzer für die Replikation an. Der Benutzer für das folgende Beispiel heißt repl und bekommt das Passwort slavepass, der User darf sich aus dem angegebenen Netzbereich anmelden:
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
-> TO repl@'192.168.1.%' IDENTIFIED BY 'slavepass';
### oder ###
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
-> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
Listing 11.8 Einen Benutzer für die Replikation anlegen
Vergewissern Sie sich nun, dass der Abschnitt [mysqld] der Datei adminbuch.cnf (siehe auch den Hinweis zu Beginn des Kapitels 11) auf dem MasterServer die Option log-bin enthält. Der Abschnitt sollte außerdem eine Option server-id=master_id enthalten, wobei master_id ein positiver Integer zwischen 1 und 4294967295 (232 - 1) sein muss. Da der DefaultWert 1 ist, kann er auch auf einem schlecht konfigurierten Server noch »versehentlich« gesetzt sein, deshalb sollten Sie einen anderen Wert wählen.
Um die größtmögliche Dauerhaftigkeit und Konsistenz in einer Replikationskonfiguration für InnoDB[ 18 ] mit Transaktionen zu erzielen, sollten Sie in jedem Fall innodb_flush_log_at_trx_commit=1 und sync_binlog=1 in der Datei adminbuch.cnf auf dem Master angeben. So sieht ein Beispiel für den fertigen Konfigurationsabschnitt aus:
[mysqld]
log_bin = /var/log/mysql/mariadb-bin.log
max_binlog_size = 100M
server_id = 100
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Listing 11.9 Die Änderungen in der Datei »adminbuch.cnf«
[+] Nachdem Sie diese Änderungen vorgenommen haben, müssen Sie den MariaDB-Daemon neu starten. Falls Sie CentOS benutzen, legen Sie vorher noch mit den folgenden Kommandos das Verzeichnis /var/log/mysql für den User mysql an:
mkdir /var/log/mysql
chown mysql:mysql /var/log/mysql
Listing 11.10 Das Log-Verzeichnis anlegen und dem User »mysql« zuordnen
Nun muss der Slave erstmalig mit einer Momentaufnahme der Daten des Masters versorgt werden. Synchronisieren Sie alle Tabellen, und unterbinden Sie Schreibanweisungen, indem Sie eine FLUSH TABLES WITH READ LOCK-Anweisung auf dem Master ausführen:
MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
Listing 11.11 Tabellensynchronisierung und Stopp aller Schreibvorgänge
Wechseln Sie nun in das Datenverzeichnis des Master-Servers (/var/lib/mysql/). Dort gibt es für jede Datenbank ein Unterverzeichnis. Kopieren Sie die Dateien aller Datenbanken, die an der Replikation teilnehmen sollen, in das identische Verzeichnis auf dem Slave-Server. Lassen Sie dabei jedoch die Dateien master.info und relay-log.info aus.
[+] Wenn auf dem Slave-Server andere MariaDB-Benutzerkonten als auf dem Master vorhanden sind, sollten Sie die Datenbank mysql besser nicht replizieren.
Während die mit FLUSH TABLES WITH READ LOCK erwirkte Lesesperre gültig ist, ermitteln Sie den Namen des aktuellen Binär-Logs und den Versatz auf dem Master:
MariaDB [(none)]> SHOW MASTER STATUS;
+-----------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------+----------+--------------+------------------+
| mariadb-bin.003 | 73 | test | manual,mysql |
+-----------------+----------+--------------+------------------+
mysql >
Listing 11.12 Binlog-Name und Versatz auf dem Master ermitteln
Die Spalte File zeigt den Namen der Log-Datei an, und Position zeigt den Versatz innerhalb der Datei. In diesem Beispiel heißt die Binär-Log-Datei mariadb-bin.003, der Versatz ist 73. Notieren Sie diese Werte, denn Sie benötigen sie später beim Konfigurieren des Slaves. Die Werte stellen die Replikationskoordinaten dar, bei denen der Slave die Verarbeitung neuer Updates vom Master startet.
Wenn der Master zuvor ohne aktiviertes Binär-Logging ausgeführt wurde, sind die von SHOW MASTER STATUS oder mysqldump --master-data angezeigten Werte für Log-Name und Position leer. In diesem Fall lauten die Werte, die Sie später als Log-Dateinamen und Position auf dem Slave angeben müssen, " " (Leer-String) und 4.
Nachdem Sie die Momentaufnahme erstellt und Log-Name und Versatz aufgezeichnet haben, können Sie die Schreibaktivitäten auf dem Master neu starten:
MariaDB [(none)]> UNLOCK TABLES;
Listing 11.13 Schreibaktivitäten wieder starten
Notieren Sie den Log-Namen und Versatz aus der Ausgabe von SHOW MASTER STATUS (siehe Listing 11.12) wie zuvor beschrieben. Danach fahren Sie den Server herunter, ohne die Tabellen zu entsperren; hierdurch ist sichergestellt, dass der Server mit einem Status beendet wird, der den Angaben zu Log-Datei und Versatz entspricht:
# mysqladmin -u root shutdown
Listing 11.14 Den MariaDB-Server stoppen
Die Alternative: SQL-Speicherauszug
Eine Alternative, die sowohl bei MyISAM- als auch bei InnoDB-Tabellen funktioniert, besteht darin, einen SQL-Speicherauszug des Masters anstatt – wie zuvor beschrieben – einer binären Kopie zu erstellen. Hierzu führen Sie mysqldump --master-data auf dem Master aus und laden die SQL-Speicherauszugsdatei später in Ihren Slave. Diese Vorgehensweise ist langsamer als die Erstellung einer binären Kopie, hat aber dafür den Vorteil, dass der Slave dabei nicht gestoppt werden muss.
Der Name der binären Log-Datei und der Versatz sind in diesem Fall im Dump zu finden. Die genaue Vorgehensweise finden Sie im folgenden Unterabschnitt »Konfiguration des Slave-Servers«.
Konfiguration des Slave-Servers
Um den Slave-Server zu konfigurieren, nehmen Sie auch auf ihm zunächst die Änderungen an der Datei adminbuch.cnf vor. Für den Slave-Betrieb genügt es, den Parameter server_id zu setzen:
[mysqld]
server_id = 101
Listing 11.15 Server-ID des Slaves konfigurieren
Falls Sie die Master-Master-Replikation nutzen möchten, fügen Sie an dieser Stelle in der adminbuch.cnf auch die weiteren Parameter hinzu:
log_bin = /var/log/mysql/mariadb-bin.log
max_binlog_size = 100M
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Listing 11.16 Weitere Einstellungen für die Master-Master-Replikation
Falls Sie unter CentOS arbeiten, müssen Sie auch auf dem Slave nach dem Muster aus Listing 11.10 das Verzeichnis /var/log/mysql anlegen und für den User mysql beschreibbar machen.
Start der Master-Slave-Replikation
Zunächst wird auf dem Master eine Datenbank benötigt, die repliziert werden soll. Eine Beispieldatenbank mit nur einer Tabelle und zwei Datensätzen legen Sie wie folgt an:
MariaDB [(none)]> create database sonnensystem;
Query OK, 1 row affected (0.01 sec)
MariaDB [(none)]> use sonnensystem;
Database changed
MariaDB [sonnensystem]> create table planeten (id integer, name varchar(20));
Query OK, 0 rows affected (0.03 sec)
MariaDB [sonnensystem]> insert into planeten values (1,'Merkur'),(2,'Venus');
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
Listing 11.17 Eine einfache Beispieldatenbank
Anschließend müssen Sie die Log-Datei und die Position in der Log-Datei ermitteln, um die Synchronisation sauber zu starten. Alle Schreibzugriffe auf die Datenbank müssen unterbunden werden (siehe Listing 11.18). Bitte beachten Sie: Sie dürfen den Client nach dem flush tables with read lock nicht verlassen, da sonst der Lock aufgehoben wird.
MariaDB [sonnensystem]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)
MariaDB [sonnensystem]> show master status;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000001 | 1741 | | |
+--------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
Listing 11.18 Schreibzugriffe unterbinden und aktuellen Status ermitteln
Diese Datenbank wird nun in einer separaten Session in eine Datei exportiert und auf den Slave-Server kopiert:
mysqldump sonnensystem --databases --master-data -u root -p > sonnensystem.sql
scp sonnensystem.sql slave:/tmp/
Listing 11.19 Die Beispieldatenbank exportieren und auf den Slave-Server kopieren
Wechseln Sie nun auf den Slave-Server, und spielen Sie die Datei in MariaDB ein:
mysql -u root -p < /tmp/sonnensystem.sql
Listing 11.20 Die Beispieldatenbank auf dem Slave-Server in MariaDB einspielen
Kontrollieren Sie anschließend am MariaDB-Prompt, ob die Datenbank vollständig und korrekt angekommen ist:
MariaDB [(none)]> use sonnensystem;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [sonnensystem]> select * from planeten;
+------+--------+
| id | name |
+------+--------+
| 1 | Merkur |
| 2 | Venus |
+------+--------+
2 rows in set (0.00 sec)
Listing 11.21 Die Beispieldatenbank auf dem Slave-Server überprüfen
Das hat funktioniert. Fügen Sie jetzt auf dem Master-Server einen weiteren Datensatz zur Tabelle hinzu. Dazu muss natürlich zuerst der Lock aufgehoben werden:
MariaDB [sonnensystem]> unlock tables;
Query OK, 0 rows affected (0.00 sec)
MariaDB [sonnensystem]> insert into planeten values (3,'Erde');
Query OK, 1 row affected (0.01 sec)
Listing 11.22 Auf dem Master einen weiteren Datensatz zur Beispieldatenbank hinzufügen
Danach starten Sie die Replikation auf dem Slave so wie in Listing 11.23 beschrieben:
MariaDB [sonnensystem]> show slave status;
Empty set (0.00 sec)
MariaDB [sonnensystem]> CHANGE MASTER TO MASTER_HOST='masterserver' ,
-> MASTER_USER='repl',
-> MASTER_PASSWORD='slavepass',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='mariadb-bin.000001',
-> MASTER_LOG_POS=1741,
-> MASTER_CONNECT_RETRY=10;
MariaDB [sonnensystem]> START SLAVE;
Listing 11.23 Die Replikation starten
Der letzte Befehl erzeugt keine Fehlermeldungen oder Ausgaben. Untersuchen Sie jetzt noch einmal SHOW SLAVE STATUS:
MariaDB [sonnensystem]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: masterserver
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mariadb-bin.000001
Read_Master_Log_Pos: 1953
Relay_Log_File: mariadb-relay-bin.000002
Relay_Log_Pos: 741
Relay_Master_Log_File: mariadb-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1953
Relay_Log_Space: 1037
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
1 row in set (0.00 sec)
Listing 11.24 Am MariaDB-Prompt den Slave-Status anzeigen lassen
Der gerade neu hinzugefügte Datensatz (siehe Listing 11.22) sollte nun auf den Slave repliziert worden sein. Kontrollieren Sie dies durch eine einfache SELECT-Abfrage auf dem Slave:
MariaDB [(none)]> select * from planeten;
+------+--------+
| id | name |
+------+--------+
| 1 | Merkur |
| 2 | Venus |
| 3 | Erde |
+------+--------+
3 rows in set (0.00 sec)
Listing 11.25 Prüfen, ob der neue Datensatz repliziert wurde
Es hat funktioniert: Der Datensatz mit der ID 3 ist angekommen. Wenn Sie nun einen weiteren Datensatz auf dem Master anlegen, sollte er praktisch ohne Verzögerung auf dem Slave ankommen. Fügen Sie auf dem Master noch einen vierten Datensatz hinzu:
MariaDB [(none)]> insert into planeten values (4,'Mars');
Query OK, 1 row affected (0.00 sec)
Listing 11.26 Einen weiteren Datensatz auf dem Master hinzufügen
Mit der bekannten SELECT-Abfrage sollten Sie den Datensatz auf dem Slave sehen können.
MariaDB [(none)]> select * from planeten;
+------+--------+
| id | name |
+------+--------+
| 1 | Merkur |
| 2 | Venus |
| 3 | Erde |
| 4 | Mars |
+------+--------+
4 rows in set (0.00 sec)
Listing 11.27 Kontrolle auf dem Slave-Server
Damit haben Sie Ihre Master-Slave-Replikation erfolgreich getestet.
11.1.3 Master-Master-Replikation
Sie können die bestehende Master-Slave-Replikation mit nur geringem Aufwand zu einer Master-Master-Replikation erweitern. Dazu legen Sie zunächst auch auf dem jetzigen Slave-Server ein Benutzerkonto für die Replikation an:
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
-> TO repl@'192.168.1.%' IDENTIFIED BY 'slavepass';
oder
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
-> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
Listing 11.28 Einen weiteren Benutzer für die Replikation anlegen
Führen Sie nun – immer noch auf dem bisherigen Slave-Server – am MariaDB-Prompt das Kommando SHOW MASTER STATUS aus. Bitte setzen Sie vorher den »read lock«.
MariaDB [sonnensystem]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> show master status;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000002 | 98 | | |
+--------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
Listing 11.29 »show master status« auf dem bisherigen Slave-Server
Merken oder notieren Sie sich die Werte für File und Position. Sie benötigen diese Daten im nächsten Schritt.
Wechseln Sie nun auf den bisherigen Master-Server, und führen Sie am MariaDB-Prompt die Kommandos aus, die in Listing 11.30 hinter dem Prompt MariaDB [(none)]> stehen:
MariaDB [(none)]> show slave status;
Empty set (0.00 sec)
MariaDB [(none)]> change master to master_host='slaveserver',
-> master_user='repl',
-> master_password='slavepass',
-> master_log_file='mariadb-bin.000002',
-> master_log_pos=98,
-> master_connect_retry=10;
Query OK, 0 rows affected (0.01 sec)
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.01 sec)
MariaDB [(none)]> show slave status;
Slave_IO_State: Waiting for master to send event
Master_Host: slaveserver
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000002
Read_Master_Log_Pos: 98
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 235
Relay_Master_Log_File: mariadb-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)
Listing 11.30 Den bisherigen Slave zum zweiten Master-Server befördern
MariaDB [sonnensystem]> unlock tables;
Query OK, 0 rows affected (0.00 sec)
MariaDB [sonnensystem]> insert into planeten values (5,'Jupiter'),(6,'Saturn');
Query OK, 2 rows affected (0.01 sec)
Records: 2 Duplicates: 0 Warnings: 0
MariaDB [sonnensystem]> select * from planeten;
+------+---------+
| id | name |
+------+---------+
| 1 | Merkur |
| 2 | Venus |
| 3 | Erde |
| 4 | Mars |
| 5 | Jupiter |
| 6 | Saturn |
+------+---------+
6 rows in set (0.00 sec)
Listing 11.31 Zwei weitere Planeten anlegen
Das letzte SELECT-Statement in Listing 11.31 zeigt den Inhalt der Tabelle Planeten auf dem bisherigen Master-Server. Wenn Sie nun auf dem ehemaligen Slave-Server einen Datensatz hinzufügen, wird er auf den Master repliziert werden. Wechseln Sie also auf den Ex-Slave-Server, und fügen Sie der Tabelle einen weiteren Planeten hinzu:
MariaDB [sonnensystem]> insert into planeten values (7,'Uranus');
Query OK, 1 row affected (0.01 sec)
Listing 11.32 Einen Datensatz auf dem ehemaligen Slave-Server hinzufügen
Wechseln Sie nun zurück auf den Master-Server, und kontrollieren Sie, ob der Datensatz auch dorthin repliziert wurde (siehe Listing 11.33). Sollte das nicht der Fall sein, gehen Sie bitte die vorhergehenden Schritte noch einmal durch.
MariaDB [(none)]> select * from planeten;
+------+---------+
| id | name |
+------+---------+
| 1 | Merkur |
| 2 | Venus |
| 3 | Erde |
| 4 | Mars |
| 5 | Jupiter |
| 6 | Saturn |
| 7 | Uranus |
+------+---------+
7 rows in set (0.00 sec)
Listing 11.33 Erfolgskontrolle auf dem ehemaligen Master-Server
Ihre Master-Master-Replikation funktioniert.
[+] MariaDB erlaubt explizit die Ring-Replikation (Multi-Master-Replikation). Damit können Sie mehr als zwei Server zu einem Ring zusammenfassen. Wenn der Ring unterbrochen ist, ist an der Stelle auch die Replikation für alle beteiligten Server unterbrochen. Hier sind besondere Vorkehrungen zu treffen. Weitere Informationen dazu finden Sie auf den Webseiten, die von der folgenden URL verlinkt sind: https://mariadb.com/kb/en/library/multi-source-replication