mysql高可用架构了解
转自：https://www.cnblogs.com/gomysql/p/3675429.html，https://www.cnblogs.com/gomysql/p/3671896.html
https://cloud.tencent.com/developer/article/1031542
1.MHA
MHA（Master High Availability），是MySQL高可用性环境下故障切换和主从提升的高可用软件。能做到在0~30秒之内自动完成数据库的故障切换操作，在最大程度上保证数据的一致性，以达到真正意义上的高可用。两部分组成：
- MHA Manager（管理节点）；MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。
- MHA Node（数据节点）；MHA Node运行在每台MySQL服务器上。
MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。
MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失。但有风险，如果原主服务硬件故障（InnoDB数据文件损坏）或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据，可以与半同步复制结合起来，降低数据丢失的危险。
目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。
MHA工作原理：
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave；通过对比slave之间I/O线程读取master binlog的位置，选取最接近的slave做为latest slave。
（3）应用差异的中继日志（relay log）到其他的slave；其它slave通过与latest slave对比生成差异中继日志。【这一步是保证所有slave先对齐？】
（4）在最新的slave上应用从master保存的二进制日志事件（binlog events）；
（5）提升一个slave为新的master；
（6）使其他的slave连接新的master进行复制；在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
缺点：
- 需要在各个节点间打通ssh信任，这对某些公司安全制度来说是个挑战，因为如果某个节点被黑客攻破的话，其他节点也会跟着遭殃；
- 高可用依赖于vip（虚拟ip）的方案，譬如采用keepalive来达到vip的切换，但是keepalive会限制切换的主机必须在一个网段，对于跨机房不在一个网段的服务器来说，就无法支持了。
2.MMM
MMM（Master-Master replication manager for MySQL），双主复制，支持双主故障切换和双主日常管理的脚本程序。虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热。MMM无法完全的保证数据一致性，但可最大程度的保证业务可用性。
做到高可用，但由于双主所以无法强一致？
