目录
- 主从复制基础
- 主从复制简介
- 主从复制前提
- 主从复制搭建
- 主库配置（3307实例）
- 从库配置（3308实例）
- 主从复制原理
- 主从复制相关文件
- 主从复制相关线程
- 主从复制图解原理
- 主从故障监控/分析/处理
- IO线程故障
- 连接主库出现问题
- 请求和接收二进制文件
- 处理故障过程
- SQL线程故障
- SQL线程故障原因分析
- SQL县城故障模拟环境
- SQL线程故障处理方式
- 以从库为核心的处理方案
- 一劳永逸的方案
- 主从延时分析
- 外在因素
- 主库因素
- 从库因素
- 主从复制进阶
- 延时从库
- 延时从库原因
- 延时从库配置
- 延时从库应用
- 半同步复制
- 过滤复制
- GTID复制
- GTID简介
- GTID复制配置
- GTID复制与普通复制的区别
- 主从复制架构演变
- 基础架构（无需三方软件支持）
- 高级架构（需要三方软件支持）
- 企业高可用标准
主从复制基础
主从复制简介
MySQL数据库的主从复制方案，与使用scp/rsync等命令进行的文件级别复制类似，都是数据的远程传输，只不过MySQL的主从复制是自带的功能。MySQL的主从复制并不是数据库磁盘上的文件直接拷贝，而是将二进制日志binlog复制到要同步的服务器本地，然后由本地的线程读取日志里面的SQL语句，重新应用到MySQL数据库中。
- 基于二进制日志binlog进行复制
- 主库的修改操作会记录到二进制日志文件中
- 从库会请求新的二进制日志并回放，最终达到主从数据同步
- 主从复制核心功能：辅助备份，处理数据库物理损坏
什么是逻辑损坏？drop、delete truncate等在数据库内部的误操作
什么是物理损坏？操作系统层次的损坏（数据库外部的损坏）
问：主从复制可以替代数据库的备份？
答：主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）；对逻辑损坏还是需要通过备份进行恢复。
主从复制前提
- 两台以上mysql实例 ：server_id、server_uuid不同
- 主库开启二进制日志
- 主库需建立专用的复制用户（replication slave）
- 建立主库全备（适用于主库运行很久后需要建立从库的情况），保证主从开启之前的某个时间点,从库数据和主库一致
- change master to：告知从库主库的IP、Port、user、passwd以及复制的起点（file，position）
- start slave：开启专用的复制线程（主库：binlog_dump_T 、从库：thread IO thread 、SQL thread）
主从复制搭建
主库配置（3307实例）
- 创建数据目录并赋予权限进行初始化
[root@localhost data]# mkdir /data/3307/data -p [root@localhost data]# chown -R mysql.mysql /data/3307 [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3307/data - 编辑配置文件，开启二进制日志功能
[root@localhost data]# vim /data/3307/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3307/data socket=/data/3307/mysql.sock log_error=/data/3307/mysql.log port=3307 server_id=7 log_bin=/data/3307/mysql-bin - 启动主库数据库实例3307
[root@localhost data]# systemctl start mysqld3307 [root@localhost data]# mysql -uroot -S /data/3307/mysql.sock - 检查是否开启二进制日志文件
[root@localhost ~]# ll /data/3307/mysql-bin* -rw-r-----. 1 mysql mysql 154 Oct 3 12:23 /data/3307/mysql-bin.000001 -rw-r-----. 1 mysql mysql 28 Oct 3 12:23 /data/3307/mysql-bin.index - 创建专用复制用户
[root@localhost ~]# mysql -uroot -S /data/3307/mysql.sock mysql [(none)]>grant replication slave on *.* to slave@'192.168.1.%' identified by '123456'; - 建立主库全备（若主库都是刚搭建可以省略该步骤）
[root@localhost ~]# [root@localhost ~]# mysqldump -uroot -S /data/3307/mysql.sock -A -R -E --triggers --master-data=2 --single-transaction > /data/3307/backup/full.sql 获取change master to 的信息 [root@localhost ~]# vim /data/3307/backup/full.sql -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=448; - 查看主库状态
mysql [(none)]>show master status ; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000001 | 448 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
从库配置（3308实例）
-
从库模拟恢复主库全备，保证主从开启之前的某个时间点，从库数据和主库一致
[root@localhost ~]# mysql -uroot -S /data/3308/mysql.sock mysql [mysql]>set sql_log_bin=0; mysql [mysql]>source /data/3307/backup/full.sql -
告知从库主库的IP、Port、专用复制用户的用户名和密码等信息（change master to）
查看change master to帮助信息 mysql [(none)]>help change master to CHANGE MASTER TO MASTER_HOST='master2.mycompany.com', --主库地址 MASTER_USER='replication', --用户名 MASTER_PASSWORD='bigs3cret', --密码 MASTER_PORT=3306, --端口 MASTER_LOG_FILE='master2-bin.001', --binlog MASTER_LOG_POS=4, --position MASTER_CONNECT_RETRY=10; --重复连接次数mysql [(none)]>CHANGE MASTER TO -> MASTER_HOST='192.168.1.5', -> MASTER_USER='slave', -> MASTER_PASSWORD='123456', -> MASTER_PORT=3307, -> MASTER_LOG_FILE='mysql-bin.000001', -> MASTER_LOG_POS=448, -> MASTER_CONNECT_RETRY=10; Query OK, 0 rows affected, 2 warnings (0.22 sec) -
开启主从专用线程
mysql [(none)]> start slave; -
检查复制状态
mysql [(none)]>show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.5 --主库相关信息监控 Master_User: slave Master_Port: 3307 Connect_Retry: 10 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 448 Relay_Log_File: localhost-relay-bin.000002 --从库中继日志的应用状态 Relay_Log_Pos: 320 Slave_IO_Running: Yes --从库复制线程有关状态 Slave_SQL_Running: Yes Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Do_DB: --过滤复制有关 Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Seconds_Behind_Master: 0 --主从延时相关状态（非人为） SQL_Delay: 0 --延时从库有关状态（人为） SQL_Remaining_Delay: NULL Retrieved_Gtid_Set: --GTID复制有关状态 Executed_Gtid_Set: Auto_Position: 0
主从复制原理
主从复制相关文件
- 主库：
mysql-bin.000001：二进制文件 - 从库：
localhost-relay-bin.000002：中继日志文件
master.info：主库信息
relay-log.info：中继日志信息
主从复制相关线程
- 主库：
Binlog_Dump_Thread：DT - 从库：
Slave_IO_Thread：IT
Slave_SQL_Thread：ST
主从复制图解原理
- change master to命令：主库的ip port user password binlog position写入到master.info进行记录；
- start slave 命令：从库会启动Slave_IO_Thread和Slave_SQL_Thread；
- Slave_IO_Thread读取master.info信息，获取主库信息并连接主库；
- 主库会生成一个Binlog_Dump_Thread来响应从库；
- Slave_IO_Thread根据master.info记录的binlog文件名和position号，请求主库Binlog_Dump_Thread最新日志；
- Binlog_Dump_Thread检查主库的binlog日志，如果有新日志生成，TP(传送)给从库的Slave_IO_Thread（主库一旦有新的日志生成，会发送信号给Binlog_Dump_Thread，IO线程再请求）；
- Slave_IO_Thread将收到的日志存储到了TCP/IP 缓存，并立即返回ACK给主库 ，主库工作完成；
- Slave_IO_Thread将缓存中的数据存储到relay-log中继日志文件，并更新master.info文件binlog 文件名和postion，Slave_IO_Thread工作完成；
- Slave_SQL_Thread读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log；
- Slave_SQL_Thread回放完成之后，会更新relay-log.info文件；
- relay-log有自动清理的功能。
主从故障监控/分析/处理
IO线程故障
连接主库出现问题
Slave_IO_Running：Connecting
Last_IO_Errno: 0
Last_IO_Error:
-
IP
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.55' (113) -
Port
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.5' (111) -
user，passwd
ERROR 1045 (28000): Access denied for user 'slave'@'192.168.1.5' (using password: YES) -
连接数量上限
ERROR 1040 (HY000)：Too many connections -
防火墙、网络不通
请求和接收二进制文件
故障：主库日志损坏或丢失
案例：执行reset master模拟主库日志丢失（会导致从库方面二进制日志位置点不对）
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000001' at 154, the last event read from '/data/3307/data/mysql-bin.000002' at 154, the last byte read from '/data/3307/data/mysql-bin.000002' at 154.'
注意：在主从复制环境中，严令禁止主库中reset master； 可以选择expire 进行定期清理主库二进制日志。
处理故障过程
重新搭建主从环境
- 从库停止slave服务
> stop slave; - 重置从库信息
> reset slave all; > show slave status \G - 重新搭建从库
> change master to > start slave;
SQL线程故障
SQL线程故障原因分析
- 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响；
- 要创建的数据库对象已经存在；
- 要删除或修改的对象不存在 ；
- DML语句不符合表定义及约束；
归根揭底都是由于从库发生了写入操作。
SQL县城故障模拟环境
-
从库建立一个数据库sql_error
mysql [(none)]>create database sql_error; Query OK, 1 row affected (0.03 sec) mysql [(none)]>show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sql_error | | sys | | test | +--------------------+ 6 rows in set (0.13 sec) -
主库再次建立一个sql_error数据库
mysql [(none)]>show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | | test | +--------------------+ 5 rows in set (0.29 sec) mysql [(none)]>create database sql_error; Query OK, 1 row affected (0.02 sec) -
查看从库状态，出现异常
Slave_SQL_Running: No Last_SQL_Error: Error 'Can't create database 'sql_error'; database exists' on query. Default database: 'sql_error'. Query: 'create database sql_error'
SQL线程故障处理方式
以从库为核心的处理方案
丑话说在前头：以从库为核心处理的方案是有风险的，最安全的做法就是重新构建主从。坚定把握一个原则：一切以主库为主。
- 方法一：sql_slave_skip_counter=1;(有风险)
mysql [(none)]>stop slave; Query OK, 0 rows affected (0.01 sec) mysql [(none)]>set global sql_slave_skip_counter=1; # 将同步指针移到下一个，如果多次不同步，可以重复操作 Query OK, 0 rows affected (0.00 sec) mysql [(none)]>start slave; Query OK, 0 rows affected (0.11 sec) - 方法二：编辑配置文件跳过指定错误（生产环境不允许）
vim my.cnf slave-skip-errors = 1032,1062,1007 常见错误代码: - 1007:对象已存在 - 1032:无法执行DML - 1062:主键冲突,或约束冲突
一劳永逸的方案
- 方法一：设置从库只读
mysql [(none)]>set global read_only=1; Query OK, 0 rows affected (0.00 sec) mysql [(none)]>show variables like '%read_only%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_read_only | OFF | | read_only | ON | | super_read_only | OFF | | transaction_read_only | OFF | | tx_read_only | OFF | +-----------------------+-------+ 5 rows in set (0.00 sec) - 方法二：加入中间件实现读写分离
主从延时分析
主库做了修改操作,从库比较长时间才能追上。
外在因素
- 网络
- 主从硬件差异大
- 版本差异
- 参数因素
主库因素
原因分析：
- 二进制日志写入不及时
mysql [(none)]>select @@sync_binlog; +---------------+ | @@sync_binlog | +---------------+ | 1 | +---------------+ 1 row in set (0.01 sec) - 传统模式的主从复制中，binlog_dump线程以事件为单元串行传送二进制日志(版本5.5 5.6)
a. 主库并发事务量大,主库可以并行,传送时是串行
b. 主库发生大事务,由于是串行传送,会阻塞后续的事务 - 一主多从情况下，主库有很多DUMP线程，传输压力大（架构层面）
解决方案:
- MySQL 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO
- MySQL 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,但建议还是开启GTID
- 大事务拆成多个小事务,可以有效的减少主从延时
从库因素
原因分析：
SQL线程导致的主从延时。在传统模式主从复制中，从库默认情况下只有一个SQL，只能串行回放事务SQL
- 主库如果并发事务量较大,从库只能串行回放
- 主库发生了大事务,会阻塞后续的所有的事务的运行
解决方案:
- MySQL 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放（同一个库内依然是串行回放，防止出现逻辑问题）
- MySQL 5.7 版本开启GTID之后,在SQL方面,提供了逻辑时钟(logical_clock),binlog加入了seq_no（sequence number，序列号）机制,
真正实现了基于事务级别的并发回放,这种技术称之为MTS(enhanced multi-threaded slave) - 大事务拆成多个小事务,可以有效的减少主从延时
主从复制进阶
延时从库
延时从库是一种特殊从库，通过人为配置从库和主库延时N小时。
延时从库原因
主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）。如果发生了逻辑损坏，就需要备份恢复，但如果恢复数量级很大的话，时间成本很高。
因此延时从库是为了更快的解决逻辑损坏问题的从库（备份恢复的替代方案）。
延时从库配置
SQL线程延时：数据已经写入relay-log中，但SQL线程慢点执行relay-log中的语句。
一般企业建议延时3-6小时，具体看公司运维人员对于故障的反应时间。
延时从库配置
-
停止slave服务
mysql [(none)]>stop slave; Query OK, 0 rows affected, 1 warning (0.05 sec) -
修改MASTER_DELAY参数
mysql [(none)]>CHANGE MASTER TO MASTER_DELAY=300; Query OK, 0 rows affected (0.32 sec) -
开启slave服务
mysql [(none)]>start slave; -
查看延时状态
mysql [(none)]>show slave status \G; SQL_Delay: 300 --延时时间 SQL_Remaining_Delay: 295 --延时倒计时 -
查看二进制日志是否一致
# 主库 mysql [test]>show master status ; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000001 | 943 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.34 sec) # 从库 mysql [(none)]>show slave status \G; Read_Master_Log_Pos: 943
延时从库应用
一主一从，从库延时5分钟，主库误删除1个库。
逻辑故障恢复思路：
- 5分钟之内及时侦测到误删除操作
- 立即停止延时从库SQL的线程
- 挂维护页
- 截取relay-log日志进行恢复
起点 ：停止SQL线程时的relay-log位置点
终点 ：误删除之前的position(GTID) - 截取的日志恢复到从库
- 从库身份解除,替代主库工作
故障模拟及恢复：
-
模拟主库数据操作
mysql [(none)]> create database relay charset utf8; mysql [(none)]> use relay mysql [relay]> create table t1 (id int); mysql [relay]> insert into t1 values(1); mysql [relay]> drop database relay; -
发现故障，停止从库的SQL线程
mysql [none]> stop slave sql_thread; -
找到relay-log的截取起点和终点
# 起点 mysql [(none)]>show slave status\G; Relay_Log_File: localhost-relay-bin.000002 Relay_Log_Pos: 482 --同步前的position Read_Master_Log_Pos: 1698 --主库传来的新position # 终点 mysql [(none)]>show relaylog events in 'localhost-relay-bin.000002' | localhost-relay-bin.000002 | 1046 | Xid | 7 | 1538 | COMMIT /* xid=74 */ | | localhost-relay-bin.000002 | 1077 | Anonymous_Gtid | 7 | 1603 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | localhost-relay-bin.000002 | 1142 | Query | 7 | 1698 | drop database relay | # 截取日志 [root@localhost ~]# mysqlbinlog --start-position=482 --stop-position=1077 /data/3308/data/localhost-relay-bin.000002>/tmp/relay.sql -
从库恢复relay-log
mysql [relay]>source /tmp/relay.sql -
从库身份解除，从库替代主库身份（数据量比较小的话可以考虑直接将数据导入主库）
mysql [relay]>stop slave; mysql [relay]>reset slave all;
半同步复制
半同步复制用来解决主从数据一致性问题。
- MySQL 5.5 版本出现
- MySQL 5.6 增强
- MySQL 5.7 完善，5.7.17后出现MGR复制
- 主库执行新的事务commit时，更新 show master status\G ，触发一个信号给Binlog_Dump_Thread；
- Binlog_Dump_Thread 接收到主库的 show master status\G 信息,通知从库日志更新；
- 从库Slave_IO_Thread 请求新的二进制日志事件;
- 主库会通过 Binlog_Dump_Thread 传送新的日志事件给从库Slave_IO_Thread；
- 从库Slave_IO_Thread接收到binlog日志，当日志写入到磁盘上的relaylog文件时，给主库ACK_receiver线程发送确认；
- ACK_receiver线程触发一个事件，告诉主库commit可以成功了；
- 如果ACK达到了预设值的超时时间，半同步复制会切换为原始的异步复制。
过滤复制
需求：master 有3个库A、B、C ，现在需要将其中2个库B，C单独拆分出来，单独一个实例。
常见的做法为：单独搭建一个只有B、C库的实例，且它们只复制master的B、C库，过滤掉A库。此时就需要过滤复制。
mysql [(none)]>show slave status \G;
Replicate_Do_DB: --过滤复制相关参数
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
过滤复制配置
-
主库方面（不建议使用）
Binlog_Do_DB
Binlog_Ignore_DB -
从库方面
Replicate_Do_DB
Replicate_Ignore_DB配置3309数据库实例只对两个库进行同步操作
[root@db01 ~]# vim /data/3309/my.cnf replicate_do_db=people replicate_do_db=world [root@db01 ~]# systemctl restart mysqld3309
GTID复制
GTID简介
GTID(Global Transaction ID)是对一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。它的官方定义如下：
GTID = source_id ：transaction_id
什么是sever_uuid？和server-id 区别？
server_uuid是mysql的识别码，server_id是在集群里面的id号，防止server_id冲突。
-
核心特性
全局唯一，具备幂等性 -
核心参数
gtid-mode=on --启动GTID类型，否则就是普通的复制架构
enforce-gtid-consistency=true --强制GTID的一致性
log-slave-update=1 --设置为开启，则从库从主库复制数据时可以写入到binlog日志
GTID复制配置
需求：搭建一主两从的GTID环境
-
创建数据目录并授予权限
[root@localhost ~]# mkdir -p /data/330{7,8,9}/data [root@localhost ~]# chown -R mysql.mysql /data/330{7,8,9} -
准备各实例的配置文件
[root@localhost ~]# vim /data/3307/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3307/data socket=/data/3307/mysql.sock server_id=7 port=3307 secure-file-priv=/tmp autocommit=0 log_bin=/data/3307/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db01 [\\d]>[root@localhost ~]# vim /data/3308/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3308/data socket=/data/3308/mysql.sock server_id=8 port=3308 secure-file-priv=/tmp autocommit=0 log_bin=/data/3308/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db02 [\\d]>[root@localhost ~]# vim /data/3309/my.cnf [mysqld] basedir=/app/mysql datadir=/data/3309/data socket=/data/3309/mysql.sock server_id=9 port=3309 secure-file-priv=/tmp autocommit=0 log_bin=/data/3309/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db03 [\\d]> -
初始化各实例数据目录
[root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3307/data [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3308/data [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3309/data -
启动各数据库实例
[root@localhost system]# systemctl start mysqld3307.service [root@localhost system]# systemctl start mysqld3308.service [root@localhost system]# systemctl start mysqld3309.service [root@localhost system]# ps -ef | grep mysqld mysql 10676 1 21 18:18 ? 00:00:06 /app/mysql/bin/mysqld --defaults-file=/data/3307/my.cnf mysql 10687 1 9 18:19 ? 00:00:02 /app/mysql/bin/mysqld --defaults-file=/data/3308/my.cnf mysql 10761 1 24 18:19 ? 00:00:03 /app/mysql/bin/mysqld --defaults-file=/data/3309/my.cnf root 10795 5857 16 18:19 pts/0 00:00:00 grep --color=auto mysqld -
构建主从
数据库实例3307mysql [(none)]>grant replication slave on *.* to repl@'192.168.1.%' identified by '123456'; Query OK, 0 rows affected, 1 warning (0.12 sec)数据库实例3308/数据库实例3309
mysql [(none)]>change master to -> master_host='192.168.1.5', -> MASTER_PORT=3307, -> master_user='repl', -> master_password='123456' , -> MASTER_AUTO_POSITION=1; Query OK, 0 rows affected, 2 warnings (0.13 sec) mysql [(none)]>start slave; Query OK, 0 rows affected (0.10 sec) -
GTID从库误写入操作处理
查看监控信息产生错误
Last_SQL_Error: Error 'Can't create database 'oldboy'; database exists' on query. Default database: 'oldboy'. Query: 'create database oldboy' Retrieved_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3 --从主库请求的 Executed_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-2, --实际运行的 7ca4a2b7-4aae-11e9-859d-000c298720f6:1由于71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3操作有问题，可以采取注入空事务的方法，跳过该错误（有风险）：
> stop slave; --停止slave服务 > set gtid_next='99279e1e-61b7-11e9-a9fc-000c2928f5dd:3'; --手工设置操作xxxxx:N 就是slave_sql_thread报错的GTID，或者是想要跳过的GTID > begin;commit; --注入空事物 > set gtid_next='AUTOMATIC'; --设置回自动操作注入空事务的方式有风险，最好的解决方案：重新构建主从环境。
GTID复制与普通复制的区别
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
0. 在主从复制环境中，主库发生过的事务，在全局都是由唯一GTID记录的，更方便Failover;
1. gtid-mode=on 、enforce-gtid-consistency=true 、log-slave-update=1;
2. change master to 的时候不再需要binlog 文件名和position号，直接auto即可，MASTER_AUTO_POSITION=1;
3. 在复制过程中，从库不再依赖master.info文件，而是直接读取最后一个relaylog的 GTID号，获取到上次复制的GTID号后从此号开始向后复制即可;
4. 在MHA高可用环境下，主库无法SSH时，从库进行数据恢复更加便捷;
5. mysqldump备份时，默认会将备份中包含的事务操作，以以下方式:
SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';
告诉从库，我的备份中已经有以上事务，你就不用运行了，直接从下一个GTID开始请求binlog就行。
主从复制架构演变
基础架构（无需三方软件支持）
单向主从复制架构图（只能在Master端写入数据）
一主多从复制架构图（只能在Master端写入数据）
双向主主复制架构图（两端Master均可写入数据）
线性级联单向双主复制架构图（只能在Master1端写入数据）
环状级联单向多主复制架构图（任意一点均可写入数据）
MySQL Group Replication（MGR）框架让MySQL具备了自动主从切换和故障恢复能力。MySQL Group Replication（MGR）是MySQL官方推出的一种基于Paxos协议的状态机复制。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-sync replication），从而进一步提示数据复制的强一致性。
高级架构（需要三方软件支持）
-
高可用架构
单活：Keepalived + 双主 + 一从（MMM架构）、MHA
多活：NDB Cluster（收费）、InnoDB Cluster、PXC（Percona XtraDB Cluster）、MGC（MariaDB Galera Cluster） -
高性能架构
读写分离架构：Atlas（360）、Cobar、ProxySQL（Percona）、MySQL Router（Oracle）、Maxscale、Mycat
分布式架构：Atlas-Sharding（360）、Mycat（开源）、TDDL（Taobao）
企业高可用标准
-
全年无故障率（非计划内故障停机）
99.9% ----> 0.001*365*24*60=525.6 min 99.99% ----> 0.0001*365*24*60=52.56 min 99.999% ----> 0.0001*365*24*60=5.256 min -
高可用架构方案
负载均衡：有一定的高可用性（高可用最低的标准） LVS、Nginx 主备（单活架构）：有高可用性，但是需要切换（切换的过程无法提供服务） Keepalived、MHA 真正高可用（多活系统）：NDB Cluster、Oracle RAC、Sysbase Cluster、InnoDB Cluster（MGR）、Percona PXC、MGC