MySQL-Utilities für GTIDs

In erster Linie vereinfachen GTIDs Failover und Switchover zwischen Master und Slave, optimalerweise ohne manuelles Eingreifen und ohne Service-Downtime [5]. Die aktuelle Version installieren Sie am besten aus dem MySQL-Repository:

root@mysql1:~# wget https://dev.mysql.com/get/mysql-apt-config_0.8.0-1_all.deb

root@mysql1:~# dpkg -i mysql-apt-config_0.8.0-1_all.deb

Die Utilities sind einfacher mit vorkonfigurierten Login-Dateien verwendbar, darin enthalten sind Benutzer und Passwort für den MySQL-Client ("/etc/mysql/login/login-master.cnf"). Im ersten Schritt wird die aktuelle Master-Slave-Topologie aufgelistet (Listing 1).

root@mysql1:~# /usr/bin/mysqlrplshow --master=/etc/mysql/login/login-master.cnf --discover-slaves-login=root:password --format=csv --show-list
# master on 10.66.100.1: ... connected.
# Finding slaves for master: 10.66.100.1:3306
# Replication Topology Graph
10.66.100.1:3306 (MASTER)
      |
      +--- mysql2:3306 – (SLAVE)
Master,Slave
10.66.100.1:3306,mysql2:3306

Bevor wir auf einen Slave umschwenken, unterziehen wir seinem Replikationsstatus mehrere Tests:

$ /usr/bin/mysqlrplcheck --master=/etc/mysql/login/login-master.cnf --slave=/etc/mysql/login/login-slave.cnf

Das Werkzeug "mysqlrpladmin" zeigt, wie einfach ein Switchover zwischen Master und Slave mit GTIDs ist. Das manuelle Hantieren mit Binlog-Datei und Position entfällt komplett (Listing 2).

root@mysql1:~# /usr/bin/mysqlrpladmin --master=/etc/mysql/login/login-master.cnf --new-master=/etc/mysql/login/login-slave.cnf --slaves=/etc/mysql/login/login-slave.cnf --demote-master switchover
# Checking privileges.
# Performing switchover from master at 10.66.100.1:3306 to slave at 10.66.100.2:3306.
# Checking candidate slave prerequisites.
# Checking slaves configuration to master.
# Waiting for slaves to catch up to old master.
# Stopping slaves.
# Performing STOP on all slaves.
# Demoting old master to be a slave to the new master.
# Switching slaves to new master.
# Starting all slaves.

Vor- und Nachteile

Auf den ersten Blick sehen GTIDs einfach und sehr praktisch aus. Sie müssen sich aber bewusst sein, dass hinter der Technologie eine völlig neue Art der Replikation steckt. Deshalb sollten Sie auch GTIDs ausreichend mit ihrer eigenen Applikation testen und sich mit der Replikation zuerst vertraut machen, bevor Sie sie produktiv einsetzen. Ein gutes Beispiel, das zeigt, was sich mit GTIDs ändert, ist die Reparatur eines fehlerhaften Slaves. In vielen Setups ist es üblich, Statements zu überspringen, die am Slave Fehler verursachen – "sql_slave_skip_counter" wird dazu entsprechend angepasst. Mit GTIDs ändert sich die Vorgehensweise, ein Statement kann nicht einfach übersprungen werden. Stattdessen wird dem Slave eine leere Transaktion mit der fehlerhaften GTID injiziert. Der Kasten "Vor- und Nachteile von GTIDs" führt noch einmal Nutzen und Nachteil der neuen Technologie auf.