目录
1、写作目的
现在的服务都是分布式,MySQL的集群架构也是一样。那么MySQL的集群架构中有一个点是读写分离,而读写分离是基于binlog实现的。 那么接下来就MySQL的读写分离和binlog为突破点进行分析为什么大厂中的默认隔离级别是RC。总体来说以时间线为基准进行讲解。
2、binlog格式
3、为什么MySQL默认的隔离级别是RR
参考:互联网项目中mysql应该选什么事务隔离级别(https://zhuanlan.zhihu.com/p/59061106) 在Oracle,SqlServer中都是选择读已提交(Read Commited)作为默认的隔离级别, 为什么Mysql不选择读已提交(Read Commited)作为默认隔离级别, 而选择可重复读(Repeatable Read)作为默认的隔离级别呢?
首先要明确一点:MySQL需要主从复制!。主从复制需要binlog和事务的隔离级别。
历史原因:5.0版本及之前binlog只支持STATEMENT这种格式。为了支持主从复制,那么事务的隔离级别只能是可重复读(Repeatable Read)。
因为当binlog为STATEMENT格式,且隔离级别为读已提交(Read Commited)时,会有bug导致主从库的数据不一致。
如下图所示,在主(master)上执行如下事务。
此时在主(master)上执行下列语句
select * from test;
输出如下:
+---+ | b | +---+ | 3 | +---+ 1 row in set
但是,你在此时在从(slave)上执行该语句,得出输出如下:
Empty set
这样,你就出现了主从不一致性的问题!原因其实很简单,就是在master上执行的顺序为先删后插!而此时binlog为STATEMENT格式,它记录的顺序为先插后删!从(slave)同步的是binglog,因此从机执行的顺序和主机不一致!就会出现主从不一致!
如何解决? 解决方案有两种:
。隔离级别设为可重复读(Repeatable Read),在该隔离级别下引入间隙锁。当Session 1执行delete语句时,会锁住间隙。那么,Ssession 2执行插入语句就会阻塞住! 。将binglog的格式修改为row格式,此时是基于行的复制,自然就不会出现sql执行顺序不一样的问题!奈何这个格式在mysql5.1版本开始才引入。
因此由于历史原因,mysql将默认的隔离级别设为可重复读(Repeatable Read),保证主从复制不出问题!
4、为什么大厂MySQL设置的隔离级别是RC
。RC和RR的一个很大的区别是RR解决了不可重复读的问题。但是仔细想一想,不可重复读是问题吗?其实不是问题。我第一次读到的是1,再次读的时候为2,中间有人把1修改为2,那我读取到2就没问题。RC反应的是真实数据的变迁。主要数据真实有效(没提交就是脏读,无效),为什么怕被别人读出来呢? 。RR下有间隙锁,使用锁就会导致资源的消耗和等待。
5、MySQL主从复制的三种方式
5.1、异步复制
。Slave 端的 IO 进程连接上 Master,向 Master 请求指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 。Master 接收到来自 Slave 的 IO 进程的请求后,负责复制的 IO 进程根据 Slave 的请求信息,读取相应日志内容,返回给Slave 的IO进程,并将本次请求读取的 bin-log 文件名及位置一起返回给 Slave 端 Slave 端的 IO 。进程接收到信息后,将接收到的日志内容依次添加到 Slave 端的 relay-log(中继日志) 文件的最末端,并将读取到的 Master端的 bin-log 的文件名和位置记录到 master-info 文件中,以便在下一次读取的时候能够清楚的告诉 Master:”我需要从某个 bin-log 的哪个位置开始往后的日志内容,请发给我”; 。Slave 端的 Sql 进程检测到 relay-log(中继日志)中新增加了内容后,会马上解析 relay-log 的内容成为在 Master 端真实执行时候的那些可执行的内容,并在本地执行。
存在的问题: 主库的数据commit到binlog后则返回SUCCESS给客户端。因为binlog同步给slave是异步的,如果此时master提交而未同步给到slave, 则数据发生丢失。
5.2、半同步复制
主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制, 半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,半同步复制最好在低延时的 网络中使用。 **首先明确一点:master上已提交,然后等待slave的ACK,最后返回给客户端结果。
存在的问题:** 幻读:当用户发起一个事务,该事务已经写入redo日志和binlog日志,所以该数据为有效状态。在RC隔离级别下其他事务是可以读取到的。如果 在等待slave的ack过程中binlog还没传输到slave上,则其他事务查询该数据为修改后的数据,此时master宕机。slave上升为master。 此时在查询新master则查询不到数据,出现幻读。 数据丢失:提高数据的安全性,但不能完全避免数据丢失。
5.3、增强半同步复制
现在我们已经知道,在半同步环境下,主库是在事务提交之后等待Slave ACK,所以才会有数据不一致问题。 **所以这个Slave ACK在什么时间去等待,也是一个很关键的问题了。**因此MySQL针对半同步复制的问题, 在5.7.2引入了Loss-less Semi-Synchronous,在调用binlog sync之后,engine层commit之前等待Slave ACK。 这样只有在确认Slave收到事务events后,事务才会提交。
首先明确一点:在等待ack的时候,master状态为未提交。
存在的问题: 在这种模式下解决了after_commit模式带来的幻读和数据丢失问题,因为主库没有提交事务。但也会有个问题, 假设主库在存储引擎提交之前挂了,那么很明显这个事务是不成功的,但由于对应的Binlog已经做了Sync操作, 从库已经收到了这些Binlog,并且执行成功,相当于在从库上多了数据,也算是有问题的,但多了数据,问题一般不算严重。