基础编程学习快乐每一天
首页
留言
Siddim.com
当前位置:
首页
>
编程知识库
>
后端开发知识
>
面试官:你能说出MySQL主从复制的几种复制方式吗?
面试官:你能说出MySQL主从复制的几种复制方式吗?
阅读
1
2020-08-16
目录
异步复制
多线程复制
增强半同步复制
异步复制
MySQL
的复制默认是异步的,主从复制至少需要两个
MYSQL
服务,这些
MySQL
服务可以分布在不同的服务器上,也可以在同一台服务器上。
MySQL
主从异步复制是最常见的复制场景。数据的完整性依赖于主库
BINLOG
的不丢失,只要主库的
BINLOG
不丢失,那么就算主库宕机了,我们还可以通过
BINLOG
把丢失的部分数据通过手工同步到从库上去。
注意:主库宕机的情况下,
DBA
可以通过
mysqlbinlog
工具手工访问主库
binlog
,抽取缺失的日志并同步到从库上去;也可以通过配置高可用
MHA
架构来自动抽取缺失的数据补全从库,或者启用
Global
Transaction
Identifiers
(
GTID
)来自动抽取缺失
binlog
到从库。
MySQL
在
BINLOG
中记录事务(或
SQL
语句),也就是说对于支持事务的的引擎(例如
InnoDB
)来说,每个事务提交时都需要写
BINLOG
;对于不支持事务的引擎(例如
MyISAM
)来说,每个
SQL
语句执行完成时,都需要些
BINLOG
。为了保证
Binlog
的安全,
MySQL
引入
sync
_
binlog
参数来控制
BINLOG
刷新到磁盘的频率。
show variables like 'sync_binlog';
在默认情况下,
sync
_
binlog
=
1
,表示事务提交之前,
MySQL
都需要先把
BINLOG
刷新到磁盘,这样的话,即使出现数据库主机操作系统崩溃或者主机突然掉电的情况,系统最多损失
prepared
状态的事务;设置
sync
_
binlog
=
1
,尽可能保证数据安全。
sync
_
binlog
=
0
,表示
MySQL
不控制
binlog
的刷新,由文件系统自己控制文件缓存的刷新。
sync
_
binlog
=
N
,如果
N
不等于
0
或者
1
,刷新方式同
sync
_
binlog
=
1
类似,只不过此时会延长刷新频率至
N
次
binlog
提交组之后。
以上是传统的异步复制,在
MySQL5
.
7
的并行复制技术(也称多线程复制)到来之前,为人诟病最多的还是效率问题,
slave
延迟是一个顽疾,虽然之前已经出现了
schema
级别的并行复制,但实际效果并不好。
多线程复制
在
MySQL5
.
7
中,带来了全新的多线程复制技术,解决了当
master
同一个
schema
下的数据发生了变更,从库不能并发应用的问题,同时也真正将
binlog
组提交的优势充分发挥出来,保障了从库并发应用
Relay
Log
的能力。
在
MySQL8
.
0
中,多线程复制又进行了技术更新,引入了
writeset
的概念,而在之前的版本中,如果主库的同一个会话顺序执行多个不同相关对象的事务,例如,先执行了
Update
A
表的数据,又执行了
Update
B
表的数据,那么
BINLOG
在复制到从库后,这两个事务是不能并行执行的,
writeset
的到来,突破了这个限制。
增强半同步复制
前面介绍的复制是异步操作,主库和从库的数据之间难免会存在一定的延迟,这样存在一个隐患:当在主库上写入一个事务并提交成功,而从库尚未得到主库的
BINLOG
日志时,主库由于磁盘损坏、内存故障、断电等原因意外宕机,导致主库上该事务
BINLOG
丢失,此时从库就会损失这个事务,从而造成主从不一致。往期:
为了解决这个问题,从
MySQL5
.
5
开始,引入了半同步复制,此时的技术暂且称之为传统的半同步复制,因该技术发展到
MySQL5
.
7
后,已经演变为增强半同步复制(也成为无损复制)。在异步复制时,主库执行
Commit
提交操作并写入
BINLOG
日志后即可成功返回客户端,无需等待
BINLOG
日志传送给从库,如图所示。
而半同步复制时,为了保证主库上的每一个
BINLOG
事务都能够被可靠地复制到从库上,主库在每次事务成功提交时,并不及时反馈给前端应用用户,而是等待至少一个从库(详见参数
rpl
_
semi
_
sync
_
master
_
wait
_
for
_
slave
_
count
)也接收到
BINLOG
事务并成功写入中继日志后,主库才返回
Commit
操作成功给客户端(不管是传统的半同步复制,还是增强的半同步复制,目的都是一样的,只不过两种方式有一个席位地方不同,将在下面说明)
半同步复制保证了事务成功提交后,至少有两份日志记录,一份在主库的
BINLOG
日志上,另一份在至少一个从库的中继日志
Relay
Log
上,从而更进一步保证了数据的完整性。往期:
在传统的半同步复制中,主库写数据到
BINLOG
,且执行
Commit
操作后,会一直等待从库的
ACK
,即从库写入
Relay
Log
后,并将数据落盘,返回给主库消息,通知主库可以返回前端应用操作成功,这样会出现一个问题,就是实际上主库已经将该事务
Commit
到了事务引擎层,应用已经可以可以看到数据发生了变化,只是在等待返回而已,如果此时主库宕机,有可能从库还没能写入
Relay
Log
,就会发生主从库不一致。
增强半同步复制就是为了解决这个问题,做了微调,即主库写数据到
BINLOG
后,就开始等待从库的应答
ACK
,直到至少一个从库写入
Relay
Log
后,并将数据落盘,然后返回给主库消息,通知主库可以执行
Commit
操作,然后主库开始提交到事务引擎层,应用此时可以看到数据发生了变化。增强半同步复制的大致流程如下图所示。
半同步复制模式下,假如在传送
BINLOG
日志到从库时,从库宕机或者网络延迟,导致
BINLOG
并没有即使地传送到从库上,此时主库上的事务会等待一段时间(时间长短由参数
rpl
_
semi
_
sync
_
master
_
timeout
设置的毫秒数决定),如果
BINLOG
在这段时间内都无法成功发送到从库上,则
MySQL
自动调整复制为异步模式,事务正常返回提交结果给客户端。
半同步复制很大程度上取决于主从库之间的网络情况,往返时延
RTT
越小决定了从库的实时性越好。通俗地说,主从库之间的网络越快,从库约实时。
注意:往返时延
RTT
(
Round
-
Trip
Time
)在计算机网络中是一个重要的性能指标,它表示从发送端发送数据开始到发送端接收到接收端的确认,总共经历的时长(这里可能有点拗口,我们可以理解为
TCP
三次握手的前两次握手)。
来源:
cnblogs
.
com
/
itbsl
/
p
/
13507401
.
html
? ~
以上数据来源于网络,如有侵权,请联系删除。
上一篇:
谈谈 ZooKeeper 的定位:能解决什么问题?不能解决什么问题?
下一篇:
面试官:谈谈常用的Arraylist和Linkedlist的区别
评论
(0)
提交
类别
基础编程学习
HTML
PHP
Python
编程知识库
后端开发知识
热门文章
Java并发中的同步容器与并发容器,你了解多少?
Innodb中的事务隔离级别和锁的关系,难倒一半面试者!
SpringBoot + minio实现分片上传、秒传、续传
面试官:你知道消息队列如何保证数据不丢失吗?
JAVA知识 Java8新特性
面试官:谈谈为什么要限流,有哪些限流方案?
说说动态代理与静态代理区别
面试官:思考Tomcat 类加载器为什么要违背双亲委派模型?
boot-admin 基于SpringBoot的后台权限管理系统,可作为脚手架,用于快速搭建项目
SpringBoot+Vue+App+硬件实现智能家居系统项目