mysql异步复制参数_mysql 异步复制，半同步复制

最新推荐文章于 2022-12-29 17:17:58 发布

酉迟

最新推荐文章于 2022-12-29 17:17:58 发布

阅读量134

点赞数

文章标签： mysql异步复制参数

本文链接：https://blog.csdn.net/weixin_35582019/article/details/113143309

版权

Mysql复制

什么是Mysql复制？

复制是指将主数据库的 DDL和DML操作通过二进制日志传到复制服务器(也叫从库)上,然后在从库上对这些日志重新执行(也叫重做),从而使得从库和主库的数据保持同步。MysQL支持一台主库同时向多台从库进行复制,从库同时也可以作为其他服务器的主库,实现链状的复制。

注意:

由于MySQL实现的是并不是完全同步的复制,所以主从库之间存在一定的差距,在从库上进行的査询操作需要考虑到这些数据的差异,一般只有更新不频繁的数据或者对实时性要求不高的数据可以通过从库查询,实时性要求高的数据仍然需要从主数据库获得。

名称解释：

DML(data manipulation language)数据操纵语言：

就是我们最经常用到的 SELECT、UPDATE、INSERT、DELETE。主要用来对数据库的数据进行一些操作。

DDL(data definition language)数据库定义语言：

其实就是我们在创建表的时候用到的一些sql，比如说：CREATE、ALTER、DROP等。DDL主要是用在定义或改变表的结构，数据类型，表之间的链接和约束等初始化工作上

好处

如果主库出现问题,可以快速切换到从库提供服务。

可以在从库上执行查询操作, 降低主库的访问压力。

某些数据库维护工作，比如备份，可以在从库上执行，以避免备份期间影响主库的服务。

原理概述

( 1 )首先, MySQL主库在事务提交时会把数据变更作为事件Events记录在二进制日志文件Binlog中; MySQL主库上的sync_binlog参数控制Binlog日志刷新到磁盘。

( 2 )主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log,之后从库根据中继日志Relay Log重做数据变更操作,通过逻辑复制以此来达到主库和从库的数据一致。

MySQL通过3个线程来完成主从库间的数据复制:其中Binlog Dump线程跑在主库上, I/0线程和SQL线程跑在从库上。当在从库上启动复制时,首先创建I/0程连接主库,主库随后创建Binlog Dump线程读取数据库事件并发送给I/0线程, I0线程获取到事件数据后更新到从库的中继日志Relay Log中去,之后从库上的SQL线程读取中继日志RelayLog中更新的数据库事件并应用。

可以通过 SHOW PROCESSLIST命令在主库上査看BinlogDump线程,从BinlogDump线程的状态可以看到, Mysql的复制是主库主动推送日志到从库去的,是属于“推”日志的方式来做同步。同样地,在从库上通过SHOW PROCESSLIST可以看到l/O线程和SQL线程, l/O线程等待主库上的Binlog Dump线程.发送事件并更新到中继日志RelayLog, SQL线程读取中继日志并应用变更到数据库。

复制中的各类文件解析

日志文件

复制过程中涉及了两类非常重要的日志文件: 二进制日志文件( Binlog)和中继日志文件( Relay Log)。二进制日志文件( Binlog)会把MysQL中的所有数据修改操作以二进制的形式记录到日志文件中,包括Create、Drop、Insert、Update、Delete操作等,但二进制日志文件(Binlog)不会记录Select操作,因为Select操作并不修改数据。

可以通过 show variables査看 Binlog的格式, Binlog支持Statement、Row、Mixed三种格式,也对应了MysQL的3种复制技术。

中继日志文件 Relay Log的文件格式、内容和二进制日志文件Binlog一样,唯一的区别在于从库上的SQL线程在执行完当前中继日志文件Relay Log中的事件之后, SQL线程会自动删除当前中继日志文件Relay Log，避免从库上的中继日志文件Relay Log占用过多的磁盘空间。为了保证从库Crash重启之后,从库的I/0线程和SQL线程仍然能够知道从哪里开始复制,从库上默认还会创建两个日志文件master.info和relay_log.info用来保存复制的进度。这两个文件在磁盘上以文件形式分别记录了从库的l/0线程当前读取主库二进制日志Binlog的进度和SQL线程应用中继日志RelayLog的进度。

可以通过 show slave status命令能够看到当前从库复制的状态。

主要参数：

Master Host: 主库的IP.

Master User 主库上,主从复制使用的用户账号,

Master Port:主库MySQL的端口号,

Master_Log_File:从库的I/0线程当前正在读取的主库Binlog的文件。

Read_Master Log_Pos:从库I/0线程当前读取到的位置。

Relay_Log_File: 从库SQL线程正在读取和应用的中继日志Relay Log的文件名。

Relay_Log_Pos: 从库SQL线程当前读取并应用的中继日志Relay Log的位置。

Relay_Master_Log_File:从库SQL线程正在读取和应用的Relay Log对应于主库Binlog的文件名。

Exec_Master_Log_Pos:中继日志RelayLog中Relay_Log_Pos位置对应于主库Binlog的位置。

三种复制技术

二进制日志文件 Binlog有三种格式：

Statement:基于SQL语句级别的Binlog,每条修改数据的SQL都会保存到Binlog里。

Row:基于行级别,记录每一行数据的变化,也就是将每行数据的变化都记录到Binlog里面,记录得非常详细,但是并不记录原始SQL;在复制的时候,并不会因为存储过程或触发器造成主从库数据不一致的问通,但是记录的日志量较Statement格式要大得多。

Mixed:混合Statement和Row模式,默认情况下采用Statement模式记录,某些情况下会切换到Row模式

同时也对应了 MysQL复制的3种技术。

在 binlog_format设置为Row格式时, MySQL实际上在Binlog中逐行记录数据的变更, Row格式比Statement格式更能保证从库数据的一致性(复制的是记录,而不是单纯操作SQL)。当然, Row格式下的Binlog的日志量很可能会增大非常多,在设置时需要考虑到磁盘空间间题。

参数 binlog_format可以在全局设置或者在当前session动态设置:在全局设置会影响所有session,而在当前session设置则仅仅影响当前Session。可以通过SET命令来实时修改二进日志文件(Binlog)的格式。

相关参数可以查看主库：

命令 show master status;

举例说明如下:

CHANGE MASTER TO MASTER_HOST='192.168.56.103',MASTER_PORT=3306,MASTER_USER='rep1',MASTER_PASSWORD='1234test' ,MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=428;

8、在从库上,启动slave线程:

start slave;

9、这时slave上执行show processlist命令将显示类似如下的进程:

执行show slave status;将显示：

11、在master上执行show processlist命令将显示类似如下的进程:

12、测试一下：

在主库上新建数据库和表，并插入数据，看看从库中是否会自动创建相关的数据库和表、插入数据。

新建数据库和表之前：

主库中创建数据库orders和表order_exp，并插入数据

检查从库

半同步复制

在 MySQL5.5之前, MySQL的复制是异步操作,主库和从库的数据之间存在一定的延迟,这样存在一个隐患:当在主库上写人一个事务并提交成功,而从库尚未得到主库推送的Binlog日志时,主库宕机了,例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失,此时从库就可能损失这个事务,从而造成主从不一致。

而半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后，才返回Commit操作成功给客户端；如此半同步就保证了事务成功提交后至少有两份日志记录，一份在主库Binlog上，另一份在从库的Relay Log上，从而进一步保证数据完整性；半同步复制很大程度取决于主从网络RTT(往返时延)，以插件semisync_master/semisync_slave形式存在。

安装比较简单,在上一小节异步复制的环境上,安装半同步复制插件即可。

(1)首先,判断MySQL服务器是否支持动态增加插件:

mysql> select @@have_dynamic_loading;