mysql常用高可用架构（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