MySQL主从复制

MySQL主从复制

MySQL主从复制是MySQL负载均衡、读写分离和高可用(HA)的基础。
主要针对的是InnoDB的行级复制。

InnoDB与MyIsam的主要区别:
InnoDB支持事务,有行级锁;而MyIsam只有表级锁,不支持事务。

优点:

  1. 通常Slave是只读的,可以分摊Master的部分读压力,可以提高性能
  2. 如果Master宕机,Slave可以承担Master的责任,对外提供服务,可以提高容灾性

(一)异步复制(默认)

异步复制

MasterSlave建立复制关系后,Slave上会有一个I/O线程读取Master的二进制文件Binlog,并写到本地的Relay log,然后Slave开启另一个线程异步地读取Relay log,通过这种方式达成主从复制。

缺点:
Master在接受到用户的commit请求后,不管Slave的执行情况,直接就返回给用户成功。由于是异步复制,如果Master已经返回给用户执行成功,但是Binlog还没来得及传到Slave,这时Slave是落后于Master一个事务的。
所以异步复制是无法保证主从强一致性的


(二)半同步(semi-sync)复制(强一致性)

同步复制:只有在Master和Slave都执行成功后,才返回用户执行成功,这种复制是原子性的2PC(二阶段提交),要么都成功,要么都不成功,可以保证强一致性。

半同步复制Slave接收到Binlog写入Relay log后就通知Master可以返回执行成功。

半同步复制 & 同步复制 的区别:
半同步复制:Slave接收到日志后,就通知Master可以返回成功。
同步复制:Slave接收到日志后,要执行成功,才会通知Master可以返回成功。

1.半同步复制的两种实现方式

两者的区别:是否需要等待Slave的ACK才InnoDB commit

(1)AFTER_COMMIT:先提交,再等待ACK(2PC)
  1. Master将事务的Redo logBin log刷入磁盘
  2. InnoDB commit,事务提交,释放锁,此时用户可以看到事务的更新
  3. 等待Slave的ACK后才返回给用户成功,否则回滚

缺点:
如果Master执行InnoDB commit提交事务成功,用户可以看到事务的更新,但是Binlog还未来得及传给Slave时Master宕机了,Slave接替了Master的职责,用户看不到自己的更新,出现了幻读

(2)AFTER_SYNC:等待ACK,再提交(强一致性)
  1. Master将事务的Redo logBin log刷入磁盘
  2. 等待Slave的ACK
  3. 接收到ACK后才进行InnoDB commit,事务提交,释放锁

优点:强一致性

2.开启半同步复制

Master

开启半同步:rpl_semi_sync_master_enabled = 1
Master等待Slave的ACK时间:rpl_semi_sync_master_timeout = 10000

等待ACK的时间:默认10000,单位ms。
如果超过了该时间,会切换为默认的异步复制

Slave

开启半同步:rpl_semi_sync_slave_enabled = 1

为了保证半同步立即生效,要重启Slave的I/O线程。


(三)并行复制(效率)

半同步复制可以保证数据的强一致性,但是I/O线程(用于拉取BinlogRelay log)和SQL线程(将Relay log中的数据写入Slave库)都是串行执行的,效率不高,在高负载下,Master发送数据的数据远远高于Slave消费数据的速度,Slave的数据就会存在延迟

(1)并行I/O线程

将从Master拉取Binlog 和 将Binlog写入Relay log拆分为两个线程,并发执行。

(2)并行SQL线程:收益更高

为了保证事务的序列化执行,多线程并行必须要顺序读取Relay log,将不冲突的事务并发执行,保证SlaveMaster事务顺序一致


(四)复制方式

1.基于SQL语句的复制(SBR)

statement-based replication,类比Redis的AOF持久化。
默认复制方式。

优点
  1. binlog
  2. binlog可以用于实时的还原,而不仅仅用于复制
缺点
  1. 不是所有UPDATE都可以复制,尤其是包含不确定操作时
  2. 复制需要进行全表扫描的UPDATE时,需要请求比RBR更多的行级锁
  3. 对于一些复杂的语句,服务器耗资源情况更严重

2.基于行的复制(RBR)

row-based replication,类比Redis的RDB持久化。

优点
  1. 任何情况都可以被复制,这种复制是最安全可靠的
  2. 如果表上有主键,那么复制很快
缺点
  1. RBRbinlogSBR大了很多
  2. 复杂的回滚时binlog会包含大量的数据
  3. 主服务器执行UPDATE语句,所有发生变化的记录都会被写入binlog,会导致频繁的并发写问题,而SBR只写一次
  4. 无法从binlog看到复制了什么语句

3.混合模式复制(MBR)

mixed-based replication。


(五)MySQL主从同步有延迟,Redis缓存了脏数据怎么办?

字节跳动社招有3-4次都被问到,参考https://blog.csdn.net/john1337/article/details/98850192

  1. 根据CAP定理BASE定理,如果想要满足高可用,那么就只能保证最终一致性。用到Redis的业务都不可能强一致性,只要保证最终一致性即可

  2. 如果要求强一致性,可以Redis强制读主库,这种方法主库压力会比较大。

    苏宁购物车的异地多活就是这么做的:Redis强制读MySQL主库,MySQL从库只作为冷备

  3. 所有请求强制读主库过于粗暴,可以在只有主库有更新时强制读主库,其他时候读从库:写主库时(insert/update/delete),将“库-表-主键”拼装成一个keydb-table-pk)存储到Redis缓存中,过期时间设置为MySQL主从同步的延迟,Redis读库的时候判断key是否存在:key存在强制读主库,否则允许读从库

-------------本文结束感谢您的阅读-------------

本文标题:MySQL主从复制

文章作者:DragonBaby308

发布时间:2019年07月26日 - 21:00

最后更新:2020年02月27日 - 21:00

原始链接:http://www.dragonbaby308.com/mysql-master-slave/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

急事可以使用右下角的DaoVoice,我绑定了微信会立即回复,否则还是推荐Valine留言喔( ఠൠఠ )ノ
0%