MySQL主从架构

主从架构是用于解决什么问题？

用于解决数据库性能瓶颈的。单个数据库下，能同时连接的客户端数量有限，这时候容易成为瓶颈；另外，单个MySQL服务器，如果宕机了，那么就没有应急方案，从事导致整个系统挂掉。

主从架构分为有多重类型——一主一从、一主多从（一主二从一备主）

那么就算主库此时挂了，从库也能充当主库使用。

同时，在这种架构下，能实现读写的分离，提高并发度（尤其是读多写少的场景下）。主库负责处理写请求、从库负责读请求。

主从数据同步的基石——binlog、relaylog

binlog是二进制日志，用于在更新数据时写入。可以理解为里面内容就是写入MySQL的最新数据。

relaylog，叫中继日志，是从库才有的日志，正如名字一样，“中继”，也就是从主库那里复制binlog日志，或者供别的从库复制relaylog使用。relaylog就是从库用于更新数据的

不过还要看binlog的格式，Statement格式是基于SQL实现复制（好处是日志存储空间小、弊端是NOW()等函数调用结果不一致）、Row格式是基于行信息复制（相当于复制数据、好处是数据无误坏处是存储空间大）、Mixed是混合复制（智能选择使用statement还是row）

具体流程为——当一条写请求来后，更新了主库的binlog日志，然后主库会创建一个log dump线程，用于向从库发送bin log日志内容，从库开启同步后，会创建一个IO线程用来连接主库，请求主库的bin log，从库接收到主库发来的bin log日志后，保存在本机的relay log中。接着从库会有一个线程负责读取relay log日志内容，更新从库的数据，完成主库与从库之间数据同步。

主从复制类型

图源https://juejin.cn/post/7269953746851266620#heading-0

主从复制有多种类型，本质还是同步时机的不同、同步方式的区别（指的是多源复制）。不同类型的复制都会达到数据的最终一致性，只是达到一致性的延迟有所不同。

大致的流程都一样，只是些许步骤的顺序不同。

异步复制（这是MySQL默认的复制策略）
- 客户端事务提交->写binlog日志->通知log dump线程向从库发送bin log日志->返回客户端成功响应
- 这种方式不用等待从库更新relay log，直接返回客户端成功响应，速度最快。但是在“客户端收到成功响应”到“从库同步数据完成前”这段时间，如果客户端立马向从库发起读请求，读到的数据可能是旧数据。
全同步复制
- 客户端事务提交->写binlog日志->通知log dump线程向从库发送bin log日志->等待所有从库写入relay log->所有从库同步完数据->返回客户端成功响应
- 全同步复制需要等待所有从库同步完成才返回客户端成功响应，数据一致性最高，但是性能最差。
半同步复制
- 客户端事务提交->写binlog日志->通知log dump线程向从库发送bin log日志->至少有一个从库写入relay log->返回客户端成功响应
- 半同步复制相比于全同步复制，性能更高（因为只需要一个从库写入relay log）
增强半同步复制
- 客户端事务提交->写binlog日志->通知log dump线程向从库发送bin log日志->至少有一个从库写入relay log->主库提交存储引擎->返回客户端成功响应
- 增强半同步和半同步很像，但是增强半同步复制方式，会等relay log写入后，主库才会提交存储引擎（避免relay log的数据被回滚失效）
多源复制
- 多源复制是指一个从库的数据是从多个主库复制而来，常用语OLAP业务查询
  
  OLAP（Online Analytical Processing，联机分析处理）业务是一种以快速、多维、交互式分析大量历史数据为核心的数据处理模式，其主要目的是支持商业智能（BI）和决策支持系统，通过对数据进行切片、钻取、旋转等操作，帮助用户从不同角度洞察业务趋势、发现潜在规律并制定战略决策，与处理日常交易的OLTP（联机事务处理）业务形成鲜明对比。