您现在的位置是:首页 > 正文

MySQL的主备同步原理及过程

2024-02-01 03:31:44阅读 2

1. MySQL是如何保证主备一致的:

一句话概括:

通过binlog完成主备同步,实现最终一致性,binlog有三种格式:statement、row、mixed。
涉及到的线程有主库上的dump_thread、备库上的io_thread、sql_thread;
涉及到的日志有binlog、relaylog。

1.1 MySQL基本的主备切换流程:

如下图所示就是基本的主备切换流程。主库A负责处理客户端的读写操作,备库B只需要将A的更新都同步过来,到本地执行即可。这样可以保持节点B和A的数据是相同的。

当需要切换时,就切成状态2,此时客户端读写访问的都是备库B,而主库A成为节点B的备库。

注:
备库一般都设置为readonly状态,可以防止误操作及切换过程中出现双写造成主备不一致。还可以通过readonly状态来判断节点的角色。readonly不会影响主备同步,因为readonly对超级用户(root权限)是无效的,用于同步更新的线程就属于root权限。
MySQL主备切换流程
图1:MySQL主备切换流程

下图所示为节点A到节点B的主备切换流程图:

MySQL主备流程图
图2:MySQL主备流程图

从图中可见,主库A上有三个线程:处理客户端读写请求的线程、bg_thread后台线程用于进行持久化、dump_thread用于传递binlog给备库;
备库B上有两个线程:io_thread用于处理与主库之间的网络连接和IO操作、sql_thread用于读取中转日志,解析出日志中的命令并执行。

一个事务日志同步的完整过程是这样的:

(1)在备库B上通过 change master 命令,设置主库A的IP、端口号、用户名、密码,以及要从哪个位置开始请求binlog,这个位置包含的文件名和日志偏移量offset;(此时只是设立建立连接需要的信息,包括IP、port等,还未真正发起连接,连接的建立需要后面的io_thread线程来处理)
(2)在备库B上执行 start slave 命令,此时备库B会启动两个线程,即:io_threadsql_thread。 其中 io_thread 负责与主库建立网络连接;
(3)主库A校验用户名、密码后,开始按照备库B传过来的位置,从本地读取binlog,并将其发送给备库B;
(4)备库B接收到binlog后,将其写到本地文件,称为中转日志 relay log
(5)备库B上的 sql_thread 线程读取中转日志 relay_log,解析出日志中的命令,并执行。

注:在后续的MySQL版本中,sql_thread 演化为多线程,但处理流程是不变的。

1.2 主备同步中的关键日志:binlog:

从上文中的主备同步流程中可以看到,其中关键的文件是binlog,binlog有三种格式,用于备库通过binlog完成数据同步。

1.2.1 binlog的三种格式:

(1)statement;
(2)row;
(3)mixed(statement 与 row 两种格式的混合)

1.2.2 举例说明statement和row两种格式的区别:

为说明binlog的三种格式的区别,先创建一个表t,随后分别在 STATEMENT 和 ROW 格式下执行 delete 操作,观察生成的binlog中内容的异同。

首先,执行以下语句在主节点A上创建一个表并初始化一部分数据:

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `a` int(11) DEFAULT NULL,
  `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `a` (`a`),
  KEY `t_modified`(`t_modified`)
) ENGINE=InnoDB;

insert into t values(1,1,'2018-11-13');
insert into t values(2,2,'2018-11-12');
insert into t values(3,3,'2018-11-11');
insert into t values(4,4,'2018-11-10');
insert into t values(5,5,'2018-11-09');

创建后的表t中的数据:

mysql> select * from t;
+----+------+---------------------+
| id | a    | t_modified          |
+----+------+---------------------+
|  1 |    1 | 2018-11-13 00:00:00 |
|  2 |    2 | 2018-11-12 00:00:00 |
|  3 |    3 | 2018-11-11 00:00:00 |
|  4 |    4 | 2018-11-10 00:00:00 |
|  5 |    5 | 2018-11-09 00:00:00 |
+----+------+---------------------+
5 rows in set (0.01 sec)

然后,设置MySQL的binlog格式为STATEMENT:

mysql> set global binlog_format = "STATEMENT";
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like "binlog_format";
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.00 sec)

执行 delete 语句:

mysql> delete from t /*comment*/ where a>=4 and t_modified<='2018-11-10' limit 1;
Query OK, 1 row affected (0.01 sec)

查看binlog中的内容:
statement格式binlog示例

可以看到,在statement格式下 binlog会原封不动的记录下执行的SQL命令,甚至连注释也一并记录了。

执行 show warnings; 命令 查看delete语句的执行结果:

delete执行warnings

可以看到这个命令可能是 unsafe 的,这是因为delete带limit操作,可能会导致主备数据不一致的情况,例如主库上使用的是索引a,那么根据索引a找到的第一个满足条件的行是 a=4 这一行,而如果备库使用了索引 t_modified,那么删除的就是 a=5 这一行。

而如果使用 binlog_format=‘ROW’ 的格式,则不会出现上述问题,这是因为 ROW格式下 binlog中不会存储SQL语句的原文,而是替换成了两个event:Table_map 和 Delete_rows。其中 Table_map用于说明接下来的操作的表是test库的表t,Delete_rows用于定义删除的行为。

row格式bilog示例

使用 mysqlbinlog 工具解析ROW格式的binlog,解析结果如下图所示,可见 当binlog_format使用row格式的时候,binlog里面记录了真实删除行的 主键id,这样binlog传到备库去的时候,就肯定会删除id=4的行,不会有主备删除不同行的问题。

(statement格式记录SQL语句本身,row格式记录SQL语句具体到对每一行的操作,row格式比statement格式增加了确定性。)

row格式binlog示例的详细信息

1.2.3 mixed格式的作用:

因为有些statement格式的binlog可能会导致主备不一致,所以需要使用row格式。但是row格式的缺点是很占空间,例如当使用delete语句删除10万行数据时,用statement的话只需要在binlog中记录一条SQL语句,占用几十个字节的空间,而使用row格式的binlog,就要把这10万行记录都写入到binlog中,这样做不仅会占用更大的空间,也会由于写binlog耗费IO资源而影响执行速度。

因此MySQL采取了一种折中方案,即mixed格式的binlog,mixed格式的意思是:MySQL会自行判断这条SQL语句是否可能会引起主备不一致,如果有可能,则使用row格式,否则就使用statement格式。

但目前越来越多的场景要求把MySQL的binlog格式设置为row,row格式的binlog还具有很多优点,例如:恢复数据(当误删除了某些数据时,直接将binlog中的delete操作改为对应的insert操作重新执行即可,反之亦然)。

因此,线程的MySQL如果设置的binlog格式是statement的话,那么基本可以认定为是一个不合理的设置,至少应该将其设置为mixed格式,而最佳的设置应该是row格式。

1.3 双M主备结构下的循环复制问题:

实际生产中使用的比较多的主备结构是“双M结构”,如下图所示,即 节点A和节点B之间总是互为主备关系,这样在切换的时候就不需要再修改主备关系。

但双M结构有一个问题需要解决,就是binlog的循环复制,解决方法为在binlog中记录一条命令第一次执行时所在实例的 server_id,主备库的server_id必须配置为不同,当收到另一个库发来的binlog时,先判断server_id是否跟自己相同,如是则直接将收到的binlog丢弃,以此来避免发生循环复制。
MySQL主备切换流程--双M结构

2. MySQL是如何保证高可用的:

一句话概括:

只有保证足够小的主备延迟,才能保证足够高的可用性。
主备切换策略有两种:基于可靠性、基于可用性。一般选择基于可靠性,存在一段时间整个系统不可用,但可靠。
如果是异常下主备切换,主备延迟越大,系统对外不可用的时间越长(需要备库从主库拉取数据),如果主备延迟超过阈值,将导致系统持续不可用。

(可用性:系统持续对外提供服务的能力,一般用几个9表示,例如 99.999% 表示的是全年99.999%的时间可用;)
(可靠性:系统保证数据不丢失的能力。)

正常情况下,只要主库执行更新生成的所有binlog,都可以传到备库并被正确的执行,备库就能达到跟主库一致的状态,这就是 最终一致性
但是,MySQL要提高可用性,只有最终一致性是不够的,还需要考虑一些其他的因素,例如:主备延迟。

2.1 主备延迟:

所谓主备延迟,是指同一个事务在备库执行完成的时间 和 主库执行完成时间之间的差值。

与主备间的数据同步有关的时间点包括以下三个:
(1)主库A执行完一个事务,写入binlog,记这个时刻为 T1;
(2)之后将binlog传递给备库B,记备库B接收完成这个binlog的时刻为 T2;
(3)备库B接收到binlog后开始执行并将数据写入完成,记这个时刻为 T3。

三个时间点将主备同步binlog的过程分为两个时间段,即:主库通过网络连接将binlog传递给备库并在备库上接收完成的时间、备库收到binlog后在本地解析并执行binlog的时间。

其中,通过“网络连接”这段时间是MySQL主备节点非可控的,且在网络正常连接的情况下,日志从主库传给备库的时间是很短的(主备之间一般都是通过局域网连接)。也就是说,主备延迟的主要来源是:备库接收完binlog后执行完这个事务所耗费的时间。

可能导致备库执行binlog所需的时长增加的因素有:
(1)主备节点所部署的主机性能差异;(解决方法:主备的主机做对称部署)
(2)备库的业务压力(读操作)更大;(解决方法:采用一主多从)
(3)一次性执行的事务过大,例如几种的delete删除太多数据。(解决方法:避免一次性集中操作大量数据,避免在高峰期操作归档、删除历史数据这类操作)

2.2 主备切换策略:

由于主备延迟的存在,切换策略有不同的选择,主要分为:
可靠性优先策略、可用性优先策略

在实际应用中,更建议使用“可靠性优先策略”,毕竟保证数据正确,应该是数据库服务器的底线,在这个基础上,通过减少主备延迟,提升系统性能的可用性。

2.2.1 可靠性优先策略下的主备切换过程:

(1)判断备库 B 现在的 seconds_behind_master,如果小于某个值(比如 5秒)继续下一步,否则持续尝试这一步;
(2)把主库 A 改成只读状态,即把 readonly 设置为 true;
(3)判断备库 B 的 seconds_behind_master 的值,直到这个值变成0为止;
(4)把备库B改成可读写状态,也就是把 readonly 设置为 false;
(5)把业务请求切换到备库 B。

其中,seconds_behind_master 用于表示当前备库延迟了多少秒,可通过在备库上执行 show slave status 命令查看。
当主库将binlog传给从库时,会在其中带上主库写入时的时间,备库收到后将其与当前的系统时间做差值,得到 seconds_behind_master 的值,也就是 (T3 - T1)的值。

下图所示为MySQL可靠性优先主备切换流程演示图:(其中SBM为seconds_behind_master的缩写)
MySQL可靠性优先主备切换流程

3. MySQL主节点切换后确定新的复制位移:

请添加图片描述

以图中双主多从的结构为例,其中 A 和 A’ 互为主备,从库 B、C、D 指向的是主库 A。主库A负责写操作,其他从库负责读操作。

相比于一主一备的切换流程(只有A和A‘),一主多从结构在切换完成后,A’ 成为新的主库,从库B、C、D也要重新接到A‘上,这个过程中有一个问题需要解决:从库上执行 change master 时的两个参数 MASTER_LOG_FILEMASTER_LOG_POS,即新主库的 同步位点(主库对应的文件名和日志偏移量) 如何确定。

有两种方式:

(1)基于位点:
A’上的binlog中可以解析出A发生故障时刻,从那之后开始同步即可,但需要配置跳过错误,slave_skip_errors,操作复杂且容易出错。
因此MySQL 5.6版本引入了GTID,彻底解决了 B -> A’ 的困难。

(2)GTID:
GTID = Global Transaction Identifier,“全局事务ID”

网站文章

  • Linux常见命令

    注:要查看命令的具体使用,可以使用man查看命令帮助,如 man ls 1、login  登录系统   login [name][-p][-h 主机名称]一般打开系统,就会出现,localhost login:root   password:   为安全起见,输入密码时,字符不会在屏幕上回显,光标也不会移动。注:Linux是一个多用户操作系统,可以同时接受多个用

    2024-02-01 03:31:37
  • element plus 轮播图第一页数据不显示问题

    参考网址element-plus 使用 el-carousel 跑马灯默认第一页不显示_前端老实人的博客-CSDN博客_element plus 走马灯关键代码 :在data里面定义一个初始化数据即可,里面要有长度 banner:[{}], .

    2024-02-01 03:31:31
  • 整数替换:将键盘输入的整数变成1,所用的最小次数 1)n是偶数,n=n/2 2)n是奇数,n=n-1/n=n+1 例如:7 -> 8 -> 4 -> 2 -> 1

    初试: import java.util.Scanner; class 算法_整数替换 { /* 将键盘输入的整数变成1,所用的最小次数 1)n是偶数,n=n/2 2)n是奇数,n=n-1/n=n+1...

    2024-02-01 03:31:23
  • Android阴影绘制的方式

    不管是自定义View也还是自定义ViewGroup,都是一样的效果,我们都是通过Paint画笔自己画出阴影,本质都是操作onDraw方法。核心类就是 BlurMaskFilter 类,它的兼容性比较好...

    2024-02-01 03:30:53
  • Spark作业执行原理(六)——获取执行结果

    Spark作业执行原理(六)——获取执行结果

    对于Executor的计算结果,会根据结果的大小使用不同的处理策略:计算结果在(0,128MB-200KB)区间内:通过Netty直接发送给Driver终端;计算结果在[128MB, 1GB]区间内:将结果以taskId为编号存入到BlockManager中,然后通过Netty把编号发送给Driver终端;阈值可通过Netty框架传输参数设置spark.a...

    2024-02-01 03:30:47
  • python变量的内建方法3——String型

    #a=整数型变量1.a.capitalize()#此方法返回的字符串只有它的第一个字符大写的副本。例:In [40]: a=&#39;abc&#39;In [41]: a.capitalize()Ou...

    2024-02-01 03:30:40
  • JNDI注入

    JNDI注入

    JNDI(The Java Naming and Directory Interface,Java命名和目录接口)是一组在Java应用中访问命名和目录服务的API,命名服务将名称和对象联系起来,使得我们可以用名称访问对象。

    2024-02-01 03:30:12
  • ES6学习——set map数据结构 、 DOM classlist属性、创建对象 、Symbol应用

    ES6学习——set map数据结构 、 DOM classlist属性、创建对象 、Symbol应用

    对象方法就是把对象中的属性,用匿名函数的形式编程方法(之前就有)。

    2024-02-01 03:30:07
  • 如何在SQLServer中处理每天四亿三千万记录的(数据库大数据处理)

    项目背景这是给某数据中心做的一个项目,项目难度之大令人发指,这个项目真正的让我感觉到了,商场如战场,而我只是其中的一个小兵,太多的战术,太多的高层之间的较量,太多的内幕了。具体这个项目的情况,我有空再写相关的博文出来。这个项目是要求做环境监控,我们暂且把受监控的设备称为采集设备,采集设备的属性称为监控指标。项目要求:系统支持不少于10w个监控指标,每个监控指标的数据更新不大于20秒,存储延迟...

    2024-02-01 03:30:00
  • 《软件开发的201个原则》

    《软件开发的201个原则》

    作为一名从事软件开发工作的读者,深刻体会到《软件开发原则》书中的系列原则,在我开发过程中处处可见。如果遵循这些原则,那么对你的开发是十分有效的。在项目开发过程格遵守开发流程,让一切异常都有迹可循,有法可解,工作效率显著提示。

    2024-02-01 03:29:28