MySQL常见的高可用架构

概述：

高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称7天24小时不间断服务，但多多少少有一些时候服务不可用，比如某些时候网页打不开，百度不能搜索或者无法发微博，发微信等。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，一般会同时考虑方案中数据一致性问题。

1.基于共享存储的方案SAN

方案介绍：SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL。

优点:

1.可以避免存储外的其它组件引起的数据丢失。
2.部署简单，切换逻辑简单，对应用透明。
3.保证主备数据的强一致。

限制或缺点:

1.共享存储是单点，若共享存储挂了，则会丢失数据。
2.价格比价昂贵。

2.基于磁盘复制的方案 MySQL+DRDB架构

通过DRBD基于block块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题。
方案介绍：DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：

优点：

1.切换对应用透明。
2.保证主备数据的强一致。

限制或缺点：

1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2.一般配置两节点同步，可扩展性比较差。
3.备库不能提供读服务，资源浪费。

3、MySQL+MHA架构

MHA目前在Mysql高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在mysql故障切换过程中，MHA能做到快速自动切换操作，而且还能最大限度保持数据的一致性。

优点：

1、 代码开源，方便结合业务场景二次开发
2、故障切换时，可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。
3、 可以灵活选择VIP方案或者全局目录数据库方案(更改Master IP映射)来进行切换。

缺点：

1、无法保证强一致，因为从故障Master上保存二进制日志并不总是可行，比如Master磁盘坏了，或者SSH认证失败等。
2、只支持一主多从架构，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。
3、采用全局目录数据库方案切换时，需要应用感知变化，因此对应用不透明，因此要保持切换对应用透明，依然依赖于VIP。
4、不适用于大规模集群部署，配置比较复杂。
5、MHA管理节点本身的HA无法保证。

4、MySQL+MMM架构

MMM即Master-Master Replication Manager for MySQL（mysql主主复制管理器），是关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。

优点：

1、安全、稳定性较高，可扩展性好
2、对服务器数量要求至少三台及以上
3、双主热备模式，读写分离，SLAVE集群可线性扩展（主从复制性要求较高）
4、 同样可实现读写分离。

缺点：

读写分离需要在程序端解决，Master大批量写操作时会产生主从延时

服务器资源：

1、至少五台PC Server，2台MySQL主库，2台MySQL从库，1台MMM Monitor；
2、1台MMM Monitor选择低配；
3、如果不采用F5作为从库的负载均衡器，可用2台PC SERVER部署LVS或HAProxy+Keepalived组合来代替；

参考资料：
https://www.likecs.com/show-855612.html
https://www.jb51.net/article/83400.htm
官方文档：
https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html