MySQL（架构）[主从篇]

原理

• 第一步：对主库进行增删改操作。
• 第二步：主库记录变更到日志中。
• 第三步：从库有两个线程，一个是 I/O 线程，负责从主库的日志中读取变更，并写入自己的日志；另一个是 SQL 线程，负责读取从库日志中的变更，并写入从库。

常用方案

一主三从是比较合理的部署方案，三台从库的作用分别是：读取、备份和替补。读取和备份很容易理解，读取从库为了应付大量的读操作，备份从库为了执行大量数据的备份工作。替补从库平时不做任何工作，只为了保证自己与主库的数据最接近，这样就可以尽可能的减少数据丢失。

切换从库为主库

在主从结构中，主库挂了，需要我们手动切换从库为主库。

• 第一步：查看每台从库的日志文件，找出与主库最接近的从库。
  
• 第二步：如果主库没有死透，把主库的日志同步到该从库，再同步到其它所有从库。
  
• 第三步：切换该从库为主库。
  

主从架构的特点

使用主从结构可以实现读写分离，支持了高并发，也可以满足单一实例的一切性能要求。但还存在以下两个问题：

一致性

主库的完成了增删改操作，也记录了日志，但从库还没有把最新的日志取走，主库就挂了，这时会导致数据丢失。也就是说，用户的某些操作被抹去了，需要重新来过，但用户并不知道，因为主库已经执行完成，并告知用户已成功了，如果是信用卡还款，那这个倒霉的用户可能会稀里糊涂的被拉近黑名单。（可使用半同步复制解决）

高可用

无法监测问题，主库挂了后，不能自动找到与主库数据最接近的从库，并把它切换为主库。这对于运维人员来说太不友好了，很可能有上百个从库日志等着被检查。（可使用 MHA 架构解决）

半同步复制

半同步复制可以解决主从库之间数据一致性的问题，我们先来看看以前主从库同步数据的流程：

这里会造成数据不一致的地方，就在于发送日志这一步，主库发送后，继续执行操作，提交并返回结果。如果发送日志失败了，但结果已经返回成功，这就会让用户以为自己操作成功了，其实从库还没有记录这一操作数据。

下面我们来看看半同步复制是怎么解决这一问题的：

使用半同步复制的方式，在主库处理完成提交后，还需要等待从库返回的结果，再返回结果给用户。

适用场景

性能

各从库分工明确，所以不会影响性能，但从库的负载均衡，需要借助负载工具来维护。支持读写分离、高并发，可以满足单一实例的一切性能要求。

高可用

不具备自动探测故障的能力。需要人工转移故障，但支持在线切换。不支持 VIP。不会产生脑裂。

部署

主从架构是 MySQL 原生的高可用方案。不需要增加很多额外的机器。支持任意引擎。主从架构需要频繁的同步数据，所以对网络的稳定性要求较高。支持跨机房容灾。