MySql主从复制机制全面解析

作为一个关系型数据库,MySQL内建地提供数据复制机制,这使得在使用时,可以基于其复制机制实现高可用架构等高级特性,从而使得MySQL无需借助额外的插件或其他工具就具备适用于生产环境。这是MySQL得到大面积实际应用的条件之一。

基于MySQL的复制机制,不仅可以实现数据库的高可用,还能实现如:性能扩展、异地灾备以及冷热分离等高级特性。

  • 高可用:通过配置一定的复制机制,MySQL实现了跨主机的数据复制,从而获得一定的高可用能力,如果需要获得更高的可用性,只需要配置多个副本,或者进行级联复制就可以达到目的。
  • 性能扩展:由于复制机制提供了多个数据备份,在读写一致性要求不高的场景下,可以通过配置一个或多个副本,将读请求分发至副本节点,从而获得整体上读写性能的提升。
  • 异地灾备:只需要将副本节点部署到异地机房,就可以轻松获得一定的异地灾备能力。实际当中,需要考虑网络延迟等可能影响整体表现的因素。
  • 交易分离:通过配置复制机制,并将低频、大运算量的交易发送至副本节点执行,就可以避免这些交易与高频交易竞争运算资源,从而避免整体的性能问题。

为了获得上述能力,需要了解基本的MySQL复制机制,并结合实际应用场景选择恰当的配置。

主从复制机制

MySQL基于binlog实现主从复制,从节点跟踪并获取主节点binlog中最新更新并在自身进行重放,从而实现复制主节点数据。

下图是MySQL主从复制过程的示意图。在整个过程中涉及三个线程,他们的职责分别是:

  • 主节点binlog dump线程:该线程在从节点连接上主节点后创建,负责向从节点发送binlog中新写入的数据。在读取binlog时,dump线程会首先获取binlog的锁,并在读取完毕后立刻释放,然后将读取到的数据发送至从节点。
  • 从节点I/O线程:从节点I/O线程职责为向主节点发送数据同步的请求,接收主节点发送的数据并将其写入relay-log。
  • 从节点SQL线程:该线程从relay-log中读取数据更新并进行重放。

异步复制

默认情况下,MySQL的主从复制是异步复制,在这种机制下,主节点会在完成本地日志写入后立刻响应客户端的请求,从节点的数据复制过程异步执行。

很明显,在这种机制下面,由于复制过程并不会影响主节点对客户端请求的响应,因此,相比于单节点,并不会造成整体性能上的明显损失。

但是,在这种机制下面,如果数据在主节点完成提交而未同步至从节点时主节点宕机,此时如果发生主从切换并写入新的数据,可能导致数据丢失或不一致。

半同步复制(semisynchronous replication)

从5.6版本开始,MySQL支持半同步复制,这种机制与异步复制相比主要有如下区别:

主节点在收到客户端的请求后,必须在完成本节点日志写入的同时,还需要等待至少一个从节点完成数据同步的响应之后(或超时),才会响应请求。

从节点只有在写入relay-log并完成刷盘之后,才会向主节点响应。

当从节点响应超时时,主节点会将同步机制退化为异步复制。在至少一个从节点恢复,并完成数据追赶后,主节点会将同步机制恢复为半同步复制。

可以看出,相比于异步复制,半同步复制在一定程度上提高了数据的可用性,在未退化至异步复制时,如果主节点宕机,此时数据已复制至至少一台从节点。

同时,由于向客户端响应时需要从节点完成响应,相比于异步复制,此时多出了主从节点上网络交互的耗时以及从节点写文件并刷盘的耗时,因此整体上集群对于客户端的响应性能表现必然有所降低。

主从复制格式

由于MySQL的复制机制是基于binlog的,因此binlog的格式就决定了主从复制的格式。binlog有基于行的和基于语句两种,从而复制也有两种对应的格式。

Statement-Based Replication(SBR)

对于基于语句的复制机制,binlog仅记录所执行的语句。这种方式,有如下优点:

  • 自从3.23版本就存在,经过长期验证的成熟技术
  • 写入日志文件的数据更少,这意味着更少的文件写入和网络传输消耗,从而整体上可以更快的完成主从复制,提升性能表现。
  • 日志文件记录了所有数据库上执行的语句,可以用来进行审计等用途

有如下缺点:

  • 用户自定义函数(UDF)以及执行结果不确定的函数无法进行复制
  • 进行数据更新时,需要比基于行的复制更多的行锁
  • 对于如先插入后更新式的复杂语句,从节点需要进行完全的对应重放,而基于行格式的复制只需要执行最终结果即可

Row-Based Replication(RBR)

基于行的复制机制下,对应binlog也是基于行的,这时每次数据更新当写入binlog时,都被转化所有受影响行的变化。

这种复制方式,有如下优点:

  • 所有数据变化都可以被安全的复制,不会受到UDF以及特殊函数的影响。
  • 大部分DBMS都采用这种复制方式,知识迁移成本低。
  • 进行数据更新时,所需要的行锁更少,从而可以获取更高的性能表现。

有如下缺点:

  • 在涉及大数据量的DML时,基于行的日志将会产生大量的日志数据,大数据量在日志文件写入、网络传输方面都意味着更长的时间,从而可能导致整体性能表现显著变差,同时也可能导致并发问题。
  • 无法通过日志查看所执行的语句,同时也无法获知从节点上执行的语句。

在实际的架构应用中,需要根据系统的业务特点合理利用主从复制机制,并选择合适主从复制格式。

以上就是MySql主从复制机制全面解析的详细内容,更多关于MySql主从复制机制的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySql主从复制实现原理及配置

    数据库读写分离对于大型系统或者访问量很高的互联网应用来说,是必不可少的一个重要功能.对于MySQL来说,标准的读写分离是主从模式,一个写节点Master后面跟着多个读节点,读节点的数量取决于系统的压力,通常是1-3个读节点的配置.而一般的读写分离中间件,例如Mycat的读写分离和自动切换机制,需要mysql的主从复制机制配合. 主从配置需要注意的地方 1.主DB server和从DB server数据库的版本一致 2.主DB server和从DB server数据库数据名称一致 3.主DB se

  • Mysql主从复制与读写分离图文详解

    文章思维导图 为什么使用主从复制.读写分离 主从复制.读写分离一般是一起使用的.目的很简单,就是为了提高数据库的并发性能. 你想,假设是单机,读写都在一台MySQL上面完成,性能肯定不高. 如果有三台MySQL,一台mater只负责写操作,两台salve只负责读操作,性能不就能大大提高了吗? 所以主从复制.读写分离就是为了数据库能支持更大的并发. 随着业务量的扩展.如果是单机部署的MySQL,会导致I/O频率过高. 采用主从复制.读写分离可以提高数据库的可用性. 主从复制的原理 ①当Master

  • MySQL主从复制原理以及需要注意的地方

    写在前面 最近在写Mycat专题,由于不少小伙伴最近要出去面试,问我能不能简单写下MySQL的主从复制原理和注意事项,因为在之前的面试中被问到了这些问题.我:可以啊,安排上了!! 主从复制原理 (1) Master 将数据改变记录到二进制日志(binary log)中,也就是配置文件 log-bin 指定的文件, 这些记录叫做二进制日志事件(binary log events): (2) Slave 通过 I/O 线程读取 Master 中的 binary log events 并写入到它的中继

  • MySQL主从复制断开的常用修复方法

    01 问题描述 在生产环境中,我们经常会遇见MySQL主从复制断开的情况,在遇到主从复制断开是,通常情况,解决问题的步骤如下: 1.从库上show slave status查看复制断开的直观原因,并记录当前的复制位点 2.查看error log,分析更详细的复制断开原因 3.修复主从复制关系 4.如果复制关系无法修复,则需要重新搭建从库 02 解决问题的方法 主从复制关系断裂,有各种各样的原因.有些时候,我们没有时间去客观分析原因,因为应用程序处于无法使用状态,需要立即恢复,这种情况下,我们对复

  • MYSQL数据库GTID实现主从复制实现(超级方便)

    一.添加Maria源 vi /etc/yum.repos.d/MariaDB.repo 粘贴阿里云的最新mariadb镜像: [mariadb] name = MariaDB baseurl = https://mirrors.aliyun.com/mariadb/yum/10.5/centos7-amd64/ gpgkey=https://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck=1 安装新版本的MariaDB yu

  • MySQL中主从复制重复键问题修复方法

    -------------------quote begin------------------------ 3. If you decide that you can skip the next statement from the master, issue the following statements: mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n; mysql> START SLAVE; The value of n should be

  • 关于MySQL主从复制的几种复制方式总结

    异步复制 MySQL的复制默认是异步的,主从复制至少需要两个MYSQL服务,这些MySQL服务可以分布在不同的服务器上,也可以在同一台服务器上. MySQL主从异步复制是最常见的复制场景.数据的完整性依赖于主库BINLOG的不丢失,只要主库的BINLOG不丢失,那么就算主库宕机了,我们还可以通过BINLOG把丢失的部分数据通过手工同步到从库上去. 注意:主库宕机的情况下,DBA可以通过mysqlbinlog工具手工访问主库binlog,抽取缺失的日志并同步到从库上去:也可以通过配置高可用MHA架

  • 全面解读MySQL主从复制,从原理到安装配置

    为什么需要主从复制? 1.在业务复杂的系统中,有这么一个情景,有一句sql语句需要锁表,导致暂时不能使用读的服务,那么就很影响运行中的业务,使用主从复制,让主库负责写,从库负责读,这样,即使主库出现了锁表的情景,通过读从库也可以保证业务的正常运作. 2.做数据的热备 3.架构的扩展.业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的频率,提高单个机器的I/O性能. 什么是mysql的主从复制? MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节

  • mysql主从复制配置过程

    主库配置 1. 配置mysql vim /etc/my.cn # 在文件中增加以下内容 server-id=1 # 保证server id唯一 log-bin = /var/lib/mysql/mysql-bin.log binlog-do-db = db1 binlog-do-db = db2 其中db1和db2是计划进行主从复制的库,如果有多个,写多行即可.配置完毕后,重启数据库: service mysqld restart 2. 添加复制用户 通过phpmyadmin,添加新用户,并授予

  • mysql 主从复制如何跳过报错

    一.传统binlog主从复制,跳过报错方法 mysql> stop slave; mysql> set global sql_slave_skip_counter = 1; mysql> start slave; mysql> show slave status \G 二.GTID主从复制,跳过报错方法 mysql> stop slave: #先关闭slave复制: mysql> change master to ...省略... #配置主从复制: mysql>

随机推荐