什么是MVCC
即多版本并发控制,读取数据时通过一种类似快照的方式将数据保存下来,这样读写与写锁就不会
冲突,不同的事务session只会看到自己特定版本的数据,版本链
MVCC只会在READ COMMITTED(已提交读)和REPEATABLE READ(可重复读)两个隔离级别下工作,已提交读和可重复读的区别在于他们生成ReadView的策略不同
开始事务创建readview,readVIew维护维护当前活动的事务id,即未提交的事务id,排序生成一个数组访问数据,获取数据中的事务id(获取事务id最大的记录,对比readView);
如果在readview的左边(比raedview都小),可以访问(在作弊意味着该事务已经提交)
如果在readview的右边(比readview都大)或者就在readview中,不可以访问,获取roll_pointer,取上一版本重新对比(在右边意味着,该事务在readview生成之后出现,在readview中意味着该事务还未提交)
已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成ReadView,之后的读都复用之前的ReadView。
这就是MySQL的MVCC,通过版本链,实现多版本,可并发读-写,写-读,通过ReadView生成策略的不同实现不同的隔离级别。
MySQL主从同步原理
MySQL主从同步的作用主要有以下几点:
1、故障切换。
2、提供一定程度上的备份服务。
3、实现MySQL数据库的读写分离。
MySQL的主从复制主要有三个线程:master(binlog dump thread),slave(I/O) thread,SQL thread),Master一条线程和和Slave 中两条线程
主节点binlog ,主从赋值的基础是主库记录数据库的所有变更记录到binlog,binlog 是数据库服务器启动的那一刻起,保存所有修改数据库结构或内容的一个文件。
主节点log dump线程,当binlog由变动时,log dump线程读取其内容并发送给节点
从节点i/o线程接受binlog内容,并将其写入relay log 文件中。
从节点的sql线程读取relay log文件内容对数据更新进行重放,最终导致主从数据库的一致
注意:主从节点使用binlog 文件 +position 偏移量来定位同步的位置,从节点会保存其已接受的偏移量,如果从节点发生宕机,则会从position的位置发起同步
由于mysgl默认的复制方式是异步的,主库把日志发送给从库后不关心从库是否已经处理,这样会
产生一个问题,假设主库挂了,从库处理失败了,这时候从库升为主库后,日志就丢失了。由此产生两个概念。
全同步复制
主库写入binlog后强制同步日志到从库,所有的从库都执行完成后才返回给客户端,但是很显然这
个方式的话,性能会受到严重影响。
半同步复制
和全同步不同的是,半同步复制的逻辑是这样,从库写入日志成功后返回ACK确认给主库,主库
收到至少一个从库的确认就认为写操作完成。