可选的MySQL高可用方案 MySQL的各种高可用方案大多基于以下部署： 基于主从复制； 基于加莱拉协议； 基于NDB引擎；?是基于中间件/代理； 是基于共享存储； 是基于主机高可用；复制的方案，后面是基于Galera的方案，我们将重点关注这两个方案。其他方案在生产中用的不多，简单说一下。 基于主从复制的高可用解决方案 双节点主从+keepalived/heartbeat 一般来说，中小规模采用这种架构是最省事的。 两个节点可以采用简单的单主从模式，或者双主模式，置于同一个VLAN中。主节点故障后，利用keepalived/heartbeat高可用机制快速切换到从节点。 在这个方案中，有几点需要注意： 在使用keepalived作为高可用方案时，两个节点***都设置为BACKUP模式，避免相互抢占导致写入冲突相同的数据到两个节点； 将两个节点的auto_increment_increment（自增初始值）和auto_increment_offset（自增步长）设置为不同的值。其目的是为了避免当master节点意外宕机时，部分binlog可能没有及时复制到slave上应用，导致slave写入的新数据的自增值与原来的master发生冲突.它是交错的；当然，如果有合适的容错机制，可以解决主从自增ID冲突，也可以不做； slave节点服务器配置不要太差，否则更容易造成复制延迟。作为双机热备节点的从服务器，硬件配置不能低于主节点； 如果对延迟问题比较敏感，可以考虑使用MariaDB分支版本，或者直接上线MySQL5.7***版本，使用多线程复制可以大大降低复制延迟； 另一种对复制延迟特别敏感的方案是使用semisyncreplication（所谓的半同步复制）或者后文提到的PXC方案，基本上没有延迟，但是事务的并发性能会损失到一个一定程度，需要综合评估再做决定； keepalived的检测机制需要适当完善。它不能只检查mysqld进程是否存活或MySQL服务端口是否可用。进一步检测数据写入或计算，判断响应时间。如果超过设定的阈值，则可以启动切换机制；当 keepalived最终决定切换时，还需要判断slave的延时。需要提前设定规则，决定直接切换哪种策略，或者延迟等待。直接切换可能会导致一些由于复制延迟而无法查询的数据重复写入； keepalived和heartbeat本身都不能解决脑裂问题，所以在判断服务异常时，可以调整判断脚本，通过补充第三方节点检测来决定是否切换，可以降低脑裂风险大脑问题。?双节点主从+keepalived/心跳方案架构示意图如下所示： 图：MySQL双节点（单向/双向主从复制），使用keepalived实现高可用建筑学。 多节点主从+MHA/MMM 多节点主从，一主多从，或者双主多从都可以。 在这种模式下，可以使用MHA或者MMM来管理整个集群。目前MHA用的最多，首先推荐MHA。最新的MHA也支持了MySQL5.6的GTID模式，这是个好消息。 MHA优势明显：?开源，使用Perl开发，代码结构清晰，二次开发容易； 是一个成熟的方案，MHA在failover时会做更严格的判断，尽量减少数据丢失，保证数据的一致性； 提供了一个通用的框架，可以根据自己的情况进行自定义开发，尤其是判断和切换操作步骤； 支持binlogserver，可以提高binlog传输效率，进一步降低数据丢失的风险。?但是MHA也有一些局限性：?需要在各个节点之间建立ssh信任，这对一些公司的安全系统来说是一个挑战，因为如果一个节点被黑了，其他节点也会受到影响； 提供的脚本有待进一步补充完善。当然，对于一般用途来说已经足够了。 多节点master-slave+etcd/zookeeper 在大规模节点环境下，使用keepalived或者MHA作为MySQL的高可用管理还是有些复杂或者麻烦。 首先，如果那么多节点不被配置服务管理的话，会杂乱无章，切换上线的时候很容易误操作。 在大规模环境下，推荐使用etcd/zookeeper来管理集群，可以实现快速的检测切换和方便的节点管理。 基于Galera协议的高可用解决方案 Galera是Codership提供的多主数据同步复制机制，可以实现多个节点之间的数据同步复制和读写，可以保证数据库服务的高可用和数据一致性性。 基于Galera的高可用解决方案主要包括MariaDBGaleraCluster和PerconaXtraDBCluster（简称PXC）。目前PXC用的比较多。?PXC的架构图如下： （图片来自网络），示意图：底层使用wsrep接口实现多节点间数据的同步复制。 （图片来自网络），示意图：PXC中，节点间的一个数据写入校验/回滚过程。?PXC优势?高服务可用性； 数据同步复制（并发复制），几乎没有延迟； 多个读写节点同时进行，可以实现写扩展，但是提前***分库分表，让每个节点写不同的表或者库，避免galera解决数据冲突； 新节点自动部署，部署操作简单； 数据严格一致，特别适合电商应用；?完全兼容MySQL；?有这么多好处，但也有一些局限性：?只支持InnoDB引擎； 所有的表都必须有一个主键； 锁冲突和死锁问题相对较多； 不支持XA； 集群吞吐量/性能取决于短板；?新节点使用SST成本高； 存在写扩容问题；?如果并发交易量大，建议使用InfiniBand网络，减少网络延迟；?其实使用PXC的主要目的是为了解决数据一致性的问题，而高可用是附带实现的。因为PXC有写扩容和短板效应，并发效率会大大损失，类似于半同步复制机制。 其他高可用解决方案?都是基于NDBCluster的。由于NDB的诸多缺陷和局限性，不建议在生产环境中使用； 是基于共享存储的。此外，共享存储也可能成为新的单点，除非采用基于高速网络的分布式存储，类似RDS的应用场景，架构方案会更复杂，成本可能更高； 基于中间件（Proxy），现在靠谱的代理选择不多，也没有通用的代理，都是有针对性的，比如有的专注于解决读写分离，有的专注于分库分表等，真正好用Proxy一般需要自己开发； 是基于主机高可用，指的是类似RHCS一样，搭建高可用集群后部署MySQL应用的解决方案。老实说，我从来没有真正使用过它，但是从侧面了解到这个方案在生产中使用的并不多，可能是因为一些限制； 以DBA们的聪明才智，肯定还有其他方案知道的也欢迎各位同仁交流。
