MySQL5.7复制基础
MySQL的复制是异步复制,因此会有一定的延迟,这个延迟与组上写数据的频率有很大的关系
主从复制同步:
*---------------------------------------------------
主从复制延迟总是存在的,可以用假一致性来避免用户在感知上的延迟。比如用户刚刚发了一条帖子,但读操作是在从节点上,这时刚刚插入的数据还没有被同步,但用户要查看刚刚发布的帖子,我们就把读操作暂时转到主节点上,这样就暂时消除了一致性问题。
MySQL的复制是基于BinLog日志,BinLog中存储的是SQL语句
存在三种日志格式
- Statement:这种格式存储的数据量是最小的,它独特的序列化结构在执行如update,insert语句是,使用了聚合函数,可能会造成主从数据不一致。因为这些数据都是由系统运算得来的。所以不建议将这种格式用于生产环境。存储的是sql
- Row:存储event数据,存储日志量大,但不能很直接的进行读取。存储的是实际的数据的变更。由于量大,因此会对带宽造成影响该。
- Mixed:介于Row和Statement之间,对不确定的操作使用Row记录,如果每天数据操作量很大,产生的日志较多,可以考虑使用mixed格式。
MySQL复制可以是对整个实例进行复制,也可以对事例中某个库或某个表进行复制。也称为部分复制,我们可以对master或slave端的配置文件进行修改对复制的内容进行控制。
- master端进行控制的指令:
–binlog-do-db
–binlog-ignore-db 执行/忽略对某数据库的复制 - slave端:
–replicate-do-db
–replicate-ignore-db
–replicate-do-table
–replicate-ignore-table
–replicate-wild-do-table
–replicate-wild-ignore-table 控制对哪个数据库、表的复制
因此建议在slave端对控制库/表进行复制,控制的颗粒度更小。通常要保证master对所有日志的记录,而非进行日志的过滤
MySQL的两种复制类型:
- 基于二进制日志的复制
使用这种类型的复制,要求明确的知道当前从节点上的数据对应主节点上的日志文件和日志点,尤其是在一主多从情况下,mysql的日志文件是在不同服务器上的,其日志文件和日志点的记录是不一样的,在一主多从的情况下,主宕机的话,要在几个从节点中选举出一个。此时的难点就在于新的主一从节点同步。因为我们无法确定新的主节点上对应从节点上的日志点。因此在5.6之后引入了GTID复制 - 使用GTID完成基于事务的复制:
实现方式就是在每一个master节点上提交的事务都会被赋予一个全局唯一标识,标识由两部分组成,一部分是主机的标识,另一部分是事务的ID。那么在从上二次执行的时候就会明确知道哪个事务在从节点上已经执行过。这样就可以不用知道主节点对应从节点的日志点了。基于事务的复制在数据完整性上更加的可靠。在主从切换上提供方便。
mysql支持半同步复制
上文提及过,MySQL的复制是异步复制,在master提交完事务会把日志写入到BinLog中,master此时不会知道slave何时会得到BinLog日志,鉴于此,我们可以在主从节点上安装插件实现半同步复制。
master提交事务之后会将IO阻塞,直到从节点接收并把日志保存到磁盘上之后,slave节点的进程才会告诉master的进程事务执行完成。只有当至少一个支持半同步的slave节点确认日志写到BinLog后,才会继续这一过程。所以当集群上有多个slave节点时,我们可以设置几个slave节点确认之后,才进行下面的操作。
但使用半同步并不会减少主从的延迟,因为它并不是真正的同步复制,反而会降低SQL的执行效率,因为我们在网络并不是很稳定的环境下,主节点如果长时间没有接收到从节点的确认的话,那主节点上的进程可能会一直被阻塞,因此可能会延迟主上写入的效率。这个延迟最大时间可通过参数来控制,但这个延迟会造成主从复制事件上的安全性,因为在主节点宕机的情况下,完全异步复制时,我们无法保证主节点事务完全被从节点复制。如果是半同步复制情况下,则可以保证能被完全复制。尤其是在MySQL5.7之后,半同步复制得到增强。
MySQL5.6 和 5.7日志复制的差别
实现基于日志点的复制
- 在master端建立复制用户
这个复制用户就是用于存slave端读取master端的日志所使用的用户。
/**创建用户
create user 'dba'@'192.168.100.%' identified by '123456';
/**授权
grant replication slave on *.* to dba@'192.168.100.%';
- 备份Master端的数据,并在Slave端恢复。
在备份数据时,要指定master data 参数,并在slave端对其进行恢复
/** master端备份
mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases -uroot -p> all.sql、
/**slave端恢复
mysql -uroot -p < all.sql
- 在Slave端使用Change master命令配置复制。
使用记录的日志文件和日志点进行复制。
/**备份命令
change master to master_host='192.168.100.192',master_user='dba',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=154;
/**启动从节点
start slave
/**查看从节点状态
show slave status \G
/** 状态中代表同步健康的标志
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
查看主从管理的系统视图
performance_schema数据库中有5.7新增的为主从同步服务的表。
replication_***都是
replication_applier_configuration表中存放的是数据链路的名字和主从延迟(反悔期,在这时间内不想同步的话,可用从节点上未同步的数据进行恢复)。
replication_applier_status表中放的是一些同步的状态。SERVICE_STATE:同步状态;REMAINING_DELAY:主从延迟倒计时。
replication_applier_status_by_coordinator表存的是多线程复制中控制器的状态。
replication_applier_status_by_worker表存的是使用到的线程信息。
如何在线变更数据类型
- 在线将基于日志的复制变更为基于事务的复制
- 先决条件:
1集群中所有服务器数据库版本都高于5.7.6
2集群中所有服务器gtid_mode都设为off
/** 查看MySQL版本
show variables like '%version%';
/** 查看gtid状态是否为off
show variables like '%gtid_mode%';
- 处理步骤
/**设置强制id为warn状态
set @@global.enforce_gtid_consistency = warn;
set @@global.enforce_gtid_consistency = on; ********
set @@global.gtid_mode= off_permissive;
set @@global.gtid_mode= on_permissive;
show status like 'ongoing_anonymous_transaction_count';
set @@global.gtid_mode= on ; *********
stop slave;
change master to master_auto_position = 1;
start slave;
将*******的两个参数加入到/etc/my.cnf中,下次启动mysql就默认是基于事务的复制
/** 若AUTO_POSITION 值为1 ,则基于事务的复制已开启
select * from replication_connection_configuration\G
- 在线将基于事务的复制变更为基于日志的复制
- 先决条件:
1集群中所有服务器数据库版本都高于5.7.6
2集群中所有服务器gtid_mode都设为on
/** 查看MySQL版本
show variables like '%version%';
/** 查看gtid状态是否为off
show variables like '%gtid_mode%';
- 处理步骤
stop slave;
/** 告诉从节点的日志文件和日志点是什么,重启slave节点
change master to master_auto_position = 0 ,master_log_file='file',master_log_pos=position start slave;
set @@global.gtid_mode= on_permissive;
set @@global.gtid_mode= off_permissive;
/** 结果为空值才执行下一命令
select @@global.gtid_owned;
set @@global.gtid_mode= off;
将上述1中*******的两个参数从/etc/my.cnf中删除
多源(master)复制
多源复制也就是多master复制,允许一个slave对应多个master。好处就是跨库表操作时,把多表复制到一个数据库。
新建一个服务器数据库N3,开启gtid_mode和创建用户并授权
使用changeMaster命令:
change master to master_host='192.168.100.87',master_user='dba',master_password='123456',
master_auto_position = 1 for channel 'N3';
管理视图查看
use performance_schema;
show tables like 'replication%';