一文详解MySQL主从复制-电子发烧友网

19.1 主从复制介绍

19.1.1 主从存在的意义

数据备份：为了避免单点故障，增加一个从服务器，用来复制主服务器上的数据。

分担负载：将写操作在主上做，查询操作在从上做。

19.1.2 主从复制原理

① 主上将所有变更事件记录到binlog里

② 从发起请求连接主

③ 主的binlog备份线程将binlog传给从

④ 从的I/O线程将binlog解析成自己的relay log

⑤ 从的SQL线程根据relay log来执行具体的SQL语句

MySQL主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。

binlog：binary log，主库中保存所有更新事件日志的二进制文件。binlog是数据库服务启动的一刻起，保存数据库所有变更记录（数据库结构和内容）的文件。在主库中，只要有更新事件出现，就会被依次地写入到binlog中，之后会推送到从库中作为从库进行复制的数据源。

binlog dump线程：每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。对于每一个即将发送给从库的sql事件，binlog dump线程会将其锁住。一旦该事件被线程读取完之后，该锁会被释放，即使在该事件完全发送到从库的时候，该锁也会被释放。

在从库中，当复制开始时，从库就会创建从库I/O线程和从库的SQL线程进行复制处理。

从库I/O线程：当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。

从库的SQL线程：从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。

19.2 搭建主从复制

19.2.1 基于二进制日志文件位置的复制

① 根据我们前面的文档，搭建两台MySQL服务，具体步骤略

192.168.222.128 主
192.168.222.132 从

② 检查并配置两台机器的server_id

vi my.cnf #搜索server_id ，如果没有则增加
主上设置为server_id=1
从上设置为 server_id = 2

③ 在主上创建用作主从复制的用户

create user 'rep'@'192.168.222.132'  identified with 'mysql_native_password' by 'AmingLinux.Com';
grant REPLICATION SLAVE  on *.* to 'rep'@'192.168.222.132';
flush privileges;

④在主上查询日志名字以及位置

show master status; ##记录下对应的日志命令以及位置
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| aminglinux.000001 |      853|              |                  |
+------------------+----------+--------------+------------------+

⑤到从上执行

change master to master_host='192.168.222.128',master_user='rep',master_password='AmingLinux.Com',master_log_file='aminglinux.000001',master_log_pos=853;
start slave;
show slave statusG

19.2.2 基于GTID的主从复制

1. 什么是GTID

GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识，保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。下面是一个GTID的具体形式：

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

2.GTID的作用

根据GTID可以知道事务最初是在哪个实例上提交的，GTID的存在方便了Replication的Failover（故障切换）

3. GTID比传统复制的优势

更简单的实现failover，不用以前那样在需要找log_file和log_Pos。更简单的搭建主从复制。比传统复制更加安全。GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

4. GTID的工作原理：

① master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

②slave端的i/o线程将变更的binlog，写入到本地的relay log中。

③sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

④如果有记录，说明该GTID的事务已经执行，slave会忽略。

⑤如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

⑥在解析过程中会判断是否有主键，如果有就用二级索引，如果没有就用全部扫描。

4. GTID复制搭建

由于之前做过主从配置，可以先取消之前的主从。

slave上执行：

stop slave;
reset slave all;

master上执行：

reset master;

① 主上修改配置文件，重启mysql服务

server_id = 1
gtid_mode = on
enforce_gtid_consistency=on
log_bin=mysql-bin
binlog_format=row
log-slave-updates=1
skip-slave-start=1

② 从上修改配置文件，重启mysql服务

server_id = 2
gtid_mode = on
enforce_gtid_consistency=on
log_bin=mysql-bin
binlog_format=row
log-slave-updates=1
skip-slave-start=1

③ 主上授权用户

create user 'rep'@'192.168.222.132'  identified with 'mysql_native_password' by 'AmingLinux.Com';
grant REPLICATION SLAVE  on *.* to 'rep'@'192.168.222.132';
flush privileges;

④ 从上配置主从

stop slave;
CHANGE MASTER TO MASTER_HOST='192.168.222.128', MASTER_USER='rep',MASTER_PASSWORD='AmingLinux.Com',MASTER_AUTO_POSITION=1,MASTER_CONNECT_RETRY=10;
start slave;

④ 查看主从状态

从上执行