MySQL 主从复制

最新推荐文章于 2022-04-12 16:21:02 发布

村东头的二毛

最新推荐文章于 2022-04-12 16:21:02 发布

阅读量214

点赞数 1

分类专栏： Linux

本文链接：https://blog.csdn.net/wanTN/article/details/90296516

版权

Linux 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

一丶MySQL 主从复制概念
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

二丶MySQL 主从复制主要用途`
读写分类
在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。

三丶MySQL 主从形式

一主一从

一主多从，提高系统的读性能
wantn

一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现HA（HA是High Available缩写，是双机集群系统简称，指高可用性集群，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点。），而且还能读写分离，进而提升集群的并发能力。

多主一从（从5.7开始支持）

多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。

双主复制

双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。

级联复制

级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

MySQL 主从复制原理

MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点，如下图所示:
wantn

复制的基本过程如下：

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

三丶MySQL 主从复制模式
MySQL 主从复制默认是异步的模式。MySQL增删改操作会全部记录在binary log中，当slave节点连接master时，会主动从master处获取最新的bin log文件。并把bin log中的sql relay。

1丶异步模式（mysql async-mode）

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

2丶半同步模式(mysql semi-sync)

这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit（指访问并可能更新数据库中各种数据项的一个程序执行单元）；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。如下图所示：

半同步模式不是mysql内置的，从mysql 5.5开始集成，需要master 和slave 安装插件开启半同步模式。

3丶全同步模式

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

MySQL半同步复制
下面为半同步复制原理图：
wantn

半同步复制的潜在问题
客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种

事务还没发送到从库上
此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。

事务已经发送到从库上
此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。

下面我们来介绍半同步复制的安装和部署：
半同步复制的安装部署

要想使用半同步复制，必须满足以下几个条件：

1）MySQL 5.5及以上版本
2）变量have_dynamic_loading为YES
3）异步复制已经存在

首先加载插件

因用户需执行INSTALL PLUGIN, SET GLOBAL, STOP SLAVE和START SLAVE操作，所以用户需有SUPER权限。

主：

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;

从：

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;

查看插件是否加载成功

有两种方式

mysql> show plugins;
wantn

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM
INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE
’ %semi%’;
wantn

启动半同步复制

在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开启半同步

主：

mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;

从：

mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;

以上的启动方式是在命令行操作，也可写在配置文件中。

主：
wantn

从：
wantn
在有的高可用架构下，master和slave需同时启动，以便在切换后能继续使用半同步复制
在这里插入图片描述

重启从上的IO线程

mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色。

这时候，主的error.log中会打印如下信息：

查看半同步是否在运行

主：

mysql> show status like ‘Rpl_semi_sync_master_status’;

±----------------------------±------+
| Variable_name | Value |
±----------------------------±------+
| Rpl_semi_sync_master_status | ON |
±----------------------------±------+
1 row in set (0.00 sec)
从：

mysql> show status like ‘Rpl_semi_sync_slave_status’;

±---------------------------±------+
| Variable_name | Value |
±---------------------------±------+
| Rpl_semi_sync_slave_status | ON |
±---------------------------±------+
1 row in set (0.20 sec)
这两个变量常用来监控主从是否运行在半同步复制模式下。

至此，MySQL半同步复制搭建完毕~

四丶binlog记录格式
MySQL 主从复制有三种方式：***基于SQL语句的复制（statement-based replication，SBR），基于行的复制（row-based replication，RBR)，混合模式复制（mixed-based replication,MBR)***。对应的binlog文件的格式也有三种：STATEMENT,ROW,MIXED。

***l Statement-base Replication (SBR)***就是记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。优点是只需要记录会修改数据的sql语句到binlog中，减少了binlog日质量，节约I/O，提高性能。缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）。

***l Row-based Relication(RBR)***是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin log同步时间。也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更。

***l Mixed-format Replication(MBR)***，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到binlog，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式。

五丶总结
Mysql 主从复制是mysql 高可用，高性能的基础，有了这个基础，mysql 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整。