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).
Listing 1: Topologie anzeigen
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).
Listing 2: Switchover zwischen Master und Slave
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.
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.
Vor- und Nachteile von GTID
- Setup von Replikation mit MASTER_AUTO_POSITION sehr einfach.- Mehrere Master-Slaves, auch kaskadiert, einfach aufzubauen.- Nachvollziehbarkeit und Konsistenz über Master und Slave hinweg.- Einfacher Failover zwischen Master und Slave, auch automatisiert über Skripte.- Bis MySQL-Version 5.7.5 muss auf allen Servern log_slave_updates aktiviert sein [6].- Online Migration erst ab MySQL-Version 5.7.6 möglich, zuvor müssen alle Server gestoppt werden.- Keine Updates auf MyISAM und InnoDB-Tabellen in der selben Transaktion.- CREATE und DROP TEMPORARY TABLE sind innerhalb einer Transaktion nicht möglich.- CREATE TABLE SELECT Statements sind innerhalb einer Transaktion nicht möglich.