MySQL主从复制

---

主从复制基础

主从复制简介

MySQL数据库的主从复制方案，与使用scp/rsync等命令进行的文件级别复制类似，都是数据的远程传输，只不过MySQL的主从复制是自带的功能。MySQL的主从复制并不是数据库磁盘上的文件直接拷贝，而是将二进制日志binlog复制到要同步的服务器本地，然后由本地的线程读取日志里面的SQL语句，重新应用到MySQL数据库中。

1. 基于二进制日志binlog进行复制
2. 主库的修改操作会记录到二进制日志文件中
3. 从库会请求新的二进制日志并回放，最终达到主从数据同步
4. 主从复制核心功能：辅助备份，处理数据库物理损坏
   什么是逻辑损坏？drop、delete truncate等在数据库内部的误操作
   什么是物理损坏？操作系统层次的损坏（数据库外部的损坏）

问：主从复制可以替代数据库的备份？
答：主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）；对逻辑损坏还是需要通过备份进行恢复。

主从复制前提

1. 两台以上mysql实例 ：server_id、server_uuid不同
2. 主库开启二进制日志
3. 主库需建立专用的复制用户（replication slave）
4. 建立主库全备（适用于主库运行很久后需要建立从库的情况），保证主从开启之前的某个时间点,从库数据和主库一致
5. change master to：告知从库主库的IP、Port、user、passwd以及复制的起点（file，position）
6. start slave：开启专用的复制线程（主库：binlog_dump_T 、从库：thread IO thread 、SQL thread）

主从复制搭建

主库配置（3307实例）

1. 创建数据目录并赋予权限进行初始化

   [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
   

2. 编辑配置文件，开启二进制日志功能

   [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
   

3. 启动主库数据库实例3307

   [root@localhost data]# systemctl start mysqld3307
   [root@localhost data]# mysql -uroot -S /data/3307/mysql.sock
   

4. 检查是否开启二进制日志文件

   [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
   

5. 创建专用复制用户

   [root@localhost ~]# mysql -uroot -S /data/3307/mysql.sock 
   
   mysql [(none)]>grant replication slave on *.* to slave@'192.168.1.%' identified by '123456';
   

6. 建立主库全备（若主库都是刚搭建可以省略该步骤）

   [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;
   

7. 查看主库状态

   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实例）

1. 从库模拟恢复主库全备，保证主从开启之前的某个时间点，从库数据和主库一致

   [root@localhost ~]# mysql -uroot -S /data/3308/mysql.sock
   
   mysql [mysql]>set sql_log_bin=0;
   mysql [mysql]>source /data/3307/backup/full.sql
   

2. 告知从库主库的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)
   

3. 开启主从专用线程

   mysql [(none)]> start slave;
   

4. 检查复制状态

   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

主从复制图解原理

1. change master to命令：主库的ip port user password binlog position写入到master.info进行记录；
2. start slave 命令：从库会启动Slave_IO_Thread和Slave_SQL_Thread；
3. Slave_IO_Thread读取master.info信息，获取主库信息并连接主库；
4. 主库会生成一个Binlog_Dump_Thread来响应从库；
5. Slave_IO_Thread根据master.info记录的binlog文件名和position号，请求主库Binlog_Dump_Thread最新日志；
6. Binlog_Dump_Thread检查主库的binlog日志，如果有新日志生成，TP(传送)给从库的Slave_IO_Thread（主库一旦有新的日志生成，会发送信号给Binlog_Dump_Thread，IO线程再请求）；
7. Slave_IO_Thread将收到的日志存储到了TCP/IP 缓存，并立即返回ACK给主库 ，主库工作完成；
8. Slave_IO_Thread将缓存中的数据存储到relay-log中继日志文件，并更新master.info文件binlog 文件名和postion，Slave_IO_Thread工作完成；
9. Slave_SQL_Thread读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log；
10. Slave_SQL_Thread回放完成之后，会更新relay-log.info文件；
11. 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 进行定期清理主库二进制日志。

处理故障过程

重新搭建主从环境

1. 从库停止slave服务

   > stop slave;
   

2. 重置从库信息

   > reset slave all;
   > show slave status \G 
   

3. 重新搭建从库

   > change master to
   > start slave;
   

SQL线程故障

SQL线程故障原因分析

1. 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响；
2. 要创建的数据库对象已经存在；
3. 要删除或修改的对象不存在 ；
4. 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)
  

• 方法二：加入中间件实现读写分离

主从延时分析

主库做了修改操作,从库比较长时间才能追上。

外在因素

1. 网络
2. 主从硬件差异大
3. 版本差异
4. 参数因素

主库因素

原因分析：

1. 二进制日志写入不及时

   mysql [(none)]>select @@sync_binlog;
   +---------------+
   | @@sync_binlog |
   +---------------+
   |             1 |
   +---------------+
   1 row in set (0.01 sec)
   

2. 传统模式的主从复制中，binlog_dump线程以事件为单元串行传送二进制日志(版本5.5 5.6)
   a. 主库并发事务量大,主库可以并行,传送时是串行
   b. 主库发生大事务,由于是串行传送,会阻塞后续的事务
3. 一主多从情况下，主库有很多DUMP线程，传输压力大（架构层面）

解决方案:

1. MySQL 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO
2. MySQL 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,但建议还是开启GTID
3. 大事务拆成多个小事务,可以有效的减少主从延时

从库因素

原因分析：

SQL线程导致的主从延时。在传统模式主从复制中，从库默认情况下只有一个SQL，只能串行回放事务SQL

1. 主库如果并发事务量较大,从库只能串行回放
2. 主库发生了大事务,会阻塞后续的所有的事务的运行

解决方案:

1. MySQL 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放（同一个库内依然是串行回放，防止出现逻辑问题）
2. MySQL 5.7 版本开启GTID之后,在SQL方面,提供了逻辑时钟(logical_clock),binlog加入了seq_no（sequence number，序列号）机制,
   真正实现了基于事务级别的并发回放,这种技术称之为MTS(enhanced multi-threaded slave)
3. 大事务拆成多个小事务,可以有效的减少主从延时

主从复制进阶

延时从库

延时从库是一种特殊从库，通过人为配置从库和主库延时N小时。

延时从库原因

主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）。如果发生了逻辑损坏，就需要备份恢复，但如果恢复数量级很大的话，时间成本很高。

因此延时从库是为了更快的解决逻辑损坏问题的从库（备份恢复的替代方案）。

延时从库配置

SQL线程延时：数据已经写入relay-log中，但SQL线程慢点执行relay-log中的语句。
一般企业建议延时3-6小时，具体看公司运维人员对于故障的反应时间。

延时从库配置

1. 停止slave服务

   mysql [(none)]>stop slave;
   Query OK, 0 rows affected, 1 warning (0.05 sec)
   
   

2. 修改MASTER_DELAY参数

   mysql [(none)]>CHANGE MASTER TO MASTER_DELAY=300;
   Query OK, 0 rows affected (0.32 sec)
   
   

3. 开启slave服务

   mysql [(none)]>start slave;
   

4. 查看延时状态

   mysql [(none)]>show slave status \G;
   
                       SQL_Delay: 300   --延时时间
             SQL_Remaining_Delay: 295   --延时倒计时
   

5. 查看二进制日志是否一致

   # 主库
   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个库。

逻辑故障恢复思路：

1. 5分钟之内及时侦测到误删除操作
2. 立即停止延时从库SQL的线程
3. 挂维护页
4. 截取relay-log日志进行恢复
   起点 ：停止SQL线程时的relay-log位置点
   终点 ：误删除之前的position(GTID)
5. 截取的日志恢复到从库
6. 从库身份解除,替代主库工作

故障模拟及恢复：

1. 模拟主库数据操作

   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;
   

2. 发现故障，停止从库的SQL线程

   mysql [none]> stop slave sql_thread;
   

3. 找到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
   

4. 从库恢复relay-log

   mysql [relay]>source /tmp/relay.sql
   

5. 从库身份解除，从库替代主库身份（数据量比较小的话可以考虑直接将数据导入主库）

   mysql [relay]>stop slave;
   mysql [relay]>reset slave all;
   

半同步复制

半同步复制用来解决主从数据一致性问题。

• MySQL 5.5 版本出现
• MySQL 5.6 增强
• MySQL 5.7 完善，5.7.17后出现MGR复制

1. 主库执行新的事务commit时，更新 show master status\G ，触发一个信号给Binlog_Dump_Thread；
2. Binlog_Dump_Thread 接收到主库的 show master status\G 信息,通知从库日志更新；
3. 从库Slave_IO_Thread 请求新的二进制日志事件;
4. 主库会通过 Binlog_Dump_Thread 传送新的日志事件给从库Slave_IO_Thread；
5. 从库Slave_IO_Thread接收到binlog日志，当日志写入到磁盘上的relaylog文件时，给主库ACK_receiver线程发送确认；
6. ACK_receiver线程触发一个事件，告诉主库commit可以成功了；
7. 如果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环境

1. 创建数据目录并授予权限

   [root@localhost ~]# mkdir -p /data/330{7,8,9}/data
   [root@localhost ~]# chown -R mysql.mysql /data/330{7,8,9}
   

2. 准备各实例的配置文件

   [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]>
   

3. 初始化各实例数据目录

   [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
   

4. 启动各数据库实例

   [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
   

5. 构建主从
   数据库实例3307

   mysql [(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)
   
   

6. 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