欢送微信关注「SH的全栈笔记」

0. 主从复制

首先主从复制是什么？简略来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。

这种形式与Redis的主从复制的思路没有太大的出入。如果你对Redis的主从复制感兴趣能够去看看《Redis的主从复制》。那既然Redis和MySQL都采纳了复制这种形式，主从复制所带来的意义是什么呢？

通过复制性能，构建一个或者多个从库，能够进步数据库的高可用性、可扩展性，同时实现负载平衡。当主库产生故障时，能够疾速的切到其某一个从库，并将该从库晋升为主库，因为数据都一样，所以不会影响零碎的运行；当MySQL服务器须要扛住更多的读申请时，能够把读申请的流量分流到各个从库下来，写申请则转发给主库，造成读写拆散的架构，来提供更好的读扩大和申请的负载平衡。

读写拆散的架构利用的其实十分宽泛，就比方MySQL，还有Redis，以及咱们相熟的Zookeeper，Zookeeper的Follower收到读申请不会本人解决，而是会将读申请转发给Leader，感兴趣的能够本人下来理解一下，这里就不偏题了。

1. 复制原理

MySQL的主从复制反对两种形式：

  • 基于行
  • 基于语句

基于语句的复制在MySQL3.23中就曾经有了，而基于语句的形式则在5.1中才实现。其本质都是基于主库的binlog来实现的，主库记录binlog，而后从库将binlog在本人的服务器上重放，从而保障了主、从的数据一致性。

1.1 binlog

MySQL中日志分为两个维度，一个是MySQL服务器的，一个是底层存储引擎的。而上文提到的binlog就是属于MySQL服务器的日志，binlog也叫二进制日志，记录了所有对MySQL所做的更改。

基于行、语句的复制形式跟binlog的存储形式有关系。 binlog有三种存储格局，别离是Statement、Row和Mixed。

  • Statement 基于语句，只记录对数据做了批改的SQL语句，可能无效的缩小binlog的数据量，进步读取、基于binlog重放的性能
  • Row 只记录被批改的行，所以Row记录的binlog日志量一般来说会比Statement格局要多。基于Row的binlog日志十分残缺、清晰，记录了所有数据的变动，然而毛病是可能会十分多，例如一条update语句，有可能是所有的数据都有批改；再例如alter table之类的，批改了某个字段，同样的每条记录都有改变。
  • Mixed Statement和Row的联合，怎么个结合法呢。例如像update或者alter table之类的语句批改，采纳Statement格局。其余的对数据的批改例如update和delete采纳Row格局进行记录。

为什么会有这么多形式呢？因为Statement只会记录SQL语句，然而并不能保障所有状况下这些语句在从库上可能正确的被重放进去。因为可能程序不对。

MySQL什么时候会记录binlog呢？是在事务提交的时候，并不是依照语句的执行程序来记录，当记录完binlog之后，就会告诉底层的存储引擎提交事务，所以有可能因为语句程序谬误导致语句出错。

1.2 查看binlog

这里拿MySQL 5.6举例子，binlog默认是处于敞开状态的。咱们能够通过命令show variables like '%log_bin%' 来查看对于binlog的配置。

log_bin代表是否开启了binlog，其默认值为OFF。

  • log_bin 代表是否开启了binlog，其默认值为OFF
  • log_bin_basename binlog存储文件的残缺名称，会在默认的文件名前面增加上递增的序号，就例如mysql-bin.000001
  • log_bin_index binlog索引文件名称，例如mysql-bin.index
  • sql_log_bin 在binlog开启的时候，能够禁用以后session的binlog

你能够在MySQL中通过命令show binary logs查看所有的binlog文件

晓得了有哪些文件之后咱们能够来看看binlog文件中的内容，能够在MySQL通过show binlog events命令来查看。

show binglog events 查看第一个binlog文件，咱们也能够通过in参数来指定，假如咱们想看的文件名是mysql-bin.000001，那么能够应用命令show binlog events in 'mysql-bin.000001'来查看指定的binlog文件

接下来咱们来看看咱们在MySQL中的操作所对应的binlog内容别离是什么。

初始化

咱们下面提到过，binlog是由一个一个的event组成的。从MySQL 5.0开始，binlog的第一个event都为Format_desc，位于图中的Event_type那一列。能够看到内容为Server ver;5.6.50-log, Binlog ver: 4，阐明以后应用的MySQL版本为5.6.50，Binlog的版本是V4。

创立数据库

而后我创立了一个名为student的DB，其Event_type是Query，这个event的内容为CREATE DATABASE student DEFAULT CHARACTER SET = utf8mb4，一个建库语句。

新建表

而后我创立了一个名为student的表，Event_type也是Query，内容为use student; CREATE TABLE student (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT)，一个建表语句。

插入数据

而后咱们执行INSERT语句给该表插入两行数据，再次查看binlog。

INSERT INTO `student` (`id`, `name`) VALUES (NULL, '张三');INSERT INTO `student` (`id`, `name`) VALUES (NULL, '李四');

能够看到每次INSERT都会开启一个事务，你可能会纳闷，咱们只是简略的执行了INSERT语句，没有显示的开启事务。那为什么会有事务产生呢？

这是因为MySQL采纳了主动提交（AUTOCOMMIT）的机制，我应用的InnoDB存储引擎，是反对事务的，所有的用户流动都产生在事务中。咱们能够通过show variables like '%AUTOCOMMIT%';命令查看，如果后果是ON则代表是开启的。

1.3 复制的外围步骤

咱们假如主库曾经开启了binlog，并失常的记录binlog。

首先从库启动I/O线程，跟主库建设客户端连贯。

主库启动binlog dump线程，读取主库上的binlog event发送给从库的I/O线程，I/O线程获取到binlog event之后将其写入到本人的Relay Log中。

而后从库启动SQL线程，将Relay中的数据进行重放，实现从库的数据更新。

总结来说，主库上只会有一个线程，而从库上则会有两个线程。

1.4 Relay Log

relay log其实和binlog没有太大的区别，在MySQL 4.0 之前是没有Relay Log这部分的，整个过程中只有两个线程。然而这样也带来一个问题，那就是复制的过程须要同步的进行，很容易被影响，而且效率不高。例如主库必须要期待从库读取完了能力发送下一个binlog事件。这就有点相似于一个阻塞的信道和非阻塞的信道。

阻塞信道就跟你在柜台一样，你要递归柜员一个货色，然而你和柜员之间没有能够放货色的中央，你就只能始终把文件拿着，直到柜员接手；而非阻塞信道就像你们之间有个中央能够放文件，你就间接放上去就好了，不必等柜员接手。

引入了Relay Log之后，让本来同步的获取事件、重放事件解耦了，两个步骤能够异步的进行，Relay Log充当了缓冲区的作用。Relay Log有一个relay-log.info的文件，用于记录以后复制的进度，下一个事件从什么Pos开始写入，该文件由SQL线程负责更新。

1.5 Relay Log外围参数

接下来让咱们理解一下Relay Log的外围参数。

  • max_relay_log_size 中继日志的最大size，默认值0，如果为0就会取默认的size 1G，否则就为设置的值
  • relay_log 定义relay的名称，默认为主机名+relay-bin，例如像hostname-relay-bin
  • relay_log_basename 中继日志的全门路，即门路 + 文件名，例如/path/to/hostname-relay-bin，最大长度为256
  • relay_log_index 定义中继日志的索引文件的全门路，同样其最大的长度为256. 其默认值为hostname + relay-bin.index，例如/path/to/hostname-relay-bin.index
  • relay_log_info_file 定义relay-log.info文件的名称
  • relay_log_info_repository 寄存relay log重放的数据的形式，能够设置为FILE和TABLE。FILE代表将中继日志重放的数据记录在relay-info.log中，TABLE则将其寄存在slave_relay_log_info这张表里。
  • relay_log_purge 是否主动清空不须要的中继日志，默认值为ON
  • relay_log_recovery 当从库宕机后，如果relay log损坏了导致局部的中继日志没有进行同步，则主动放弃所有未进行重放的中继日志，并从主库从新获取，默认值为OFF
  • relay_log_space_limit 设置中继日志的最大值，避免写满磁盘。然而不倡议设置这个值，倡议还是给中继日志须要的空间，0就是不限度，0也是默认值
  • sync_relay_log 用于管制中继日志写入磁盘的变量，假如值为n，那么在中继日志每承受n次binlog事件之后就会调用fdatasync()函数将中继日志强制的刷入磁盘；相同，如果值为0，则写入OS的缓冲区内，由OS调度决定何时将中继日志刷入磁盘，这样一来如果在没有刷入之前报错了，那么中继日志就会失落。默认值是10000，也就是每向中继日志中写入1w次binlog事件就将中继日志强制的刷入磁盘。

  • sync_relay_log_info 该参数的影响跟参数relay_log_info_repository有肯定关系，同时也跟是否应用反对事务的存储引擎有关系。该值默认也是10000.

    • 当sync_relay_log_info为0时

      • relay_log_info_repository为FILE，MySQL不会调用fdatasync()，而是将刷入磁盘的调度交给OS；
      • relay_log_info_repository为TABLE，如果应用了反对事务的存储引擎，则每次事务的时候该表都会被更新；如果没有应用事务引擎，则永远不会被更新

    • 当sync_relay_log_info大于0时

      • relay_log_info_repository为FILE，假如设置的值为N，那么每N次事务都会都会调用fdatasync()强制将relay-log.info刷入磁盘
      • relay_log_info_repository为TABLE，如果应用了反对事务的引擎，则该表每次事务完结都会被更新；如果没有应用事务引擎则会在写入N个binlog事件的时候更新该表。

2. 复制模型

平时的开发中，其实很少说一上来就间接搞主从架构的。费时间、费钱还引入了额定的复杂度，最初发现投入了这么多一个单MySQL服务器就齐全能handle。

这就跟一个产品的架构迭代是一样的，刚刚起步的时候一个单体利用足够了。当你的业务扩大，申请收缩，单体无奈抗住压力了，就会思考开始部署多实例，开始采纳微服务架构去做横向扩大、负载平衡。

2.1 一主多从

当然你也能够把它当成一主一从。

这是最简略的模型，特地适宜大量写、大量读的状况。读申请被分到了各个从库上，无效的帮主库扩散了压力，可能晋升读并发。当然，你也能够只是把从库当成一个灾备库，除了主从复制之外，没有其余任何的申请和数据传输。

甚至你能够把其中一个备库作为你的预发环境的数据库，当然，这说到底还是间接动了生产环境的数据库，是一种过于现实的用处，因为这还波及到生产环境数据库的数据敏感性。不是所有人都可能接触到的，须要有欠缺的权限机制。

值得注意的是，如果有n个从库，那么主库上就会有n个binlog dump线程。如果这个n比拟大的话在复制的时候可能会造成主库的性能抖动。所以在从库较多的状况下能够采纳级联复制。

2.2 级联复制

级联复制用大白话说就是套娃。

原本从库B、C、D、E、F、G都是复制的主库A，然而当初因为A的压力比拟大，就不这么干了，调整成了如下的模式。

  • B、C复制A
  • D、E复制B
  • F、G复制C

这就叫级联复制，开启疯狂套娃模式。你甚至会感觉这种套娃很眼生，在Redis主从复制中也能够采纳级联模式， slave去复制另一个slave。

级联复制的益处在于很大水平上加重了主库的压力，主库只须要关怀与其有间接复制关系的从库，剩下的复制则交给从库即可。相同，因为是这种层层嵌套的关系，如果在较下层呈现了谬误，会影响到挂在该服务器下的所有子库，这些谬误的影响成果被放大了。

2.3 主主复制

顾名思义，就是两个主库互相复制，客户端能够对任意一台主库进行写操作。任何一台主库服务器上的数据产生了变动都会同步到另一台服务器下来。有点相似于Eureka Server的双节点模式，两个注册核心互相注册。这样一来，任何一台挂了都不会对系统产生影响。

而且主主复制能够突破数据库性能瓶颈，一个很酷的性能——横向扩大。为什么说很酷呢，如果DB能做到横向扩大，那很多被数据库并发所限度的瓶颈都能够被冲破，然而...

然而主主复制其实并不牢靠，两边的数据抵触的可能性很大。例如复制进行了，零碎依然在向两个主库中写入数据，也就是说一部分数据在A，另一部分的数据在B，然而没有互相复制，且数据也不同步了。要修复这部分数据的难度就会变得相当大。

所以我认为双主的更多的意义在于HA，而不是负载平衡。

2.4 主、被动的主主复制

同样还是双主的构造，然而区别在于其中一台是只读的被动服务器，客户端不会向该库进行写操作。

其用处在哪里呢？例如咱们要在不中断服务的前提下对MySQL进行保护、优化，举个例子——批改表构造。假如咱们有两个数据库，主库A和被动主库B，留神此处的被动主库是只读的，咱们先进行A对B的复制，也就是停掉A上的SQL线程。

这样一来，咱们之后在B上执行的十分耗时、可能须要锁表的操作就不会立刻同步到A上来。因为此时A正在对外提供服务，所以不能使其收到影响，然而因为采纳的是异步的复制模式，所以Relay Log还是持续由I/O线程写入，只是不去进行重放。

而后咱们在B上执行此次的保护操作，留神，此时A下面产生的更新还是会失常的同步到B来。执行完后替换读写的角色。也就是让A变成只读的被动主库，而B变为被动主库对外提供服务。

而后从新开启SQL线程，A开始去对之前Relay Log中积攒的event进行重放。尽管A此时可能会阻塞住，然而A曾经没有对外提供服务了，所以没有问题。

主、被动下的主主模式的益处大家也就分明了，能够在不进行服务的状况上来做数据库的构造更新，其次能够在主库产生故障的状况下，疾速的切换，保障数据库的HA。

3. 复制形式

上文咱们不止一次的提到了复制是异步的，接下来咱们来理解一下MySQL的主从复制都有哪些形式。

3.1 异步复制

首先就是异步，这也是MySQL默认的形式。在异步复制下，主库不会被动的向从库发送音讯，而是期待从库的I/O线程建设连贯，而后主库创立binlog dump线程，把binlog event发送给I/O线程，流程如下图。

主库在执行完本人的事务、记录完binlog之后就会间接返回，不会与客户端确认任何后果。而后后续由binlog dump线程异步的读取binlog，而后发送给从库。解决申请和主从复制是两个齐全异步化的过程。

3.2 同步复制

同步模式则是，主库执行一个事务，那么主库必须期待所有的从库全副执行完事务返回commit之后能力给客户端返回胜利，

值得注意的是，主库会间接提交事务，而不是期待所有从库返回之后再提交。MySQL只是提早了对客户端的返回，并没有延后事务的提交。

同步模式用脚趾头想晓得性能会大打折扣，它把客户端的申请和主从复制耦合在了一起，如果有某个从库复制线程执行的慢，那么对客户端的响应也会慢很多。

3.3 半同步复制

半同步绝对于同步的区别在于，同步须要期待所有的从库commit，而半同步只须要一个从库commit就能够返回了。如果超过默认的工夫依然没有从库commit，就会切换为异步模式再提交。客户端也不会始终去期待了。

因为即便前面主库宕机了，也能至多保障有一个从库节点是能够用的，此外还缩小了同步时的等待时间。

4. 复制中的数据一致性

咱们在1.3中探讨了复制的外围步骤，看似很简略的一个流程，主库的binlog dump去读取binlog，而后从库的I/O线程去读取、写入Relay Log，进而从库的SQL线程再读取Relay Log进行重放。

那如果I/O线程复制到一半本人忽然挂掉了呢？又或者复制到一半主库宕机了呢？如果和保证数据一致性的呢？

咱们下面提到过，有一个relay-log.info的文件，用于记录以后从库正在复制的binlog和写入的Relay Log的Pos，只有这个文件还在，那么当从库意外重启之后，就会从新读取文件，从上次复制的中央开始持续复制。这就跟Redis中的主从复制相似，单方要保护一个offset，通过比照offset，来进行psync增量数据同步。

然而在MySQL 5.5以及之前，都只能将复制的进度记录在relog-log.info文件中。换句话说，参数relay_log_info_repository只反对FILE，能够再回到下面的1.5 Relay Log外围参数看一下。所以只有在sync_relay_log_info次事务之后才会把relay-log.info文件刷入磁盘。

如果在刷入磁盘之前从库挂了，那么重启之后就会发现SQL线程理论执行到地位和数据库记录的不统一，数据一致性的问题就这么产生了。

所以在MySQL 5.6时，参数relay_log_info_repository反对了TABLE，这样一来咱们就能够将复制的进度放在零碎的mysql.slave_relay_log_info表里去，并且把更新进度、SQL线程执行用户事务绑定成一个事务执行。即便slave宕机了，咱们也能够通过MySQL内建的解体复原机制来使理论执行的地位和数据库保留的进度复原到统一。

其次还有下面提到的半同步复制，主库会先提交事务，而后期待从库的返回，再将后果返回给客户端，然而如果在主库期待的时候，从库挂了呢？

此时主库上因为事务曾经提交了，然而从库上却没有这个数据。所以在MySQL 5.7时引入了无损半同步复制，减少了参数rpl_semi_sync_master_wait_point的值，在MySQL 5.7中值默认为after_sync，在MySQL 5.6中默认值为after_commit。

  • after_sync 主库先不提交事务，期待某一个从库返回了后果之后，再提交事务。这样一来，如果从库在没有任何返回的状况下宕机了，master这边也无奈提交事务。主从依然是统一的
  • after_commit 与之前探讨的一样，主库先提交事务，期待从库返回后果再告诉客户端
好了以上就是本篇博客的全部内容了，如果你感觉这篇文章对你有帮忙，还麻烦点个赞，关个注，分个享，留个言。

欢送微信搜寻关注【SH的全栈笔记】，查看更多相干文章