【MySQL】高可用

说明

高可用对于互联网应用基本上是标配，目的是最大程度的为用户提供服务，避免因为服务器宕机等意外故障而终止服务。相比于无状态服务（如前后端应用），数据库服务的高可用问题更为复杂，不仅仅是能访问，更需要保证其数据的正确性。

在考虑数据库高可用架构时，需要考虑以下问题：

• 数据库服务器如果发生宕机或者意外中断等故障，能够尽快恢复数据库服务的可用性，减少停机时间
• 用作备份、只读副本等功能的非主节点应该与主节点的数据实时或者最终保持一致
• 当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务

方案

主从复制

MySQL主从复制是目前使用较为广泛的“读”高可用解决方案，官方原生支持，技术比较成熟，配置也不复杂，能够有效缓解数据库读写压力，很大程度上可以解决中小型网站的数据库压力瓶颈问题。

MySQL主从复制采用典型的Master-Slave架构，Slave从Master处同步数据来保证主从数据一致。通过修改配置文件，可以设置同步粒度，如特定数据库，甚至是数据库中的某一张表。

主从复制主要涉及binlog、I/O、SQL三个线程。

• binlog：Master进程，将数据更改写入二进制日志文件（Binary log）
• I/O：Slave进程，从Master服务器读取二进制日志文件，写入Slave的中继日志（Relay log）
• SQL：Slave进程，读取中继日志，执行其中的SQL语句

优点：

• 成本低，部署简单
• 可以作为一种备份机制，相当于热备份，保障数据安全
• 可以实现读写分离，Master上写数据，Slave上读数据，有效提高数据库读写性能

缺点：

• Master可能出现单点故障问题，写数据仍然不是高可用
• 数据一致性问题（同步延迟）

双主复制

主从复制存在“写”单点故障问题，为了保障“写”的高可用，可以采用双主互备的方式。

两台Master都可以读写，互为主备，采用Keepalive等方案实现高可用（使用VIP对外提供服务），默认只有一台（MasterA）负责数据写入，另一台（MasterB）备用。双主复制解决了主从复制的单点写故障问题，可以一定程度保障Master的高可用，一台Master宕机后，可以在极短时间内自动切换到另一台Master。

缺点：

• 资源利用率只有50%，高可用就是通过冗余实现，二者不可兼得
• 两台Master双写同步，数据可能冲突（如自增id同步冲突），需要解决冲突

MHA

MHA(Master High Availability)由日本程序员yoshinorim开发，目前在MySQL高可用方面是一个相对成熟的解决方案，在10-30秒之间可以自动完成数据库的故障切换，最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA主要包含Manager和Node两个组件：

• Node组件要部署到所有的MySQL服务器上。
• Manager组件通常单独部署在一台独立机器上来管理多个master/slave组，包含有主节点（Master）监控、故障转移等管理程序。

Manager会定时探测集群中Master节点，当Master故障时，它可以自动将包含最新数据的Slave提升为新的Master，然后让所有其他的Slave重新指向新Master，整个故障转移过程对应用程序完全透明。

MySQL Cluster

MySQL Cluster是官方提供的集群高可用解决方案，但是依赖于NDB存储引擎，如果使用InnoDB存储引擎（大多数情况）则无法发挥出集群的优势。

参考资料

1. Chapter 16 Replication
2. 五大常见的MySQL高可用方案
3. 浅淡MySQL集群高可用架构
4. MySQL高可用架构之MHA
5. yoshinorim/mha4mysql-manager