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
MySQL5.6增加了GTID复制

classic主从配置

主/从库核心配置
[mysqld]
log-bin
server-id #主从库server-id要不一致
gtid_mode=off #禁掉gtid

#主库配置
grant replication slave on *.* to 'repl'@'%' identified by 'repl4slave';
flush privileges;

添加从库

#添加一个新的从库，获取主库上一个带binlog及pos偏移量的备份，在从库上恢复后
>change master to
master_host='192.168.199.117',
master_user='repl',
master_port=7000,
master_password='repl4slave',
master_log_file='mysql-bin.000001',
master_log_pos=200;
>start slave;
>show slave status\G;

错误跳过

stop slave;
set global sql_slave_skip_counter=1;
start slave;
show slave status\G;

GTID主从配置

一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次，GTID是用来替代以前classic的复制方法，mysql5.62支持，mysql5.6.10后完善

优点：相对于行复制来讲数据安全性更高，故障切换更简单

主从库核心配置

[mysqld]
#GTID:
gtid_mode=on
enforce-gtid-consistency=on
#binlog
log-bin=mysql-bin
log-slave-updates=1（从库要是想写binlog，打开此参数）

添加从库

GTID添加从库有两种方法：
1.如果master所有的binlog还在，安装slave后，直接change master 到master，原理是直接获取master所有的gtid并执行
优点是简单
缺点是如果binlog太多，数据完全同步需要的时间较长，并且需要master一开始就启用了GTID
总结：适用于master也是新建不久的情况
2.通过master或者其它slave的备份搭建新的slave.
原理：获取master的数据和这些数据对应的GTID范围，然后通过在slave设置@@GLOBAL.GTID_PURGED从而跳过备份包含的GTID
优点是可以避免第一种方法中的不足
缺点操作相对复杂
总结：适用于拥有较大数据集的情况

mysqldump在备份的时候需要指定--master-data=2
导出的语句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';
恢复时，需要先在slave上执行一个reset master;再执行change master to

perconaxtrabackup
xtrabackup_binlog_info包含了GTID在信息
做从库恢复后，需要手工设置：
set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';
恢复后，执行change master to

>change master to
master_host='192.168.199.117',
master_user='repl',
master_port=7000,
master_password='repl4pass',
master_auto_position=1;

错误跳过

stop slave;
set gtid_next='xxxxxxxx:N';
begin;
commit;
set gtid_next='automatic';
start slave;

对比图

rpel	change master	error
classic	change master to master_host='192.168.199.117', master_user='repl', master_port=7000, master_password='repl4pass', master_log_file='mysql-bin.000008', master_log_pos=896;	stop slave; set global sql_slave_skip_counter=1; start slave; show slave status\G;
GTID	change master to master_host='192.168.199.117', master_user='repl', master_port=7000, master_password='replpass', master_auto_position=1;	stop slave; set gtid_next='xxxxxxxx:N'; begin; commit; set gtid_next='automatic'; start slave;

GTID限制

不支持非事务引擎（从库报错，stopslave; start slave; 忽略）
不支持create table … select 语句复制（主库直接报错）
不允许在一个SQL同时更新一个事务引擎和非事务引擎的表
在一个复制组中，必须要求统一开启CTID或是关闭GTID
开启DTID需要重启（5.7中可能不需要）
开启DTID后，就不在使用原来的传统的复制方式
对于createtemporary table 和drop temporary table语句不支持
不支持sql_slave_skip_counter

MySQL复制默认是异步复制，Master将事件写入binlog，但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下，如果Master宕机，事务在Master上已提交，但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制，此时Slave也可能会丢失事务。

binlog_format区别

级别	优点	缺点
statement	binlog文件较小 日志是包含用户执行的原始SQL,方便统计和审计 出现最早，兼容较好	存在安全隐患，可能导致主从不一致 对一些系统函数不能准确复制或是不能复制
row	相比statement更加安全的复制格式 在某些情况下复制速度更快（SQL复杂，表有主键） 系统的特殊函数也可以复制 更少的锁 更新和删除语句检查是否有主键，如果有则直接执行，如果没有，看是否有二级索引，如再没有，则全表扫描	binlog比较大（myql5.6支持binlog_row_image） 单语句更新（删除）表的行数过多，会形成大量binlog 无法从binlog看见用户执行SQL（5.6中增加binlog_row_query_log_events记录用户的query）
mixed	混合使用row和statement格式，对于DDL记录statument,对于table里的行操作记录为row格式。 如果使用innodb表，事务级别使用了READ_COMMITTED or READ_UMCOMMITTED日志级别只能使用row格式。 但是使用ROW格式中DDL语句还是会记录成statement格式。	mixed模式中，那么在以下几种情况下自动将binlog模式由SBR模式改成RBR模式。 当DML语句更新一个NDB表 当函数中包含UUID时 2个及以上auto_increment字段的表被更新时 行任何insert delayed语句时 用UDF时 视图中必须要求使用RBR时，例如创建视图使用了UUID()函数

复制参数

master

slave

log-bin=/data/mysql/mysql3316/logs/mysql-bin server-id=[ip]port log-bin-index=mysql-bin.index binlog_format=row binlog_cache_size=1M max_binlog_size=1G sync_binlog=0 expire_logs_days=7 log_bin_trust_function_creators=1 #使用存储过程或函数打开   enforce-gtid-consistency=1 gtid-mode=on gtid-next gtid-purged gtid-execued 执行过的gtid                                     复制过滤 建议能不用就不用，如果必须用，在从库上操作，不要在主库上设置   ==================== binlog-do-db binlog-ignore-db

server-id log_slave_updates #会把复制的binlog也写到binlog中 relay_log_recover=1 #在slave崩溃或正常启动时，未应用完的relay_log会被删掉，重新从master请求binlog再次生成relay_log skip-slave-start slave_transaction_retries #slave复制中，如果因为innodb死锁或者锁超时导致复制线程执行的事务失败重试次数，一般为5 slave_parallel_workers #5.6引入基于库计并发复制的功能，默认是关闭的 read-only #打开只读，但对有super权限的用户无效 slave_net_timeout = 10#默认3600s slave_skip_errors   log-slow-slave-statements #默认复制慢语句不会记录到慢日志中，启动此功能，会把复制中超过long_query_time的语句记录到慢日志中 max_relay_log_size 设置relay_log的最大大小，建议不设置 relay-log-info-file #relay_log的索引文件 relay_log_purge 默认开启，在relay_log使用完毕后，尽可能的清理掉 replicate-same-server-id 对于相同的server-id的binlog event默认不执行 slave_load_tmpdir 对于复制load data in file语句，slave指定创建临时文件的目录，默认是tmpdir relay_log_space_limit 限制relay_log战胜磁盘的总大小   =========================== #slave to filter replicate-do-db replicate-ignore-db repicate-rewrite-db 如果master和slave有个库同名了，可使用rewrite规则，将这个库上的复制重写到另一个新的库上 replicate-do-table replicate-ignore-table replicate-wild-do-table replicate-wild-ignore-table

官方半同步复制的概念：
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