MySQL传统复制与GTID复制原理及操作详解

MySQL传统复制与GTID复制原理及操作详解

作者：thundermeng转自：http://blog.csdn.net/thundermeng/article/details/50401150

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复制

1、classic主从配置

核心配置

[mysqld]log-binserver-idgtid_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的复制方法，mysql5.62支持，mysql5.6.10后完善

优点：

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

配置GTID

[mysqld]#GTID:gtid_mode=onenforce-gtid-consistency=on#binloglog-bin=mysql-binlog-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的限制：

不支持非事务引擎（从库报错，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也可能会丢失事务。

官方半同步复制的概念：

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=1rp;_semi_sync_master_timeout=1000#1s

slave

[mysqld]rpl_semi_sync_slave_enabled=1

复制参数

近期技术活动

运维帮技术沙龙「运维架构与安全体系」北京站·8月6号·免费中国应用性能管理大会-APMCon（详情如下）

输入ywb优惠码，可以优惠500RMB

输入ywb优惠码，可以优惠500RMB

↓↓↓