MySQL 传统复制与 GTID 复制原理及操作详解
MySQL 复制在业界里有叫：mysql 同步，ab 复制等。专业名称就是叫：复制。
复制是单向的，只能从 master 复制到 slave 上，延时基本上是毫秒级别的。
一组复制结构中可以有多个 slave，对于 master 一般场景推荐只有一个。
master 用户写入数据，生成 event 记到 binary log 中 slave 接收 master 上传来的 binlog，然后按顺序应用，重现 master 上的用户操作。
记录最小的单位是一个 event，日志前 4 个字节是一个 magic number, 接下来 19 个字节记录 formatt desc event:FDE
MySQL 5.6 增加了 GTID 复制
1、classic 主从配置
核心配置
[mysqld]
log-bin
server-id
gtid_mode=off #禁掉 gtid
grantreplication slave on *.* to 'repl'@'%' identified by 'repl4slave';
flushprivileges;
添加一个新的从库，获取主库上一个带 binlog 及 pos 偏移量的备份
在从库上恢复后执行
>changemaster to
master_host='192.168.199.117',
master_user='slave',
master_port=7000,
master_password='slavepass',
master_log_file='mysql-bin.000008',
master_log_pos=896;
启动 slave，并查看状态
>start slave;
>show slave status\G;
如果遇到错误，可以跳过：
stop slave;
set globalsql_slave_skip_counter=1;
start slave;
show slave status\G;
2、复制配置
一个事务对应一个唯一 ID，一个 GTID 在一个服务器上只会执行一次，GTID 是用来替代以前 classic 的复制方法，mysql 5.62 支持，mysql 5.6.10 后完善
优点：
相对于行复制来讲数据安全性更高，故障切换更简单
配置 GTID
[mysqld]
#GTID:
gtid_mode=on
enforce-gtid-consistency=on
#binlog
log-bin=mysql-bin
log-slave-updates=1
GTID 添加从库有两种方法：
1、如果 master 所有的 binlog 还在，安装 slave 后，直接 changemaster 到 master，原理是直接获取 master 所有的 gtid 并执行，优点是简单。缺点是如果 binlog 太多，数据完全同步需要的时间较长，并且需要 master 一开始就启用了 GTID。
总结：适用于 master 也是新建不久的情况
2、通过 master 或者其它 slave 的备份搭建新的 slave，原理：获取 master 的数据和这些数据对应的 GTID 范围，然后通过在 slave 设置 @@GLOBAL.GTID_PURGED 从而跳过备份包含的 GTID，优点是可以避免第一种方法中的不足，缺点操作相对复杂。
总结：适用于拥有较大数据集的情况
GTID 添加从库：
1、用 mysqldump 工具，在备份的时候需要指定 --master-data
导出的语句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497'; 恢复时，需要先在 slave 上执行一个 reset master，再执行 change master to
2、用 percona xtrabackup 工具
xtrabackup_binlog_info 包含了 GTID 在信息
做从库恢复后，需要手工设置：
set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';
恢复后，执行
>change master to
master_host='192.168.199.117',
master_user='slave',
master_port=7000,
master_password='slavepass',
master_auto_position=1;
错误跳过
stop slave;
setgtid_next='xxxxxxxx:N';
begin;
commit;
setgtid_next='automatic';
start slave;
GTID 的限制：
1、不支持非事务引擎（从库报错，stopslave; start slave; 忽略）
2、不支持 create table … select 语句复制（主库直接报错）
3、不允许在一个 SQL 同时更新一个事务引擎和非事务引擎的表
4、在一个复制组中，必须要求统一开启 CTID 或是关闭 GTID
5、开启 DTID 需要重启（5.7 中可能不需要）
6、开启 DTID 后，就不在使用原来的传统的复制方式
7、对于 createtemporary table 和 drop temporary table 语句不支持
8、不支持 sql_slave_skip_counter
MySQL 复制默认是异步复制，Master 将事件写入 binlog，但并不知道 Slave 是否或何时已经接收且已处理。在异步复制的机制的情况下，如果 Master 宕机，事务在 Master 上已提交，但很可能这些事务没有传到任何的 Slave 上。假设有 Master->Salve 故障转移的机制，此时 Slave 也可能会丢失事务。
官方半同步复制的概念：
1. 当 Slave 主机连接到 Master 时，能够查看其是否处于半同步复制的机制。
2. 当 Master 上开启半同步复制的功能时，至少应该有一个 Slave 开启其功能。此时，一个线程在 Master 上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的 Slave 已收到此事务的所有事件，或等待超时。
3. 当一个事务的事件都已写入其 relay-log 中且已刷新到磁盘上，Slave 才会告知已收到。
4. 如果等待超时，也就是 Master 没被告知已收到，此时 Master 会自动转换为异步复制的机制。当至少一个半同步的 Slave 赶上了，Master 与其 Slave 自动转换为半同步复制的机制。
5. 半同步复制的功能要在 Master，Slave 都开启，半同步复制才会起作用；否则，只开启一边，它依然为异步复制。
同步（社区增强半同步），异步，半同步复制的比较：
同步复制：Master 提交事务，直到事务在所有的 Slave 都已提交，此时才会返回客户端，事务执行完毕。缺点：完成一个事务可能会有很大的延迟。
异步复制：当 Slave 准备好才会向 Master 请求 binlog。缺点：不能保证一些事件都能够被所有的 Slave 所接收。
半同步复制：半同步复制工作的机制处于同步和异步之间，Master 的事务提交阻塞，只要一个 Slave 已收到该事务的事件且已记录。它不会等待所有的 Slave 都告知已收到，且它只是接收，并不用等其完全执行且提交。
半同步，开启后严重影响性能
解决主库不关心日志是否被从库读到半同步配置，在 master 和 slave 上都配置：
master
[mysqld]
rpl_semi_sync_master_enabled=1
rp;_semi_sync_master_timeout=1000#1s
slave
[mysqld]
rpl_semi_sync_slave_enabled=1
复制参数
转载自 | csdn 博客
原文链接 | http://blog.csdn.net/thundermeng/article/details/50401150