DAY6-MySQL复制

MySQL复制的了解

MySQL-3.22版本开始支持复制（statement)

利用复制，添加从库，通过从库提升读的能力及主库故障可以在从库里提升出来一个新的主库，从而达到高可用的目的。

目前MySQL为了支持多引擎的主从复制，引入了一个Binary Log，所有的复制都是基于Binary Log实现

现在标准的选择的：Row + GTID复制

理解binlog

根据日志格式分：statement ， row ， mixed
记录最小的单位是一个Event，日志前4个字节是一个magic number，接下19个字节记录Format desc event : FDE
一个事务由多个event组成
binlog相关的包含：mysql-bin.000001 和 mysql-bin.index文件
5.6开始增加了GTID复制

statement格式

基于语句级的复制 :binlog_format=statement
优点：
binlog 文件较小
日志包含用户执行的原始sql ，方便统计和审计
出现最早可binlog兼容较好
binlog方便阅读，方便故障修复
缺点：
存在安全隐患，可能导致主从不一致
对一些系统函数不能准复制或是不能复制
load_file()
uuid()
user()
found_rows()
sysdate()

row格式

优点：
相比statement更加安全的复制格式 binlog_format=row
在某些情况下复制速度更快（sql复杂，表有主键）
系统的特殊函数也可以复制
更少的锁
缺点：
binlog 比较大（支持binlog_log_image)
但语句更新（删除）表的行数过多，会形成大量binlog
无法从binlog看见用户执行sql（event：binlog_row_query_log_events,记录用户的query）
mysqlbinlog -v --base64-output=decode-rows mysql-bin.000001

row格式主从
不管主库sql是什么，从库都会根据主键去执行，所以表必须创建主键，或索引，否则全表扫。

mix格式

ddl dcl记录statement，dml记录row

扫描二维码关注公众号，回复： 1068528 查看本文章

GTID

global transaction identifiers 全局事务，每个事务编号
一个事务对应一个唯一ID
一个GTID在一个服务器上只会执行一次
GTID是用来替代以前classic的复制方法

GTID组成：
server_uuid:sequece_number

开启GTID，my.cnf添加

[mysqld]
#GTID
gtid_mode=on
enforce-gtid-consistency=on
#bin log
log-bin=mysql-bin
log-slave-updates=1
server-id=ip最后+$PORT

复制环境搭建

基于binlog+file position方式的复制
1、创建同步用户：

grant replication slave on *.* to 'repl'@'%' identified by 'repl';

flush privileges;

2、在主库上做备份
mysqldump --master-data=2 --single-transaction -A > db3306_`date+%Y%m%d`.sql
3、拷贝备份集到从库，并恢复数据

time mysql -uroot -p -S /tmp/my3306.sock < /tmp/db.sql (time 可以看执行时间）
4、从库配置主从信息

change master to master_host='192.168.1.12',master_port=3306,master_user='repl',master_password='repl',master_log_file='mysql-bin.000005',master_log_pos=333;

建议生产从库配置log_slave_updates

基于GTID环境搭建

1、创建同步用户：