Umfassende Zusammenfassung zu MySQL GTID

Umfassende Zusammenfassung zu MySQL GTID

01 Einführung in GTID

GTID, der vollständige Name der Global Transaction Identifiers, wird auch Global Transaction ID genannt. MySQL-5.6.2 wurde unterstützt und MySQL-5.6.10 wurde verbessert. GTID ist in zwei Teile unterteilt. Ein Teil ist die UUID des Dienstes. Die UUID wird in der Datei auto.cnf im MySQL-Datenverzeichnis gespeichert.
Dies ist eine sehr wichtige Datei und kann nicht gelöscht werden. Dieser Teil wird sich nicht ändern. Das Folgende ist ein Beispiel für einen UUID-Wert:

[root@dev01 mysql]# cat auto.cnf
 [Auto]
server-uuid=ac1ebad0-ef76-11e7-872b-080027a03bb6

Der andere Teil ist die Transaktions-ID. Mit zunehmender Anzahl der Transaktionen steigt der Wert. Mit anderen Worten: GTID besteht eigentlich aus UUID+TID. Die UUID ist die eindeutige Kennung einer MySQL-Instanz. TID stellt die Anzahl der Transaktionen dar, die auf der Instanz festgeschrieben wurden. Das Folgende ist ein Beispiel für eine GTID:

3db33b36-0e51-409f-a61d-c99756e90155:1-14

02 Wie GTID funktioniert

1. Wenn der Master Daten aktualisiert, generiert er vor der Transaktion eine GTID und zeichnet sie im Binlog-Protokoll auf.
2. Der E/A-Thread des Slaves schreibt das geänderte Binärprotokoll in das lokale Relay-Protokoll.
3. Der SQL-Thread erhält die GTID aus dem Relay-Protokoll und vergleicht dann, ob im Binärprotokoll auf der Slave-Seite ein Datensatz vorhanden ist.
4. Wenn ein Datensatz vorhanden ist, bedeutet dies, dass die Transaktion der GTID ausgeführt wurde und der Slave sie ignoriert.
5. Wenn kein Datensatz vorhanden ist, führt der Slave die Transaktion der GTID aus dem Relay-Protokoll aus und zeichnet sie im Binärprotokoll auf.
6. Während des Analysevorgangs wird ermittelt, ob ein Primärschlüssel vorhanden ist. Wenn nicht, wird der Sekundärindex verwendet. Wenn nicht, wird ein vollständiger Scan durchgeführt.

03 Vor- und Nachteile von GTID

Vorteil:

1. Eine Transaktion entspricht einer eindeutigen GTID, und eine GTID wird nur einmal auf einem Server ausgeführt
2.GTID wird verwendet, um die herkömmliche Replikationsmethode zu ersetzen. Der größte Unterschied zwischen der GTID-Replikation und dem normalen Replikationsmodus besteht darin, dass keine Angabe des Binärdateinamens und des Speicherorts erforderlich ist
3. Reduzieren Sie manuelle Eingriffe und Service-Ausfallzeiten. Wenn die Hauptmaschine ausfällt, kann die Software eine Backup-Maschine aus einer großen Anzahl von Backup-Maschinen zur Hauptmaschine machen.

Mangel:

1. Nicht-transaktionale Engines werden nicht unterstützt
2. Die Replikation der Anweisung „create table ... select“ wird nicht unterstützt (die Master-Datenbank meldet direkt einen Fehler).
Prinzip: (Es werden zwei SQLs generiert, eines ist das DDL zum Erstellen des Tabellen-SQL und das andere ist das Einfügen in SQL zum Einfügen von Daten.
Da DDL eine automatische Übermittlung bewirkt, erfordert dieses SQL mindestens zwei GTIDs, im GTID-Modus kann für dieses SQL jedoch nur eine GTID generiert werden.
3. Eine SQL-Anweisung darf nicht gleichzeitig eine Transaktions-Engine-Tabelle und eine Nicht-Transaktions-Engine-Tabelle aktualisieren.
4. Das Aktivieren von GTID erfordert einen Neustart (außer 5.7)
5. Die Anweisungen „Create Temporary Table“ und „Drop Temporary Table“ werden nicht unterstützt.
6. sql_slave_skip_counter wird nicht unterstützt

04 Aufbau der Testumgebung

Knoten:
Server1 192.168.197.128 3306 Meister
Server2 192.168.197.137 3306 Sklave
server3 192.168.197.136 3306 Sklave

Um GTID zu aktivieren, müssen Sie diese drei Parameter aktivieren:

gtid_mode = ein

enforce_gtid_consistency = 1

log_slave_updates = 1

Die Schritte zum Erstellen einer Testumgebung sind wie folgt:

1. Erstellen Sie einen Replikationsbenutzer auf dem Masterknoten und aktivieren Sie die GTID-Option des Masterknotens.

mysql> gewähre 'Repluser'@'%', identifiziert durch '123456', Replikations-Slave auf *.*;
Abfrage OK, 0 Zeilen betroffen, 1 Warnung (0,00 Sek.)

2. Führen Sie den Vorgang „Vom Master zum Slave“ auf dem Slave-Knoten aus, um die Master-Slave-Beziehung wie folgt aufzubauen:

mysql> ändere Master in
     -> master_host='192.168.197.128',
    -> master_user='repluser',
    -> Master-Passwort = '123456',
    -> Master-Port = 3306,
    -> master_auto_position=1;
Abfrage OK, 0 Zeilen betroffen, 2 Warnungen (0,01 Sek.)

3. Überprüfen Sie nach erfolgreicher Installation, ob der Slave-Knoten dem Master-Knoten 197.128 beigetreten ist:

mysql> Slave-Hosts anzeigen;
+-----------+------+------+----------+--------------------------------------+
| Server-ID | Host | Port | Master-ID | Slave-UUID |
+-----------+------+------+----------+--------------------------------------+
| 3 | | 3306 | | 969488f5-c486-11e8-adb7-000c29bf2c97 |
| 2 | | 3306 | | bb874065-c485-11e8-8b52-000c2934472e |
+-----------+------+------+----------+--------------------------------------+
 Zeilen im Set (.sec)

Zeigen Sie die Verbindung an:

mysql> Prozessliste anzeigen;
+----+----------+------------------+------+------------------+------+---------+----------------------------------------------------------+------------------+
| ID | Benutzer | Host | db | Befehl | Zeit | Status | Info |
+----+----------+------------------+------+------------------+------+---------+----------------------------------------------------------+------------------+
| | root | localhost | NULL | Abfrage | 0 | wird gestartet | Prozessliste anzeigen |
| 3 | repluser | work_NAT_4:60051 | NULL | Binlog Dump GTID | | Der Master hat das gesamte Binlog an den Slave gesendet; warte auf weitere Aktualisierungen | NULL |
| | repluser | work_NAT_5: | NULL | Binlog Dump GTID | 5970 | Der Master hat das gesamte Binlog an den Slave gesendet; warte auf weitere Aktualisierungen | NULL |
+----+----------+------------------+------+------------------+------+---------+----------------------------------------------------------+------------------+
 Zeilen im Set (.sec)

4. Die UUIDs der drei Testumgebungen sind:

197.128
mysql> wähle @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| bd0d-8691-11e8-afd6-4c3e51db5828 |
+--------------------------------------+
 Zeile im Satz (0,00 Sek.)

197.137
mysql> wähle @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
|bb874065-c485-11e8-8b52-000c2934472e |
+--------------------------------------+
 Zeile im Satz (0,00 Sek.)

197.136
mysql> wähle @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
|f5-c486-11e8-adb7-000c29bf2c97 |
+--------------------------------------+
 Zeile im Satz (0,00 Sek.)

05 Test starten

Die Testumgebung gliedert sich im Wesentlichen in folgende Aspekte:

a. Testen des Replikations-Failovers

b. Kopierfehler überspringen

1 Testen des Replikations-Failovers

Schauen wir uns zunächst das Failover der Testreplikation an:

(1) Stoppen Sie zunächst den Replikationsprozess von Server 3

mysql> Slave stoppen;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

(2) Erstellen Sie einige Daten auf Server 1

mysql> Tabelle yyy.a erstellen (id int);
Abfrage OK, 0 Zeilen betroffen (0,03 Sek.)

mysql> Tabelle yyy.b erstellen (ID int);
Abfrage OK, 0 Zeilen betroffen (0,02 Sek.)

mysql> Tabelle yyy.c erstellen (id int);
Abfrage OK, 0 Zeilen betroffen (0,02 Sek.)

(3) Überprüfen Sie die Datenergebnisse auf den beiden anderen Maschinen:

Server 
mysql> Tabellen ab yyy anzeigen;
+-----------------+
| Tabellen_in_yyy |
+-----------------+
| ein |
| b |
| c |
+-----------------+
 Zeilen im Set (0,00 Sek.)

Server 
mysql> Tabellen ab yyy anzeigen;
Leerer Satz (0,00 Sek.)

(4) An diesem Punkt können wir feststellen, dass die Daten auf Server 2 neuer sind als die auf Server 3. Wir stoppen dann Server 1, um einen Absturz auf dem primären Server zu simulieren:

[root@work_NAT_1 init.d]# Dienst mysqld stop
MySQL wird heruntergefahren............ [ OK ]

(5) An diesem Punkt stellen wir fest, dass die anderen beiden Knoten nicht mehr auf Server 1 zugreifen können

mysql> Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
        Slave_IO_State: Wiederverbindung nach fehlgeschlagenem Lesen des Master-Ereignisses
         Master_Host: 192.168.197.128
         Master_Benutzer: repluser
         Master_Port: 3306
        Verbindungswiederholung: 60
       Master_Log_File: mysql-bin.000006
     Read_Master_Log_Pos: 1364
        Relay-Log-Datei:mysql-relay-bin.000004
        Relay_Log_Pos: 1569
    Relay_Master_Log_File: mysql-bin.000006
       Slave_IO_Running: Verbindung wird hergestellt
      Slave_SQL_Running: Ja
     Exec_Master_Log_Pos: 1364
       Relay_Log_Space: 2337 
        Master_SSL_Schlüssel: 
    Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: Nein
        Last_IO_Errno: 2003
        Last_IO_Error: Fehler beim erneuten Verbinden mit Master „[email protected]:3306“ – Wiederholungszeit: 60 Wiederholungen: 1
        Last_SQL_Errno: 0

(6) Wir müssen Server 2 als primäre Datenbank für Server 3 festlegen, da die Daten auf Server 2 neuer sind. Wenn Sie zu diesem Zeitpunkt die vorherige Methode verwenden, müssen Sie die log_pos der vorherigen Hauptdatenbank und die log_pos berechnen, die als aktuelle Hauptdatenbank festgelegt werden soll, was wahrscheinlich schief geht. Daher sind einige Hochverfügbarkeitstools wie MHA und MMM entstanden, um das Problem zu lösen.

Nach MySQL 5.6 konnte dieses Problem leicht gelöst werden. Da die GTID derselben Transaktion auf allen Knoten den gleichen Wert hat, lässt sich die GTID auf Server2 anhand der GTID des aktuellen Haltepunkts auf Server3 lokalisieren, sodass man die Änderung direkt auf Server3 ausführen kann:

mysql> ändere Master in 
  -> master_host='192.168.197.137',
  -> master_user='repluser',
  -> Master-Passwort = '123456',
  -> master_port=,
  -> master_auto_position=;
Abfrage OK, betroffene Zeilen, Warnungen (0,01 Sek.)

(7) Überprüfen Sie nun die Daten auf Server 3 und Sie werden feststellen, dass die Daten synchronisiert wurden.

2 Kopierfehler überspringen

Im obigen Test ist das Endergebnis, dass Server 2 der primäre Knoten und Server 3 der sekundäre Knoten ist. Lassen Sie uns nun die Methode zum Überspringen von Replikationsfehlern überprüfen.

(1) Zuerst führen wir eine Drop-Anweisung auf dem Slave-Knoten aus, um die Daten auf beiden Seiten wie folgt inkonsistent zu machen:

mysql> Datenbanken anzeigen;
+--------------------+
| Datenbank |
+--------------------+
| Informationsschema |
| Datenbankadministratoren |
| Kunde |
| inc_db |
|mysql |
| Leistungsschema |
|System|
|testdb|
|juhuu|
|yyy|
+--------------------+
 Zeilen im Set (.sec)

mysql> Datenbank yyy löschen;
Abfrage OK, Zeilen betroffen (. Sek.)

mysql> Datenbanken anzeigen;
+--------------------+
| Datenbank |
+--------------------+
| Informationsschema |
| Datenbankadministratoren |
| Kunde |
| inc_db |
|mysql |
| Leistungsschema |
|System|
|testdb|
|juhuu|
+--------------------+
 Zeilen im Set (.sec)

(2) Anschließend führen wir die Operation „Drop Database yyy“ auf Server 2 wie folgt aus:

mysql> Datenbank yyy löschen;
Abfrage OK, 3 Zeilen betroffen (0,02 Sek.)

(3) An diesem Punkt sehen wir, dass auf Server 3 die Fehlermeldung „Master-Slave-Synchronisation nicht möglich“ angezeigt wird, da dieser nicht über die yyy-Datenbank verfügt (sie wurde im vorherigen Schritt gelöscht). Der Fehler lautet wie folgt:

mysql> Slave-Status anzeigen\G
*************************** . Reihe ***************************
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: 192.168.197.137
         Master_Benutzer: repluser
         Master_Port: 
        Verbinden_Wiederholen: 
       Master_Log_File: mysql-bin.
     Read_Master_Log_Pos: 
        Relay-Log-Datei: mysql-relay-bin.
        Relay_Log_Pos: 
    Relay_Master_Log_File: mysql-bin.
       Slave_IO_Running: Ja
      Slave_SQL_Running: Nein
          Letzte_Fehlernummer: 
          Last_Error: Fehler „Datenbank ‚yyy‘ kann nicht gelöscht werden; Datenbank existiert nicht“ bei Abfrage. Standarddatenbank: ‚yyy‘. Abfrage: ‚Datenbank yyy löschen‘
         Zähler überspringen: 
     Exec_Master_Log_Pos: 
       Relay_Log_Space: 
        Last_SQL_Error: Fehler „Datenbank ‚yyy‘ kann nicht gelöscht werden; Datenbank existiert nicht“ bei Abfrage. Standarddatenbank: ‚yyy‘. Abfrage: ‚Datenbank yyy löschen‘
 Server-IDs replizieren_ignorieren: 
       Master_Server_Id: 
         Master_UUID: bb874065-c485-e8-b52-c2934472e
       Master_Info_Datei: mysql.slave_master_info
      Abgerufen_Gtid_Set: bd0d--e8-afd6-c3e51db5828:-,
bb874065-c485-e8-b52-c2934472e:
      Ausgeführtes_Gtid_Set: db33b36-e51-f-a61d-c99756e90155:-,
bd0d--e8-afd6-c3e51db5828:-,
f5-c486-e8-adb7-c29bf2c97:
        Auto_Position: 
     DB replizieren_neu schreiben: 
         Kanalname: 
      Master_TLS_Version: 
 Zeile im Satz (0,00 Sek.)

(4) Wenn wir diesen Fehler mit der herkömmlichen Methode überspringen, wird wie folgt eine Meldung angezeigt, dass er im GTID-Modus nicht zulässig ist:

mysql> globalen sql_slave_skip_counter festlegen=;
FEHLER (HY000): sql_slave_skip_counter kann nicht gesetzt werden, wenn der Server mit @@GLOBAL.GTID_MODE = ON läuft. Generieren Sie stattdessen für jede Transaktion, die Sie überspringen möchten, eine leere Transaktion mit derselben GTID wie die Transaktion

Wie kann man diesen Fehler auf diese Weise umgehen?

(5) Da wir über GTID replizieren, müssen wir auch diese Transaktion überspringen und mit der Replikation fortfahren. Diese Transaktion kann im Binlog auf dem Master angezeigt werden. Da wir nicht wissen, welche GTID den Fehler verursacht hat, wissen wir nicht, wie wir welche GTID überspringen können. Allerdings können wir POS:2012 im ausführenden Master anhand der Informationen in „show slave status“ finden. Dabei handelt es sich um die 18. Codezeile in Schritt (3) oben. Nun suchen wir mit pos:2012 im Log von Server 2 und finden folgende Informationen:

# Stand 2012
#190305 20:59:07 Server-ID 2 End-Log-Pos 2073 GTID last_committed=9 Sequenznummer=10 rbr_only=nein
SETZEN @@SESSION.GTID_NEXT= 'bb874065-c485-11e8-8b52-000c2934472e:1'/*!*/;
# bei 2073
#190305 20:59:07 Server-ID 2 End-Log-Pos 2158 Abfrage Thread-ID = 3 Exec-Zeit = 0 Fehlercode = 0
ZEITSTEMPEL FESTLEGEN=/*!*/;
Datenbank löschen yyy
/*!*/;

(6) Wir können sehen, dass der Wert von GTID_NEXT ist

, und dann stellen wir die Master-Slave-Replikation mit der folgenden Methode wieder her:

mysql> Slave stoppen;
Abfrage OK, Zeilen betroffen (0,00 Sek.)

mysql> Sitzung festlegen gtid_next='bb874065-c485-11e8-8b52-000c2934472e:1';
Abfrage OK, Zeilen betroffen (0,00 Sek.)

mysql> beginnen;
Abfrage OK, Zeilen betroffen (0,00 Sek.)

mysql> festschreiben;
Abfrage OK, Zeilen betroffen (0,01 Sek.)

mysql> Sitzung festlegen gtid_next=automatisch;
Abfrage OK, Zeilen betroffen (0,00 Sek.)

mysql> Slave starten;
Abfrage OK, Zeilen betroffen (0,00 Sek.)

mysql> Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: 192.168.197.137
         Master_Benutzer: repluser
         Master_Port: 3306
        Verbindungswiederholung: 60
       Master_Log_File:mysql-bin.000002
     Read_Master_Log_Pos: 2158
        Relay-Log-Datei:mysql-relay-bin.000003
        Relay_Log_Pos: 478
    Relay_Master_Log_File: mysql-bin.000002
       Slave_IO_Running: Ja
      Slave_SQL_Running: Ja
     Exec_Master_Log_Pos: 2158
       Relay_Log_Space: 1527
       Until_Condition: Keine
       Master_Server_Id: 2
         Master_UUID: bb874065-c485-11e8-8b52-000c2934472e
       Master_Info_Datei: mysql.slave_master_info
          SQL_Delay: 0
     SQL_Remaining_Delay: NULL
   Slave_SQL_Running_State: Slave hat alle Relay-Logs gelesen; wartet auf weitere Updates
      Master_Retry_Count: 
      Abgerufen_Gtid_Set: bd0d-8691-11e8-afd6-4c3e51db5828:-7,
bb874065-c485-11e8-8b52-000c2934472e:
      Ausgeführtes_Gtid_Set: db33b36-0e51-409f-a61d-c99756e90155:-14,
bd0d-8691-11e8-afd6-4c3e51db5828:-7,
f5-c486-11e8-adb7-000c29bf2c97:,
bb874065-c485-11e8-8b52-000c2934472e:
        Auto_Position: 
     DB replizieren_neu schreiben: 
         Kanalname: 
      Master_TLS_Version: 
 Zeile im Satz (0,00 Sek.)

Das Obige ist der detaillierte Inhalt der umfassenden Zusammenfassung von MySQL GTID. Weitere Informationen zu MySQL GTID finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • MySQL-Datenbank GTID realisiert Master-Slave-Replikation (super praktisch)
  • Ein Beispiel für die Umstellung der traditionellen Replikation auf GTID-Replikation ohne Geschäftsunterbrechung in MySQL 5.7
  • Aktivieren oder Deaktivieren des GTID-Modus in MySQL online

<<:  CSS Sticky Footer Mehrere Implementierungen

>>:  So ändern Sie das Root-Passwort von MySQL in Docker

Artikel empfehlen

Angular Cookie Lese- und Schreibvorgangscode

Lese- und Schreibvorgänge bei Angular Cookies, de...

Linux-Installation MySQL5.6.24 Nutzungsanweisungen

Hinweise zur Linux-Installation von MySQL 1. Stel...

So mounten Sie eine Festplatte in Linux

Wenn Sie eine virtuelle Maschine verwenden, stell...

Detaillierte Erläuterung der Komponentenentwicklung des Vue-Dropdown-Menüs

In diesem Artikelbeispiel wird der spezifische Co...

Detaillierte Erklärung zur Installation der PHP-Curl-Erweiterung unter Linux

Dieser Artikel beschreibt, wie man die PHP-Curl-E...

MySQL 8.0.20 Installations- und Konfigurations-Tutorial unter Docker

Docker installiert MySQL Version 8.0.20 zu Ihrer ...

Fehler beim reduzierten Tabellenzeilenelement

Nehmen wir ein Beispiel: Der Code ist sehr einfach...

JavaScript zum Erzielen eines Vollbild-Seiten-Scrolleffekts

Nachdem ich mit der Lektüre von JavaScript DOM fe...

So verwenden Sie CSS-Medienabfragen mit einem geringeren Seitenverhältnis

CSS-Medienabfragen haben ein sehr praktisches Sei...

Detaillierte Erklärung des Unterschieds zwischen CSS-Link und @import

Wie fügt man CSS in HTML ein? Es gibt drei Möglic...

Detaillierte Erläuterung gängiger Methoden der Vue-Entwicklung

Inhaltsverzeichnis $nächsterTick() $forceUpdate()...