MySQL-Replikation mit GTIDs

Moderne Replikation

Jahrelang waren Binary Logs das Fundament der MySQL-Replikation. Komplexe Setups stoßen dabei jedoch schnell an ihre Grenzen. Eine neue Strategie mit Transaktions-IDs als zentrales Element soll flexibler und einfacher sein. Was dahintersteckt und welche Vorteile Datenbank-Administratoren in der Praxis davon haben, beleuchtet dieser Artikel.
Die Zusammenarbeit und der Datenaustausch stehen im Mittelpunkt der Februar-Ausgabe des IT-Administrator. Darin betrachten wir die Teamarbeit mit Office 365 und ... (mehr)

Unter Datenbank-Replikation wird die Spiegelung von Datenbank-Änderungen zwischen mehreren Instanzen verstanden – von einem Master zu einem Slave. Dieses Setup erhöht primär die Verfügbarkeit der Datenbank, der Ausfall des Masters wird durch ein Umschalten auf den Slave kompensiert. Zusätzlich kann die Applikation den Slave aber auch für analytische SQL-Abfragen und Datenbank-Sicherungen nutzen, was ebenso den Master entlastet. Bisher ist die Replikation von MySQL-Datenbanken aber mit einigen Tücken verbunden, die Global Transaction IDs (GTID) künftig eliminieren sollen.

GTIDs sind die Zukunft

GTIDs wurden mit MySQL-Version 5.6 eingeführt, sind jedoch defaultmäßig nicht aktiviert. Der Begriff GTID lässt erahnen, dass jeder Transaktion eine eindeutige ID zugewiesen wird. Der Server, der die Transaktion durchführt, berechnet beim Commit die ID. Sie setzt sich aus zwei Teilen zusammen: der Server UUID und einer fortlaufenden Nummer der Transaktion.

Für ein bestehendes Replikationssetup zwischen Master und Slave(s) gilt ebenfalls, dass GTIDs eindeutig sein müssen. Über das gesamte Master-Slave-Gespann wird eine 1-zu-1-Zuordnung zwischen GTIDs und ausgeführten Transaktionen gepflegt. Diese Information reicht aus, um komplexe Setups zu betreiben, da die MySQL-Server stets wissen, welche Transaktionen auf welchen Servern bereits ausgeführt wurden [1]. Der GTID-Lebenszyklus im Detail:

1. Der Master führt eine Transaktion durch und wählt die nächste freie GTID aus. Für die Replikation werden beide Teile in das Binary Log geschrieben.

2. Die Binary Logs werden auf Seiten des Slave geholt und ins Relay Log übertragen. Der Slave liest die GTID aus und übernimmt den Wert in die Variable "gtid_next".

3. Bevor sich der Slave der Transaktion annimmt, prüft er, ob die GTID bereits in seinem eigenen Binary Log vorkommt. Nur wenn das nicht der Fall ist, führt der Slave die Transaktion durch.

4. Der Umweg über die Variable "gtid_ next" verhindert, dass der Slave eine neue GTID erstellt. Stattdessen korrelieren die Daten zwischen Master und Slave, was das GTID-Transaktions-Paar betrifft.

Wichtige GTID-Konfigurationsvariablen

Option

Funktion

[mysqld]

Der Konfigurationsabschnitt für den MySQL-Dienst

server-id = 1

Eine eindeutige ID, die dem Server zugeordnet wird.

report-host = mysql1

Ein Hostname/IP, mit dem sich der Slave beim Master registriert.

binlog-format = ROW

Die Art und Weise, mit der Datenänderungen in den Binary Logs aufgezeichnet werden.

binlog-rows-query-log_events = 1

Bei Binary Logs im ROW Format aktiviert diese Variable zusätzliche Debug-Informationen.

gtid-mode = on

Aktiviert GTIDs für die Replikation.

enforce-gtid-consistency = true

Stellt sicher, dass Statements unter GTIDs transaktionssicher sind.

log-slave-updates = true

Stellt sicher, dass die SQL-Threads der Slaves auch Binary Logs schreiben. In Setups mit GTIDs muss diese Option für alle Server aktiviert werden.

skip-slave-start = 1

Verhindert das automatische Starten des Slave-Threads beim Start des MySQL-Servers.

slave-sql-verify-checksum = 1

Der Slave prüft die im Relay Log enthaltenen Checksummen.

Am einfachsten lassen sich GTIDs einrichten, wenn keine Replikation zwischen Master und Slave besteht. Möchten Sie auf bestehenden Servern im Online-Betrieb zu GTIDs wechseln, müssen Sie einige Punkte beachten. Erst MySQL-Version 5.7.6 bietet die Möglichkeit, ohne Downtime auf GTIDs umzustellen [2]. Wer Version 5.6 im Einsatz hat, muss seine Server auf read-only setzen, sie stoppen und mit aktiver GTID-Konfiguration wieder starten [3]. Bevor Sie GTIDs aktivieren, muss sichergestellt sein, dass die MySQL-Statements der Applikation GTID-tauglich sind. Dazu aktivieren Sie ein Log-Level, das Warnungen ausgibt, falls Statements unter GTIDs nicht transaktionssicher sind:

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;

Zur Aktivierung ändern Sie die Variable später von "WARN" auf "ON". Damit ist sichergestellt, dass Transaktionen konsistent in den Binary Logs ankommen und repliziert werden. Tabelle 1 listet weitere wichtige Optionen auf, die für GTIDs in der MySQL-Konfiguration erforderlich sind. Nach einem Neustart des MySQL-Dienstes ist die GTID-Konfiguration aktiv, und ein eigener Replikationsbenutzer mit eingeschränkten Rechten wird erstellt:

root@mysql1:~# mysql -h localhost -u root -p -e "GRANT REPLICATION SLAVE ON *.* TO repl_user@10.66.100.2 IDENTIFIED BY 'password';"

Da es sich um einen frischen Slave ohne Daten handelt, wird initial ein Daten-Dump vom Master eingespielt:

root@mysql1:~# mysqldump -u root -p --all-databases --single-transaction --triggers --routines --events > repl_all.sql
root@mysql1:~# scp repl_all.sql root@10.66.100.2:/root
root@mysql2:~# mysql -u root -p < repl_all.sql

Dump-Befehl ist GTID-kompatibel

Auch mysqldump ist mittlerweile für den Umgang mit GTIDs gewappnet. Die Dump-Datei enthält die Variable "GTID_PURGED":

root@mysql1:~# grep GTID_PURGED repl_all.sql
SET @@GLOBAL.GTID_PURGED='e69b90da-a6bf-11e6-b838-00163e16992d:1-2';

Beim Einlesen des Dumps gleicht der Slave seine "Executed_ Gtid_Set"-Variable dem Wert aus der Dump-Datei an. Dadurch weiß er, von welchem Punkt er die Replikation starten muss [4]:

root@mysql2:~# mysql -u root -p -h 10.66.100.2 -e "show slave status \G" | grep Executed
Enter password:
Executed_Gtid_Set: e69b90da-[...]

Im letzten Schritt verbinden wir Master und Slave:

root@mysql2:~# mysql -u root -p
Enter password:
mysql> CHANGE MASTER TO MASTER_HOST='10.66.100.1', MASTER_USER='repl_user', MASTER_PASSWORD='password', MASTER_AUTO_POSITION=1;
mysql> start slave;

Die Option "MASTER_AUTO_POSITION" ist erst seit der Einführung von GTIDs relevant. Ohne GTIDs treten hier "Binary Log Position" und "Datei" an die Stelle der "MASTER_AUTO_POSITION".

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019