Detaillierte Erläuterung der MySQL Master-Slave-Replikationspraxis - GTID-basierte Replikation

GTID-basierte Replikation

Einführung

Die GTID-basierte Replikation ist eine neue Replikationsmethode, die nach MySQL 5.6 hinzugefügt wurde.

GTID (Global Transaction Identifier) ​​ist eine globale Transaktions-ID, die sicherstellt, dass jede an die Masterdatenbank übermittelte Transaktion im Cluster eine eindeutige ID hat.

Bei der ursprünglichen protokollbasierten Replikation muss der Slave dem Master mitteilen, welcher Offset für die inkrementelle Synchronisierung verwendet werden soll. Wenn die Angabe falsch ist, gehen Daten verloren, was zu Dateninkonsistenzen führt.

Bei der GTID-basierten Replikation informiert die Slave-Datenbank die Master-Datenbank über den GTID-Wert der ausgeführten Transaktion. Anschließend gibt die Master-Datenbank eine Liste der GTIDs aller nicht ausgeführten Transaktionen an die Slave-Datenbank zurück. Außerdem kann garantiert werden, dass dieselbe Transaktion in der angegebenen Slave-Datenbank nur einmal ausgeführt wird.

Tatsächlicher Kampf

1. Erstellen Sie ein Replikationskonto auf der Masterdatenbank und erteilen Sie Berechtigungen

Bei der GTID-basierten Replikation werden Transaktionen, die nicht auf dem Slave ausgeführt wurden, automatisch wiederholt. Erstellen Sie daher nicht dasselbe Konto auf anderen Slaves. Wenn dasselbe Konto erstellt wird, kann dies zu Fehlern im Replikationslink führen.

mysql> Benutzer „repl“@„172.%“ erstellen, identifiziert durch „123456“;

Beachten Sie, dass das Passwort in der Produktion den entsprechenden Vorgaben entsprechen muss, um eine gewisse Passwortstärke zu erreichen und es erforderlich ist, dass auf die Master-Datenbank nur über ein bestimmtes Netzwerksegment auf die Slave-Datenbank zugegriffen werden kann.

mysql> gewähre 'repl'@'172.%' Replikations-Slave auf *.*;

Benutzer anzeigen

mysql> Benutzer, Host aus mysql.user auswählen;
+--------------+--------------+
| Benutzer | Gastgeber |
+--------------+--------------+
| % |
| Wurzel | % |
| mysql.sys | lokaler Host |
| Stammverzeichnis | lokaler Host |
+--------------+--------------+
4 Zeilen im Satz (0,00 Sek.)

Autorisierung anzeigen

mysql> Berechtigungen für repl@'172.%' anzeigen;
+--------------------------------------------------+
| Zuschüsse für repl@172.% |
+--------------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.%' |
+--------------------------------------------------+
1 Zeile im Satz (0,00 Sek.)

2. Konfigurieren Sie den Master-Datenbankserver

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
binlog_format = Zeile
Server-ID = 101
gtid_mode = EIN
enforce_gtid_consistency = EIN
#log_slave_updates = EIN

HINWEIS: Es empfiehlt sich, Protokolle von Daten zu trennen, vorzugsweise in unterschiedlichen Datenpartitionen.

enforce_gtid_consistency erzwingt GTID-Konsistenz. Nach der Aktivierung können die folgenden Befehle nicht mehr verwendet werden

Tabelle erstellen ... auswählen ...

mysql> Tabelle „Abteilung“ erstellen, „* aus Abteilungen auswählen“;
FEHLER 1786 (HY000): Anweisung verletzt GTID-Konsistenz: CREATE TABLE ... SELECT.

Da es sich eigentlich um zwei unabhängige Ereignisse handelt, können wir sie nur aufteilen, um zuerst eine Tabelle zu erstellen und dann die Daten in die Tabelle einzufügen

temporäre Tabelle erstellen

Temporäre Tabellen können nicht innerhalb einer Transaktion erstellt werden

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

mysql> temporäre Tabelle dept(id int) erstellen;
FEHLER 1787 (HY000): Anweisung verletzt GTID-Konsistenz: CREATE TEMPORARY TABLE und DROP TEMPORARY TABLE können nur außerhalb eines Transaktionskontexts ausgeführt werden. Diese Anweisungen sind auch in einer Funktion oder einem Trigger nicht zulässig, da Funktionen und Trigger ebenfalls als Transaktionen mit mehreren Anweisungen betrachtet werden.

Transaktionale und nicht-transaktionale Tabellen in derselben Transaktion aktualisieren (MyISAM)

mysql> ERSTELLEN SIE TABELLE `dept_innodb` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT);
Abfrage OK, 0 Zeilen betroffen (0,04 Sek.)

mysql> CREATE TABLE `dept_myisam` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT) ENGINE = `MyISAM`;
Abfrage OK, 0 Zeilen betroffen (0,03 Sek.)

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

mysql> einfügen in dept_innodb(id) value(1);
Abfrage OK, 1 Zeile betroffen (0,00 Sek.)

mysql> einfügen in dept_myisam(id) value(1);
FEHLER 1785 (HY000): Anweisung verletzt GTID-Konsistenz: Aktualisierungen an nicht transaktionalen Tabellen können nur in automatisch festgeschriebenen Anweisungen oder Einzelanweisungstransaktionen und nie in derselben Anweisung wie Aktualisierungen an transaktionalen Tabellen erfolgen.

Daher wird empfohlen, Innodb als Standarddatenbank-Engine zu wählen.

log_slave_updates Diese Option ist für die GTID-basierte Replikation in MySQL 5.6 erforderlich, erhöht jedoch die IO-Last des Slave-Servers. In MySQL 5.7 ist diese Option nicht mehr erforderlich.

3. Konfigurieren Sie den Slave-Server

master_info_repository und relay_log_info_repository

Vor MySQL 5.6.2 wurden die vom Slave aufgezeichneten Masterinformationen und die Informationen des Binärprotokolls der Slave-Anwendung in Dateien gespeichert, nämlich master.info und relay-log.info. Nach Version 5.6.2 ist die Aufzeichnung in Tabellen zulässig. Die entsprechenden Tabellen sind mysql.slave_master_info und mysql.slave_relay_log_info, und beide Tabellen sind InnoDB-Engine-Tabellen.

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
Server-ID = 102
# Sklaven
relay_log = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
relay_log_info_file = /var/log/mysql/relay-bin.info
enforce_gtid_consistency = EIN
log_slave_updates = EIN
schreibgeschützt = EIN
master_info_repository = TABELLE
relay_log_info_repository = TABELLE

4. Initialisieren aus Bibliotheksdaten - [optional]

Sichern Sie zuerst die Daten auf der primären Datenbank

--master-data=2 Diese Option hängt die Position und den Dateinamen des Binlogs des aktuellen Servers an die Ausgabedatei an (show master status). Bei 1 wird der Offset in den Befehl CHANGE MASTER eingefügt. Bei 2 werden die Ausgabe-Offset-Informationen mit Anmerkungen versehen.

--all-databases Da die GTID-basierte Replikation alle Transaktionen aufzeichnet, wird diese Option zum Erstellen eines vollständigen Dumps empfohlen.

Häufige Fehler

Erscheint beim Importieren von SQL aus der Bibliothek

Rufen Sie nun die MySQL-Befehlszeile der Slave-Datenbank auf und verwenden Sie „Reset Master“.

5. GTID-basierte Replikation starten

Es gibt [email protected] und [email protected], und die Daten wurden über mysqldump mit dem Slave synchronisiert. Konfigurieren Sie nun den Replikationslink auf dem Slave-Server

mysql> ändere Master in master_host='master', master_user='repl', master_password='123456', master_auto_position=1;
Abfrage OK, 0 Zeilen betroffen, 2 Warnungen (0,06 Sek.)

Starten der Replikation

mysql> Slave starten;

Nach erfolgreichem Start prüfen Sie den Status des Slaves

mysql> Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
    Slave_IO_State: Master-Ereignis in die Relay-Log-Warteschlange einreihen
     Master_Host: Master
     Master_Benutzer: repl
     Master_Port: 3306
    Verbindungswiederholung: 60
    Master_Log_File:mysql-bin.000002
   Read_Master_Log_Pos: 12793692
    Relay_Log_File: relay-bin.000002
    Relay_Log_Pos: 1027
  Relay_Master_Log_File: mysql-bin.000002
    Slave_IO_Running: Ja
   Slave_SQL_Running: Ja
    Replicate_Do_DB:
   Replikat_Ignorieren_DB:
   Tabelle_replizieren:
  Tabelle_Ignorieren_replizieren:
  Wild_Do_Tabelle replizieren:
 Tabelle_Wild_Ignore_replizieren:
     Last_Errno: 0
     Letzter_Fehler:
     Skip_Counter: 0
   Exec_Master_Log_Pos: 814
    Relay_Log_Space: 12794106
    Until_Condition: Keine
    Bis_Log_Datei:
    Bis_Log_Pos: 0
   Master_SSL_Allowed: Nein
   Master_SSL_CA_Datei:
   Master_SSL_CA_Pfad:
    Master_SSL_Zertifikat:
   Master_SSL_Chiffre:
    Master_SSL_Schlüssel:
  Sekunden_Hinter_Master: 5096
Master_SSL_Verify_Server_Cert: Nein
    Last_IO_Errno: 0
    Letzter_E/A-Fehler:
    Last_SQL_Errno: 0
    Letzter_SQL_Fehler:
 Server-IDs replizieren_ignorieren:
    Master_Server_Id: 101
     Master_UUID: a9fd4765-ec70-11e6-b543-0242ac140002
    Master_Info_Datei: mysql.slave_master_info
     SQL_Delay: 0
   SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Ereignis aus dem Relay-Log lesen
   Master_Retry_Count: 86400
     Master_Bind:
  Zeitstempel des letzten IO-Fehlers:
  Letzter_SQL_Fehler_Zeitstempel:
    Master_SSL_Crl:
   Master_SSL_Crlpfad:
   Abgerufen_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-39
   Ausgeführtes_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-4
    Auto_Position: 1
   DB replizieren_neu schreiben:
     Kanalname:
   Master_TLS_Version:
1 Zeile im Satz (0,00 Sek.)

Wenn Slave_IO_Running, Slave_SQL_Running JA ist,

Wenn „Slave_SQL_Running_State“ lautet: „Slave hat das gesamte Relay-Protokoll gelesen; wartet auf weitere Aktualisierungen“, wurde die Replikationsverbindung erfolgreich hergestellt.

6. Zusammenfassung

Vorteil

1. Da der Protokolloffset nicht manuell eingestellt werden muss, kann ein Failover problemlos durchgeführt werden
2. Wenn log_slave_updates aktiviert ist, verliert der Slave keine Änderungen, die auf dem Master vorgenommen wurden.

Mangel

1. Es gibt bestimmte Einschränkungen für die ausgeführten SQL
2. Es werden nur MySQL-Versionen nach 5.6 unterstützt. Frühere Versionen als 5.6 werden nicht empfohlen.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.