一:主从模式
1、主从复制:
步骤:
- master记录写操作到Binlog日志(master的BinlogDump Thread接收到写操作后,会读取binlog信息推送给slave的I/O Thread)
- slave读取主的Binlog并写入信息到自己的Relay log中继日志(I/O Thread接收到推送过来的binlog信息,写入到本地Relay log)
- slave读取中继日志更新数据(SQL Thread检测到Relay log变更请求,解析内容并在执行更新)
以上过程是异步,所以称为异步复制,时序图如下:
异步复制存在问题:
- 数据丢失风险:master写入binlog后,采用异步线程推送,然后继续commit,完全不关心slave是否成功接收。
- 从库只有一个sql thread,如果master并发较高,从库的单线程复制很可能延时。
解决办法:
- 半同步复制-解决数据丢失: master 推送binlog信息给slave后,等待slave成功写入relay log并返回ack信息,再执行commit
- 并行复制-解决复制延迟: 在从库使用多个sql thread同时执行
- 5.6中是基于库的并行,如果slave中只有一个库,或者所有的并发操作都在一个库,便没有意义
- 5.7中基于组的并行复制,真正实现了并行复制
- 原理: 在binlog中将不冲突的多个事务划分到一组,slave会将同一组中的多个事务,使用多线程执行
- 写入binlog时如何知道哪些事务不冲突:innodb提交事务分为prepare和commit阶段:
- prepare阶段会生成redo并刷盘,这时候,已经解析出哪些事务会有冲突。
- commit阶段将sql语句写入binlog,没有冲突的事务分到同一组,然后binlog刷盘,执行commit,将redo log中标记为commit。 自然,分到同一组的事务在slave上便可以使用多线程同步执行。
- binlog中组信息用什么记录呢:使用GTID记录,包含:
- last_committed 编号 :同一组中的事务 ,此编号相同
- sequence_number编号 : 事务编号
二:MMM和MHA架构
传统主从模式下,如果master宕机,集群不可用。 我们需要有备用master,目前有两种实现方式:
MMM架构:
如图示,在常规主从模式下,增加了一台read vip作为master备份,而write vip提供对外服务。 原理:
- 两个master互为主从,也是采用异步复制的方式同步数据
- 架构需要一个监控程序(monitor)和代理程序(agent-每台节点都要安装,用来执行monitor命令),当monitor监控write master异常,会发送命令切换master。
此架构存在问题:
- 需要一台master做备份,浪费资源
- 无法保证数据一致性:read master和slave都是异步复制,主master宕机时,并不能保证备用master比slave的数据新。 那么切换过程中,可能造成事务丢失或者多次事务提交
MHA架构:
MHA组成部分:
- MHA Manager(管理节点): 检测master情况,控制故障转移等。
- MHA Node(数据节点): 运行在每一台mysql上,被manager监控管理,执行具体的故障处理流程。
故障处理流程:
- 保存宕机master的binlog
- 根据binlog位置点找到最新的slave
- 使用最新slave的relay log修复其他slave
- 用保存下来的binlog在最新的slave上修复,提升其为master
- 将其他slave指向新的master,开启新的主从复制
优势:
自动故障转移快,不存在数据不一致问题; 性能优秀,支持半同步复制和异步复制,可以同时监控多个集群。
三:分库分表
拆分模式:
- 垂直拆分:
- 垂直分库:比如把 order 和 user 拆分到不同的库,解决库内表太多的问题。
- 垂直分表:比如order字段太多,拆分到不同的表,解决表内字段太多的问题。
- 水平拆分: 比如order表数据量太大,拆分到不同的库不同的表,解决表内记录太多的问题。
主键策略:
分库分表后,要保证数据主键不能冲突,可以使用以下策略:
- UUID(无序,不推荐)
- SNOWFLAKE(雪花算法,推荐)
- redis(推荐)
分片策略:
范围分片: 根据某个特定字段取范围,比如id为1-100的分到A,101-200的分到B。
- 优点:数据均匀分布在mysql各节点,扩容时数据不需要迁移。
- 缺点:如果数据有冷热情况,则会冷热分布不均,造成节点负荷不均。
hash取模: 根据特定字段的hash值对节点数取模。
- 优点:数据均匀分布在mysql各节点。
- 缺点:也存在冷热分布不均的问题; 另外,如果扩容或者缩容,会造成hash值变动,需要重新分配和迁移数据。
一致性hash: 其实就是hash环取模,弥补普通hash在扩容或者缩容时候的问题。 不过,也存在冷热分布不均的问题。
综上: 选用哪种策略分库分表,要根据实际的业务场景来决定。