部署基于GTID的Mysql一主两从集群
题外话
我们都知道Mysql的主从复制是非常重要的一个功能，我们在日常的大多数地方都会用到，比如用作热备，读写分离，高可用等等。本文介绍了mysql主从复制的基本原理和基础部署。
一、环境准备
三台Mysql 服务器
OS：centos 7
master：192.168.81.128
slave 1：192.168.81.129
slave 2：192.168.81.130
Mysql实例
三台Mysql服务器分别安装部署好Mysql实例，版本为5.7.30.
[root@server03 mysql3308]# ps -ef|grep mysql
root 3346 2908 0 15:23 pts/0 00:00:00 /bin/sh /d/mysqlbase/mysql3308/bin/mysqld_safe --defaults-file=/d/mysqldata/mysql3308/my.cnf.3308
mysql 4660 3346 0 15:23 pts/0 00:00:20 /d/mysqlbase/mysql3308/bin/mysqld --defaults-file=/d/mysqldata/mysql3308/my.cnf.3308 --basedir=/d/mysqlbase/mysql3308 --datadir=/d/mysqldata/mysql3308/mydata --plugin-dir=/d/mysqlbase/mysql3308/lib/plugin --user=mysql --log-error=/d/mysqldata/mysql3308/log/error.log --pid-file=/d/mysqldata/mysq3308/sock/mysql.pid --socket=/d/mysqldata/mysql3308/sock/mysql.sock --port=3308
具体安装部署Mysql实例可以参考我的另一文章：
https://blog.csdn.net/tah_001/article/details/107660943
注意：三个实例的server-id不能相同，可在配置文件更改。
二、Mysql主从复制原理
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点，如下简图：
1、 主节点 binary log dump 线程
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
2、从节点I/O线程
当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。
3、从节点SQL线程
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
4、对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。
Mysql主从复制的基本过程如下：
从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在祝节点上实际执行过的操作，并在本数据库中执行。
基于gtid的Mysql主从复制：
从 MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。
在原来基于二进制日志的复制中，从库需要告知主库要从哪个偏移量进行增量同步，如果指定错误会造成数据的遗漏，从而造成数据的不一致。借助GTID，在发生主备切换的情况下，MySQL的其它从库可以自动在新主库上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。
gtid工作原理：
①当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
②binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
③sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
④如果有记录，说明该GTID的事务已经执行，slave会忽略。
⑤如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
⑥在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。
三、部署
（1）在master创建用于主从复制的用户
mysql> CREATE USER 'rep'@'%' IDENTIFIED BY '555666';
Query OK, 0 rows affected (0.48 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rep'@'%' IDENTIFIED BY '555666';
Query OK, 0 rows affected, 1 warning (0.05 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.21 sec)
mysql> select user,host from mysql.user;
+---------------+-----------+
| user | host |
+---------------+-----------+
| rep | % |
| mysql.session | localhost |
| mysql.sys | localhost |
| root | localhost |
+---------------+-----------+
4 rows in set (0.06 sec)
（2）在所有slave指定主从复制关系
CHANGE MASTER TO
MASTER_HOST = '192.168.81.128',
MASTER_PORT = 3308,
MASTER_USER = 'rep',
MASTER_PASSWORD = '555666',
MASTER_AUTO_POSITION = 1;
开启slave的主从复制：
mysql> start slave;
Query OK, 0 rows affected (0.34 sec)
查看主从复制状态：
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.81.128
Master_User: rep
Master_Port: 3308
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 832
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 1045
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: 832
Relay_Log_Space: 1429
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: 92
Master_UUID: 372cdb11-dd77-11ea-8724-000c296c0825
Master_Info_File: mysql.slave_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: 372cdb11-dd77-11ea-8724-000c296c0825:1-3
Executed_Gtid_Set: 372cdb11-dd77-11ea-8724-000c296c0825:1-3
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
在master可以看到相应的dump进程：
mysql> show processlist;
+----+-----------------+----------------------+------+------------------+-------+---------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+----------------------+------+------------------+-------+---------------------------------------------------------------+------------------+
| 1 | event_scheduler | localhost | NULL | Daemon | 86180 | Waiting on empty queue | NULL |
| 5 | root | localhost | NULL | Query | 0 | starting | show processlist |
| 7 | rep | 192.168.81.129:51974 | NULL | Binlog Dump GTID | 345 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 8 | rep | 192.168.81.130:60828 | NULL | Binlog Dump GTID | 20 | Master has sent all binlog to slave; waiting for more updates | NULL |
+----+-----------------+----------------------+------+------------------+-------+---------------------------------------------------------------+------------------+
4 rows in set (0.02 sec)
（3）测试主从复制
**master创建库表，并插入测试数据：**
mysql> create database tah001;
Query OK, 1 row affected (0.06 sec)
mysql> use tah001
Database changed
mysql> create table tb01(id int(10) primary key,name varchar(20));
Query OK, 0 rows affected (1.28 sec)
mysql> insert into tb01 values(1,'zhangsan'),(2,'lisi');
Query OK, 2 rows affected (0.80 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> select * from tb01;
+----+----------+
| id | name |
+----+----------+
| 1 | zhangsan |
| 2 | lisi |
+----+----------+
2 rows in set (0.00 sec)
**检查slave是否成功同步master测试数据：**
可以看到show slave status的Gtid已经发生了变化：
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: 372cdb11-dd77-11ea-8724-000c296c0825:1-6
Executed_Gtid_Set: 372cdb11-dd77-11ea-8724-000c296c0825:1-6
可以看到master的测试数据已经成功同步到slave：
mysql> use tah001
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from tb01;
+----+----------+
| id | name |
+----+----------+
| 1 | zhangsan |
| 2 | lisi |
+----+----------+
2 rows in set (0.00 sec)
至此，Mysql一主两从集群已搭建完成。
PS：我这里是全新的实例，还没有数据。如果是已经运行的实例需要添加slave，则需要把master数据导至slave，并设置gtid_purged:
stop slave;
reset master;
set global gtid_purged=
'372cdb11-dd77-11ea-8724-000c296c0825:1-6';
start slave;
四、总结
Mysql一主两从集群已经安装部署完成，是不是特别简单快捷。同样的方法即可完成双主，多源复制，级联复制等配置，我们后面再分享。
可以看到对比传统指定binlog位点关系，基于GTID方便了许多。
哎哟，不错噢！ - - - - - - 欢迎指出有误的地方以及补充更好的方法