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

640?wx_fmt=gif&wxfrom=5&wx_lazy=1&retryload=1


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;


MySQL 传统复制与 GTID 复制原理及操作详解_第1张图片


添加一个新的从库,获取主库上一个带 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;


MySQL 传统复制与 GTID 复制原理及操作详解_第2张图片

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

复制参数


MySQL 传统复制与 GTID 复制原理及操作详解_第3张图片


转载自 | csdn 博客

原文链接 | http://blog.csdn.net/thundermeng/article/details/50401150


资源下载

关注公众号:数据和云(OraNews)回复关键字获取

‘2017DTC’,2017 DTC 大会 PPT

‘DBALIFE’,“DBA 的一天”海报

‘DBA04’,DBA 手记4 经典篇章电子书

‘RACV1’, RAC 系列课程视频及 PPT

‘122ARCH’,Oracle 12.2 体系结构图

‘2017OOW’,Oracle OpenWorld 资料

‘PRELECTION’,大讲堂讲师课程资料

640?wx_fmt=png


你可能感兴趣的:(MySQL 传统复制与 GTID 复制原理及操作详解)