深度探索MySQL主从复制原理

深度探索MySQL主从复制原理

一 、概要

MySQL Replication (MySQL 主从复制) 是什么?mysql

为何要主从复制以及它的实现原理是什么?sql

1.1 MySQL 主从复制概念

MySQL 主从复制是指数据能够从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式,这样从节点不用一直访问主服务器来更新本身的数据,数据的更新能够在远程链接上进行,从节点能够复制主数据库中的全部数据库或者特定的数据库,或者特定的表。数据库

1.2 MySQL 主从复制主要用途

  1. 读写分离

在开发工做中,有时候会碰见某个sql 语句须要锁表,致使暂时不能使用读的服务,这样就会影响现有业务,使用主从复制,让主库负责写,从库负责读,这样,即便主库出现了锁表的情景,经过读从库也能够保证业务的正常运做。安全

  1. 数据实时备份,当系统中某个节点发生故障时,能够方便的故障切换
  2. 高可用HA
  3. 架构扩展

随着系统中业务访问量的增大,若是是单机部署数据库,就会致使I/O访问频率太高。有了主从复制,增长多个数据存储节点,将负载分布在多个从节点上,下降单机磁盘I/O访问的频率,提升单个机器的I/O性能。服务器

二 、MySQL 主从形式一主一从

2.1 一主多从,提升系统的读性能

undefined

一主一从和一主多从是最多见的主从架构,实施起来简单而且有效,不只能够实现HA,并且还能读写分离,进而提高集群的并发能力。多线程

2.2 多主一从(从5.7开始支持)

undefined

多主一从能够将多个MySQL数据库备份到一台存储性能比较好的服务器上。架构

2.3 双主复制

双主复制,也就是互作主从复制,每一个master既是master,又是另一台服务器的slave。这样任何一方所作的变动,都会经过复制应用到另一方的数据库中。并发

2.4 级联复制

undefined

级联复制模式下,部分slave的数据同步不链接主节点,而是链接从节点。由于若是主节点有太多的从节点,就会损耗一部分性能用于replication,那么咱们可让3~5个从节点链接主节点,其它从节点做为二级或者三级与从节点链接,这样不只能够缓解主节点的压力,而且对数据一致性没有负面影响。异步

三 、MySQL 主从复制原理

MySQL主从复制涉及到三个线程,一个运行在主节点(log dump thread),其他两个(I/O thread, SQL thread)运行在从节点,以下图所示:async

undefined

3.1 主节点 binary log dump 线程

当从节点链接主节点时,主节点会建立一个log dump 线程,用于发送bin-log的内容。在读取bin-log中的操做时,此线程会对主节点上的bin-log加锁,当读取完成,甚至在发动给从节点以前,锁会被释放。

3.1.1 从节点I/O线程

当从节点上执行start slave命令以后,从节点会建立一个I/O线程用来链接主节点,请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新以后,保存在本地relay-log中。

3.1.2 从节点SQL线程

SQL线程负责读取relay log中的内容,解析成具体的操做并执行,最终保证主从数据的一致性。

对于每个主从链接,都须要三个进程来完成。当主节点有多个从节点时,主节点会为每个当前链接的从节点建一个binary log dump 进程,而每一个从节点都有本身的I/O进程,SQL进程。从节点用两个线程将从主库拉取更新和执行分红独立的任务,这样在执行同步数据任务的时候,不会下降读操做的性能。好比,若是从节点没有运行,此时I/O进程能够很快从主节点获取更新,尽管SQL进程尚未执行。若是在SQL进程执行以前从节点服务中止,至少I/O进程已经从主节点拉取到了最新的变动而且保存在本地relay日志中,当服务再次起来以后,就能够完成数据的同步。

要实施复制,首先必须打开Master 端的binary log(bin-log)功能,不然没法实现。

由于整个复制过程实际上就是Slave 从Master 端获取该日志而后再在本身身上彻底顺序的执行日志中所记录的各类操做。以下图所示:

undefined

3.3.3 复制的基本过程

  1. 从节点上的I/O 进程链接主节点,并请求从指定日志文件的指定位置(或者从最开始的日志)以后的日志内容;
  2. 主节点接收到来自从节点的I/O请求后,经过负责复制的I/O进程根据请求信息读取指定日志指定位置以后的日志信息,返回给从节点。返回信息中除了日志所包含的信息以外,还包括本次返回的信息的bin-log file 的以及bin-log position;
  3. 从节点的I/O进程接收到内容后,将接收到的日志内容更新到本机的relay log中,并将读取到的binary log文件名和位置保存到master-info 文件中,以便在下一次读取的时候可以清楚的告诉Master“我须要从某个bin-log 的哪一个位置开始日后的日志内容,请发给我”;
  4. Slave 的 SQL线程检测到relay-log 中新增长了内容后,会将relay-log的内容解析成在祝节点上实际执行过的操做,并在本数据库中执行。

3.2 MySQL 主从复制模式

MySQL 主从复制默认是异步的模式。MySQL增删改操做会所有记录在binary log中,当slave节点链接master时,会主动从master处获取最新的bin log文件。并把bin log中的sql relay。

3.2.1 异步模式(mysql async-mode)

异步模式以下图所示,这种模式下,主节点不会主动push bin log到从节点,这样有可能致使failover的状况下,也许从节点没有即时地将最新的bin log同步到本地。

undefined

3.2.2 半同步模式(mysql semi-sync)

这种模式下主节点只须要接收到其中一台从节点的返回信息,就会commit;不然须要等待直到超时时间而后切换成异步模式再提交;这样作的目的可使主从数据库的数据延迟缩小,能够提升数据安全性,确保了事务提交后,binlog至少传输到了一个从节点上,不能保证从节点将此事务更新到db中。性能上会有必定的下降,响应时间会变长。以下图所示:

undefined

半同步模式不是MySQL内置的,从MySQL5.5开始集成,须要master 和slave 安装插件开启半同步模式。

3.3.3 全同步模式

全同步模式是指主节点和从节点所有执行了commit并确认才会向客户端返回成功。

3.3.4 binlog记录格式

MySQL 主从复制有三种方式:基于SQL语句的复制(statement-based replication,SBR),基于行的复制(row-based replication,RBR),混合模式复制(mixed-based replication,MBR)。对应的binlog文件的格式也有三种:STATEMENT,ROW,MIXED。

  1. Statement-base Replication (SBR)就是记录sql语句在bin log中,MySQL5.1.4 及以前的版本都是使用的这种复制格式。优势是只须要记录会修改数据的sql语句到binlog中,减小了binlog日质量,节约I/O,提升性能。缺点是在某些状况下,会致使主从节点中数据不一致(好比sleep(),now()等)。
  2. Row-based Relication(RBR)是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中,也就是只记录哪条数据被修改了,修改为什么样。优势是不会出现某些特定状况下的存储过程、或者函数、或者trigger的调用或者触发没法被正确复制的问题。缺点是会产生大量的日志,尤为是修改table的时候会让日志暴增,同时增长bin log同步时间。也不能经过bin log解析获取执行过的sql语句,只能看到发生的data变动。
  3. Mixed-format Replication(MBR),MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合,对于通常的复制使用STATEMENT模式保存到binlog,对于STATEMENT模式没法复制的操做则使用ROW模式来保存,MySQL会根据执行的SQL语句选择日志保存方式。

3.3.5 GTID复制模式

  1. 在传统的复制里面,当发生故障,须要主从切换,须要找到binlog和pos点,而后将主节点指向新的主节点,相对来讲比较麻烦,也容易出错。在MySQL 5.6里面,不用再找binlog和pos点,咱们只须要知道主节点的ip,端口,以及帐号密码就行,由于复制是自动的,MySQL会经过内部机制GTID自动找点同步。
  2. 多线程复制(基于库),在MySQL 5.6之前的版本,slave的复制是单线程的。一个事件一个事件的读取应用。而master是并发写入的,因此延时是避免不了的。惟一有效的方法是把多个库放在多台slave,这样又有点浪费服务器。在MySQL 5.6里面,咱们能够把多个表放在多个库,这样就可使用多线程复制。

3.3.6 基于GTID复制实现的工做原理

  1. 主节点更新数据时,会在事务前产生GTID,一块儿记录到binlog日志中。
  2. 从节点的I/O线程将变动的bin log,写入到本地的relay log中。
  3. SQL线程从relay log中获取GTID,而后对比本地binlog是否有记录(因此MySQL从节点必需要开启binary log)。
  4. 若是有记录,说明该GTID的事务已经执行,从节点会忽略。若是没有记录,从节点就会从relay log中执行该GTID的事务,并记录到bin log。
  5. 在解析过程当中会判断是否有主键,若是没有就用二级索引,若是有就用所有扫描。

四 、总结

MySQL主从复制是MySQL高可用,高性能的基础,有了这个基础,MySQL的部署会变得简单、灵活而且具备多样性,从而能够根据不一样的业务场景作出灵活的调整。

相关文章
相关标签/搜索