MySQL 5.6 GTID neue Funktion practice_MySQL

GTID-Einführung

Was ist GTID

GTID (Global Transaction ID) ist die Nummer einer übermittelten Transaktion und eine weltweit eindeutige Nummer.

GTID besteht eigentlich aus UUID+TID. Die UUID ist die eindeutige Kennung einer MySQL-Instanz. TID stellt die Anzahl der Transaktionen dar, die auf dieser Instanz festgeschrieben wurden, und steigt monoton an, wenn Transaktionen festgeschrieben werden. Das Folgende ist die spezifische Form einer GTID

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

Eine ausführlichere Einführung finden Sie unter: Offizielle Dokumentation

Die Rolle von GTID

Was ist also der Zweck der GTID-Funktion? Die spezifische Zusammenfassung umfasst hauptsächlich die folgenden zwei Punkte:

Anhand der GTID können Sie erkennen, auf welcher Instanz die Transaktion ursprünglich übermittelt wurde. Das Vorhandensein der GTID erleichtert das Failover der Replikation. Der zweite Punkt wird hier ausführlich erläutert. Wir können einen Blick auf den Vorgang des Replikations-Failovers werfen, bevor die GTID von MySQL 5.6 erschien. Angenommen, wir haben eine Umgebung wie unten

Zu diesem Zeitpunkt ist der Server von Server A ausgefallen und das Unternehmen muss auf Server B umgestellt werden. Gleichzeitig müssen wir die Replikationsquelle von Server C auf Server B ändern. Die Befehlssyntax für die Änderung der Kopierquelle ist sehr einfach, nämlich CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn. Die Schwierigkeit besteht darin, dass es zu einem Problem wird, den aktuellen Synchronisationsstopppunkt von Server C und die entsprechenden Werte für „master_log_file“ und „master_log_pos“ von Server B zu finden, da dieselbe Transaktion auf jedem Computer unterschiedliche Binlog-Namen und Speicherorte hat. Dies ist ein wichtiger Grund, warum M-S-Replikationscluster zusätzliche Verwaltungstools wie MMM und MHA verwenden müssen.

Dieses Problem wird nach dem Aufkommen von GTID in 5.6 sehr einfach. Da die GTID derselben Transaktion auf allen Knoten den gleichen Wert hat, kann die GTID auf Server B anhand der GTID des aktuellen Stopppunkts von Server C eindeutig lokalisiert werden. Selbst aufgrund der Entstehung der Funktion MASTER_AUTO_POSITION müssen wir den spezifischen Wert von GTID nicht kennen. Wir können den Befehl CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION direkt verwenden, um die Failover-Arbeit abzuschließen. So einfach, nicht wahr?

Einführung in die GTID-basierte Master-Slave-Replikation

Bauen

Basierend auf dem mysql_sandbox-Skript wurde zunächst eine standortbasierte Replikationsumgebung mit einem Master und drei Slaves erstellt. Durch Konfigurationsänderungen wird dann die gesamte Architektur für die GTID-basierte Replikation ausgelegt.

Gemäß den GTID-Konstruktionsvorschlägen in der offiziellen MySQL-Dokumentation. Es ist notwendig, die Konfiguration der Master- und Slave-Knoten einmal zu ändern und den Dienst neu zu starten. Ein solcher Vorgang ist bei einem Upgrade in einer Produktionsumgebung offensichtlich nicht akzeptabel. Facebook, Booking.com und Percona haben dies allesamt durch Patches optimiert und elegantere Upgrades erreicht. Die spezifischen Betriebsmethoden werden in zukünftigen Blogbeiträgen vorgestellt. Hier werden wir ein experimentelles Upgrade gemäß der offiziellen Dokumentation durchführen.

Die wichtigsten Upgrade-Schritte sind wie folgt:

Stellen Sie die Master-Slave-Synchronisation sicher, um sicherzustellen, dass keine neuen Daten zum Ändern von my.cnf auf dem Master geschrieben werden auf dem Slave und aktivieren Sie die GTID-basierte Replikation auf master_auto_position=1. Da es sich um eine experimentelle Umgebung handelt, ist es keine große Sache, read_only und den Dienst neu zu starten. Solange Sie die offiziellen GTID-Konstruktionsempfehlungen befolgen, können Sie das Upgrade erfolgreich abschließen. Der detaillierte Prozess wird hier nicht beschrieben. Nachfolgend sind einige Fehler aufgeführt, die während des Upgrade-Vorgangs leicht auftreten können.

Häufige Fehler

Die drei Parameter „gtid_mode=ON“, „log_slave_updates“ und „force_gtid_consistency“ müssen gleichzeitig in my.cnf konfiguriert werden. Andernfalls wird in mysql.err

der folgende Fehler angezeigt

2016-10-08 20:11:08 32147 [FEHLER] --gtid-mode=ON oder UPGRADE_STEP_1 oder UPGRADE_STEP_2 erfordert --log-bin und --log-slave-updates
08.10.2016 20:13:53 32570 [FEHLER] --gtid-mode=ON oder UPGRADE_STEP_1 erfordert --enforce-gtid-consistency

Warnungen nach dem Wechsel des Masters zu

Nachdem Sie gemäß der Dokumentation „master“ auf „master“ geändert haben, werden Sie zwei Warnungen finden. Tatsächlich handelt es sich um zwei Sicherheitswarnungen, die sich nicht auf die normale Synchronisierung auswirken (interessierte Leser können die ausführliche Einleitung dieser Warnung lesen. Der spezifische Inhalt der Warnung lautet wie folgt:

slave1 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.03 sec)
slave1 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave1 [localhost] {msandbox} ((none)) > show warnings;
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1759 | Sending passwords in plain text without SSL/TLS is extremely insecure. |
| Note | 1760 | Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Experiment 1: Wenn die GTID, die der vom Slave benötigten Transaktion entspricht, auf dem Master gelöscht wurde

Den Befehlsergebnissen zum Anzeigen globaler Variablen wie „%gtid%“ können wir entnehmen, dass es unter den Variablen, die sich auf die GTID beziehen, ein gtid_purged gibt. Aus der wörtlichen Bedeutung und der offiziellen Dokumentation können wir erkennen, dass in dieser Variablen der gtid_set aufgezeichnet ist, der auf dem lokalen Computer ausgeführt, aber durch den Befehl „purge Binary Logs to“ bereinigt wurde.
In diesem Abschnitt testen wir, was passiert, wenn der Master einige gtid-Ereignisse löscht, die nicht vom Slave abgerufen wurden.

Die folgenden Anweisungen werden auf dem Master ausgeführt

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+----------------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+----------------------------------------+
7 rows in set (0.01 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test2 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.02 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test3 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.04 sec)
master [localhost] {msandbox} (test) > show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000005 | 359 | | | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
master [localhost] {msandbox} (test) > purge binary logs to 'mysql-bin.000004';
Query OK, 0 rows affected (0.03 sec)
master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave2上重新做一次主从，以下命令在slave2上执行

slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
......
Slave_IO_Running: No
Slave_SQL_Running: Yes
......
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 151
......
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
......
Auto_Position: 1
1 row in set (0.00 sec)

实验二：忽略purged的部分，强行同步

那么实际生产应用当中，偶尔会遇到这样的情况：某个slave从备份恢复后（或者load data infile）后，DBA可以人为保证该slave数据和master一致；或者即使不一致，这些差异也不会导致今后的主从异常（例如：所有master上只有insert没有update）。这样的前提下，我们又想使slave通过replication从master进行数据复制。此时我们就需要跳过master已经被purge的部分，那么实际该如何操作呢？

我们还是以实验一的情况为例：

先确认master上已经purge的部分。从下面的命令结果可以知道master上已经缺失24024e52-bd95-11e4-9c6d-926853670d0b:1这一条事务的相关日志

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

slave2 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';
Query OK, 0 rows affected (0.05 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G 
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
......
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 359
Relay_Log_File: mysql_sandbox21290-relay-bin.000004
Relay_Log_Pos: 569
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Exec_Master_Log_Pos: 359
Relay_Log_Space: 873
......
Master_Server_Id: 1
Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b
Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
......
Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3
Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3
Auto_Position: 1
1 row in set (0.00 sec)

可以看到此时slave已经可以正常同步，并补齐了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范围的binlog日志。

以上所述是小编给大家介绍的MySQL 5.6 GTID新特性实践，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！