MySQL MHA架构、原理、应用场景等

MySQL高可用，顾名思义就是当MySQL主机或服务发生任何故障时能够立马有其他主机顶替其工作，并且最低要求是要保证数据一致性。因此，对于一个MySQL高可用系统需要达到的目标有以下几点：

• 数据一致性保证--这个是最基本的同时也是前提，如果主备的数据不一致，那么切换就无法进行，当然这里的一致性也是一个相对的，但是要做到最终一致性。
• 故障快速切换--当master故障时这里可以是机器故障或者是实例故障，要确保业务能在最短时间切换到备用节点，使得业务受影响时间最短。
• 简化日常维护--通过高可用平台来自动完成高可用的部署、维护、监控等任务，能够最大程度的解放DBA手动操作，提高日常运维效率。
• 统一管理--当复制集很多的情况下，能够统一管理高可用实例信息、监控信息、切换信息等。
• 高可用的部署--要对现有的数据库架构无影响，如果因为部署高可用，需要更改或者调整数据库架构则会导致成本增加。

MySQL MHA

MHA是一位日本MySQL大牛用Perl写一套MySQL故障切换方案，来保证数据库系统的高可用，在宕机的事件内(通常10-30秒)，完成故障转意，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署架构。

MHA(Master HA)为MySQL主从复制架构提供了automating master failover 功能。MHA在监控到master节点故障时，会提升其中拥有最新数据的slave节点成为新的master节点，在此期间，MHA会通过与其它从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。

应用场景

一主多从的环境下，MySQL的主从复制是异步或是半同步。

Master发生故障的时候，有可能一部分(或者全部)的Slave未能获取到最新的binlog，造成Slave之间的binlog转发发生偏差。

如下图所示，Master宕机之后，id=102的binlog未能被发送到任何一个Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id=101的binlog

MySQL高可用，顾名思义就是当MySQL主机或服务发生任何故障时能够立马有其他主机顶替其工作，并且最低要求是要保证数据一致性。因此，对于一个MySQL高可用系统需要达到的目标有以下几点：

• 数据一致性保证--这个是最基本的同时也是前提，如果主备的数据不一致，那么切换就无法进行，当然这里的一致性也是一个相对的，但是要做到最终一致性。
• 故障快速切换--当master故障时这里可以是机器故障或者是实例故障，要确保业务能在最短时间切换到备用节点，使得业务受影响时间最短。
• 简化日常维护--通过高可用平台来自动完成高可用的部署、维护、监控等任务，能够最大程度的解放DBA手动操作，提高日常运维效率。
• 统一管理--当复制集很多的情况下，能够统一管理高可用实例信息、监控信息、切换信息等。
• 高可用的部署--要对现有的数据库架构无影响，如果因为部署高可用，需要更改或者调整数据库架构则会导致成本增加。

MySQL MHA

MHA是一位日本MySQL大牛用Perl写一套MySQL故障切换方案，来保证数据库系统的高可用，在宕机的事件内(通常10-30秒)，完成故障转意，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署架构。

MHA(Master HA)为MySQL主从复制架构提供了automating master failover 功能。MHA在监控到master节点故障时，会提升其中拥有最新数据的slave节点成为新的master节点，在此期间，MHA会通过与其它从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。

应用场景

一主多从的环境下，MySQL的主从复制是异步或是半同步。

Master发生故障的时候，有可能一部分(或者全部)的Slave未能获取到最新的binlog，造成Slave之间的binlog转发发生偏差。

如下图所示，Master宕机之后，id=102的binlog未能被发送到任何一个Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id=101的binlog

（编辑：玉林站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!