MySQL master-slave replication (6)-GTID replication
GTID-based replication is a replication method supported from MySQL 5.6. GTID is called Global Transaction ID (Global Transaction ID), which guarantees that a globally unique one can be generated in the replication cluster for each transaction submitted on the primary server ID. GTID makes MySQL's master-slave replication easier, and database consistency is more reliable.
GITD is composed of server ID (source_id) and transaction ID (transaction_id): (1) source_id is the server-uuid value of the main database that executes the transaction, and the server-uuid is stored in the auto.conf file in the data directory of the database. (2) The transaction ID is a self-increasing sequence starting from 1, indicating that a certain transaction is the first transaction executed on the main library.
1. GITD Copy Overview
1. Features of GITD replication
The differences between GITD-based replication and log-based replication:
(1) In log-based replication, the slave server connects to the master server and tells the master server from which binary log offset to start incremental synchronization;
(2) ) In GTID-based replication, first the slave server will tell the master server the GTID values of which transactions have been executed by the slave server, and then the master database will send all transactions that are not executed on the slave database to the slave database for execution. And the same transaction is executed only once on the specified slave library, which can avoid the problem of data confusion or inconsistency between master and slave caused by repeated execution.
Compared with traditional log-based replication, GITD-based replication has the following characteristics:
(1) GTID no longer uses MASTER_LOG_FILE and MASTER_LOG_POS to start copying, but uses MASTER_AUTO_POSTION=1 to start copying.
(2) In the GTID copy mode, the binlog on the slave side must be turned on to record the executed GTID. In the log-based replication mode, the binlog on the slave side does not need to be turned on.
2. The working principle of GTID replication
The working principle of GTID replication is as follows:
(1) When a transaction is executed and submitted in the main library, GTID is generated and recorded in the binlog log;
(2) The binlog is transmitted to the slave and stored in the relaylog of the slave, and this GTID is read And set the gtid_next variable to tell Slave the next GTID value to be executed.
(3) The SQL thread obtains the GTID from the relay log, and then compares whether the binlog on the slave side has the GTID. If there is a record, it means that the GTID transaction has been executed and the slave will ignore it; if there is no record, the slave will execute the GTID transaction and record the GTID to its own binlog, and check other session holdings before reading and executing the transaction The GTID is guaranteed not to be executed repeatedly.
Two, GITD copy configuration
1. Operating environment
Operating system: CentOS Linux release 7.8.2003 (Core)
MySQL version: MySQL5.7
Primary server IP: 192.168.1.11
Slave server IP: 192.168.1.12
2. Modify the configuration files of the master server and the slave server
(1) Configure the my.cnf file of the main server and add the following content in the configuration file:
[mysqld]
server-id = 1
gtid_mode = on # 开启gtid模式
enforce_gtid_consistency = on # 强制gtid一致性
log_bin = mysql-master-binlog
log-slave-updates = 1
binlog_format = row # 二进制日志的模式建议使用row
skip_slave_start = 1
(2) Configure the my.cnf file of the slave server, and add the following content to the configuration file:
[mysqld]
server-id = 2
gtid_mode = on
enforce_gtid_consistency = on
log-bin = mysql-slave-binlog
log-slave-updates = 1
binlog_format = row
read-only = on
skip_slave_start = 1
3. Create a copy account
mysql> grant replication slave on *.* to 'repl'@'192.168.1.%' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)
4. Back up the data in the main library
Execute the following backup command to back up all databases and tables:
[root@localhost data]# mysqldump -uroot -p123456 -A -B > /tmp/all.sql
5. Restore the backup of the main library to the slave library
Copy the backup file of the master library to the slave library, and then execute the import.
(1) Copy the backup file of the master library to the slave library
[root@localhost data]# scp /tmp/all.sql 192.168.1.12:/tmp/
The authenticity of host '192.168.1.12 (192.168.1.12)' can't be established.
ECDSA key fingerprint is SHA256:0yqIuKW/XcSZS5t++Is1bOyYz67wUryyULbXgTc/HuY.
ECDSA key fingerprint is MD5:12:74:ba:b6:74:0c:6e:b1:59:ab:55:8d:60:18:3f:87.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.12' (ECDSA) to the list of known hosts.
[email protected]'s password:
all.sql 100% 785KB 28.3MB/s 00:00
[root@localhost data]#
(2) Reset the log file
mysql> reset master;
Query OK, 0 rows affected (0.02 sec)
(3) Import data from the library
[root@localhost data]# mysql -uroot -p123456 < /tmp/all.sql
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@localhost data]#
6. Copy information in the slave library settings
Execute the following commands in the slave library:
CHANGE MASTER TO
MASTER_HOST='192.168.1.11',
MASTER_USER='repl',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_AUTO_POSITION = 1;
7. Start the slave and view the status of the slave library
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.11
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-master-binlog.000001
Read_Master_Log_Pos: 2776
Relay_Log_File: localhost-relay-bin.000002
Relay_Log_Pos: 444
Relay_Master_Log_File: mysql-master-binlog.000001
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: 2776
Relay_Log_Space: 655
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: 0
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: 1
Master_UUID: 19dc9ca1-c59e-11ea-9f11-000c296166d5
Master_Info_File: /usr/local/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 19dc9ca1-c59e-11ea-9f11-000c296166d5:1-11
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
8. Verification
(1) Modify data in the main library
mysql> select * from stu;
+------+------+------+
| s_id | name | age |
+------+------+------+
| 1 | Jack | 20 |
| 2 | Tom | 20 |
| 3 | Rose | 21 |
+------+------+------+
3 rows in set (0.00 sec)
mysql>
mysql>
mysql> update stu set age=age+1;
Query OK, 3 rows affected (0.01 sec)
Rows matched: 3 Changed: 3 Warnings: 0
(2) View data from the library
mysql> use hist;
Database changed
mysql> select * from stu;
+------+------+------+
| s_id | name | age |
+------+------+------+
| 1 | Jack | 21 |
| 2 | Tom | 21 |
| 3 | Rose | 22 |
+------+------+------+
3 rows in set (0.00 sec)