MySQL主从同步

01.MySQL同步

1、原理

  • MySQL的主从复制是通过主服务器将其更改记录到二进制日志(Binary log)中
  • 然后从服务器将这些日志应用到自己的数据之中,从而实现数据的一致性
  • 1、master服务器将数据的改变都记录到二进制binlog日志中,只要master上的数据发生改变,则将其改变写入二进制日志

  • 2、salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/O Thread请求master二进制事件

  • 3、同时主节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保存至从节点本地的中继日志中

  • 4、从节点将启动SQL线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致

  • 5、最后I/O Thread和SQL Thread将进入睡眠状态,等待下一次被唤醒。

  • 需要理解:

    • 1)从库会生成两个线程,一个I/O线程,一个SQL线程;
    • 2)I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;
    • 3)主库会生成一个log dump线程,用来给从库I/O线程传binlog;
    • 4)SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

2、MySQL复制流程图

  • 1、master将操作语句记录到binlog日志中

  • 2、salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变,如果发生改变

  • 3、salave开启两个线程:IO线程和SQL线程

    • 1)IO线程:负责读取master的binlog内容到中继日志relay log里;
    • 2)SQL线程:负责从relay log日志里读出binlog内容,并更新到slave的数据库里(保证数据一致)

3、MySQL同步延迟

  • 1、造成MySQL同步延迟常见原因

    • 1)网络:如主机或者从机的带宽打满、主从之间网络延迟很大,导致主上的binlog没有全量传输到从机,造成延迟。
    • 2)机器性能:从机使用了烂机器?比如主机使用SSD而从机还是使用的SATA。
    • 3)从机高负载:有很多业务会在从机上做统计,把从机服务器搞成高负载,从而造成从机延迟很大的情况
    • 4)大事务:比如在RBR模式下,执行带有大量的delete操作,这种通过查看processlist相关信息以及使用MySQLbinlog查看binlog中的SQL就能快速进行确认
    • 5)锁: 锁冲突问题也可能导致从机的SQL线程执行慢,比如从机上有一些select .... for update的SQL,或者使用了MyISAM引擎等。
  • 2、硬件方面(优化)

    • 1.采用好服务器,比如4u比2u性能明显好,2u比1u性能明显好。
    • 2.存储用ssd或者盘阵或者san,提升随机写的性能。
    • 3.主从间保证处在同一个交换机下面,并且是万兆环境。
    • 总结:硬件强劲,延迟自然会变小。一句话,缩小延迟的解决方案就是花钱和花时间。

02.MySQL复制种类

1、异步复制

  • 一个主库,一个或多个从库,数据异步同步到从库

  • 这种模式下,主节点不会主动推送数据到从节点

  • 主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理

  • 主节点如果崩溃掉了,此时主节点上已经提交的事务可能并没有传到从节点上

  • 如果此时,强行将从提升为主,可能导致新主节点上数据不完整

2、同步复制

  • 主库执行完一个事务,然后所有的从库都复制了该事务并成功执行完才返回成功信息给客户端

  • 因为需要等待所有从库执行完该事务才能返回成功信息,所以全同步复制的性能必然会收到严重的影响

3、半同步复制

  • 在异步复制的基础上,确保任何一个主库上的事物在提交之前至少有一个从库已经收到该事物并日志记录下来

  • 等待至少一个从库接收到并写到 relay log 中才返回成功信息给客户端(只能保证主库的 Binlog 至少传输到了一个从节点上)

  • 否则需要等待直到超时时间然后切换成异步模式再提交

  • 相对于异步复制,半同步复制提高了数据的安全性,一定程度的保证了数据能成功备份到从库

  • 同时它也造成了一定程度的延迟,但是比全同步模式延迟要低,这个延迟最少是一个 TCP/IP 往返的时间

  • 所以,半同步复制最好在低延时的网络中使用

4、延迟复制

  • 在异步复制的基础上,人为设定主库和从库的数据同步延迟时间,即保证数据延迟至少是这个参数

5、语句复制

  • 基于语句的复制相当于逻辑复制,即二进制日志中记录了操作的语句,通过这些语句在从数据库中重放来实现复制

  • 这种方式简单,二进制文件小,传输带宽占用小

  • 但是基于语句更新依赖于其它因素,比如插入数据时利用了时间戳

  • 因此在开发当中,我们应该尽量将业务逻辑逻辑放在代码层,而不应该放在 MySQL 中,不易拓展

特点

  • 传输效率高,减少延迟。
  • 在从库更新不存在的记录时,语句赋值不会失败。而行复制会导致失败,从而更早发现主从之间的不一致。
  • 设表里有一百万条数据,一条sql更新了所有表,基于语句的复制仅需要发送一条sql,而基于行的复制需要发送一百万条更新记录

6、行数据复制

  • 基于行的复制相当于物理复制,即二进制日志中记录的实际更新数据的每一行

  • 这样导致复制的压力比较大,日志占用的空间大,传输带宽占用大

  • 但是这种方式比基于语句的复制要更加精确

特点

  • 不需要执行查询计划
  • 不知道执行的到底是什么语句

7、混合类型的复制

  • 一般情况下,默认采用基于语句的复制,一旦发现基于语句无法精确复制时,就会采用基于行的复制
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不做大哥好多年xw

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值