MySQL-Master-Slave-Replikationspraxis – gemeinsame Nutzung von GTID-basiertem Replikationscode

In diesem Artikel wird hauptsächlich die MySQL-Master-Slave-Replikationspraxis vorgestellt. Die GTID-basierte Replikation ist eine neue Replikationsmethode nach MySQL 5.6.

GTID-basierte Replikation

Einführung

GTID-basierte Replikation ist eine neue Replikationsmethode nach MySQL 5.6.

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

In der ursprünglichen protokollbasierten Replikation , Die Slave-Bibliothek muss der Master-Bibliothek mitteilen, ab welchem ​​Offset die inkrementelle Synchronisierung durchgeführt werden soll. Wenn der angegebene Fehler angegeben wird, werden Daten weggelassen, was zu Dateninkonsistenzen führt.

Bei der GTID-basierten Replikation wird dies der Fall sein inform Der Wert der GTID der von der Hauptbibliothek ausgeführten Transaktion. Anschließend gibt die Hauptbibliothek die Liste der GTIDs aller nicht ausgeführten Transaktionen an die Slave-Bibliothek zurück. Dadurch kann sichergestellt werden, dass dieselbe Transaktion nur einmal ausgeführt wird in der angegebenen Slave-Bibliothek.

Praktischer Kampf

1. Erstellen Sie ein Replikationskonto in der Master-Datenbank und erteilen Sie Berechtigungen

Bei der GTID-basierten Replikation werden die Daten automatisch von der Slave-Datenbank in die Slave-Datenbank kopiert. Erstellen Sie daher nicht dasselbe Konto in anderen Slave-Bibliotheken. Wenn dasselbe Konto erstellt wird, kann es zu Fehlern bei der Replikationsverknüpfung kommen .

mysql> create user 'repl'@'172.%' identified by '123456';

Beachten Sie, dass das Passwort in der Produktion sein muss. Befolgen Sie die relevanten Spezifikationen, um eine bestimmte Passwortstärke zu erreichen, und legen Sie fest, dass auf die Master-Datenbank nur in einem bestimmten Netzwerksegment der Slave-Datenbank zugegriffen werden kann.

mysql> grant replication slave on *.* to 'repl'@'172.%';

Benutzer anzeigen

mysql> select user, host from mysql.user;
+-----------+-----------+
| user  | host  |
+-----------+-----------+
| prontera | %   |
| root  | %   |
| mysql.sys | localhost |
| root  | localhost |
+-----------+-----------+
4 rows in set (0.00 sec)

Autorisierung anzeigen

mysql> show grants for repl@'172.%';
+--------------------------------------------------+
| Grants for repl@172.%       |
+--------------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.%' |
+--------------------------------------------------+
1 row in set (0.00 sec)

2. Konfigurieren Sie den Hauptdatenbankserver

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
binlog_format = row
server_id = 101
gtid_mode = ON
enforce_gtid_consistency = ON
#log_slave_updates = ON

HINWEIS: Es ist eine gute Angewohnheit, Protokolle und Daten zu trennen, und es ist am besten, sie in verschiedenen Datenpartitionen abzulegen

enforce_gtid_consistency Erzwingen Sie die GTID-Konsistenz, nachdem Sie Folgendes aktiviert haben Befehle können nicht mehr verwendet werden

Tabelle erstellen ... auswählen ...

mysql> create table dept select * from departments;
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.

Da es sich eigentlich um zwei unabhängige Ereignisse handelt, können sie nur noch aufgeteilt werden Erstellen Sie zuerst eine Tabelle und fügen Sie dann die Daten in die Tabelle ein

create temporary table

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

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> create temporary table dept(id int);
ERROR 1787 (HY000): Statement violates GTID consistency: 
CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. 
These statements are also not allowed in a function or trigger because functions and triggers are also 
considered to be multi-statement transactions.

In derselben TransaktionAktualisieren Transaktionstabelle und Nicht-Transaktionstabelle (MyISAM)

mysql> CREATE TABLE `dept_innodb` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT);
Query OK, 0 rows affected (0.04 sec)

mysql> CREATE TABLE `dept_myisam` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT) ENGINE = `MyISAM`;
Query OK, 0 rows affected (0.03 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into dept_innodb(id) value(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into dept_myisam(id) value(1);
ERROR 1785 (HY000): Statement violates GTID consistency: 
Updates to non-transactional tables can only be done in either autocommitted statements or 
single-statement transactions, and never in the same statement as updates to transactional tables.

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

log_slave_updates Diese Option ist für die GTID-basierte Replikation in MySQL erforderlich 5.6, aber es erhöht die IO-Last des Slave-Servers, und diese Option ist in MySQL 5.7 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 Master-Informationen und die Binlog-Informationen der Slave-Anwendung in der Datei gespeichert, d. h. master.info und Relay-log.info. Nach Version 5.6.2. Die Anmeldung in Tabellen ist zulässig. Die entsprechenden Tabellen sind mysql.slave_master_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
# slaves
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 = ON
log_slave_updates = ON
read_only = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE

4 🎜>

Sichern Sie zuerst die Daten in der Masterdatenbank

Der Code lautet wie folgt:

mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases --events -u root -p > backup.sql

--master-data=2 Diese Option hängt den Speicherort an und Dateiname des Binlogs des aktuellen Servers zur Ausgabedatei (Master-Status anzeigen). Wenn es 1 ist, wird der Offset in den CHANGE MASTER-Befehl eingefügt. Wenn es 2 ist, werden die Ausgabe-Offset-Verschiebungsinformationen auskommentiert.

--all-databases Da die GTID-basierte Replikation alle Transaktionen aufzeichnet, wird diese Option empfohlen, um einen vollständigen Dump zu erstellen

Häufige Fehler

Beim Importieren von SQL aus der Datenbank wird

angezeigt. Der Code lautet wie folgt:

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

Geben Sie zu diesem Zeitpunkt die MySQL-Befehlszeile aus der Datenbank ein und verwenden Sie „Reset Master“

5. GTID-basierte Replikation starten

Vorhandener Master@172.20.0.2 und Slave@172.20.0.3, und die Daten wurden über mysqldump mit dem Slave-Datenbankslave synchronisiert die Slave-Datenbank. Konfigurieren Sie einen Replikationslink auf dem Server-Slave

mysql> change master to master_host='master', master_user='repl', master_password='123456', master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.06 sec)

Replikation starten

mysql> start slave;

Überprüfen Sie nach erfolgreichem Start den

Status des Slaves

mysql> show slave status\G
*************************** 1. row ***************************
    Slave_IO_State: Queueing master event to the relay log
     Master_Host: master
     Master_User: repl
     Master_Port: 3306
    Connect_Retry: 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: Yes
   Slave_SQL_Running: Yes
    Replicate_Do_DB:
   Replicate_Ignore_DB:
   Replicate_Do_Table:
  Replicate_Ignore_Table:
  Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
     Last_Errno: 0
     Last_Error:
     Skip_Counter: 0
   Exec_Master_Log_Pos: 814
    Relay_Log_Space: 12794106
    Until_Condition: None
    Until_Log_File:
    Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
    Master_SSL_Cert:
   Master_SSL_Cipher:
    Master_SSL_Key:
  Seconds_Behind_Master: 5096
Master_SSL_Verify_Server_Cert: No
    Last_IO_Errno: 0
    Last_IO_Error:
    Last_SQL_Errno: 0
    Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
    Master_Server_Id: 101
     Master_UUID: a9fd4765-ec70-11e6-b543-0242ac140002
    Master_Info_File: mysql.slave_master_info
     SQL_Delay: 0
   SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Reading event from the relay log
   Master_Retry_Count: 86400
     Master_Bind:
  Last_IO_Error_Timestamp:
  Last_SQL_Error_Timestamp:
    Master_SSL_Crl:
   Master_SSL_Crlpath:
   Retrieved_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-39
   Executed_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-4
    Auto_Position: 1
   Replicate_Rewrite_DB:
     Channel_Name:
   Master_TLS_Version:
1 row in set (0.00 sec)

Slave_IO_Running, Slave_SQL_Running ist YES,

und Slave_SQL_Running_State ist Slave hat das gesamte Relay-Protokoll gelesen; das bedeutet, dass die Replikationsverbindung erfolgreich erstellt wurde

6. Zusammenfassung

Vorteile

1. Da der Protokoll-Offset nicht manuell festgelegt werden muss, kann ein Failover problemlos durchgeführt werden

2. Wenn log_slave_updates aktiviert ist, verliert die Slave-Bibliothek keine Änderungen an der Master-Bibliothek

Nachteile

1. Es gibt bestimmte Einschränkungen für das ausgeführte SQL

2. Unterstützt nur Versionen nach MySQL 5.6 und es wird nicht empfohlen, frühere 5.6-Versionen zu verwenden

Das obige ist der detaillierte Inhalt vonMySQL-Master-Slave-Replikationspraxis – gemeinsame Nutzung von GTID-basiertem Replikationscode. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!