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