MySQL的高可用解决方案的主要目的是为了解决MySQL数据库的可用性。一般来说所谓的高可用性环境为了避免单点故障都会涉及到多台服务器或是多个IDC数据中心，当前来说比前常用的MySQL高可用解决方案包括PXC，mysql ndb cluster,mha 和mmm.这些解决方案都有其各自的特点，那么我们应该如何在众多的高可用解决方案中进行选择呢？我们需要考虑以下一些问题。
首先要考虑的是我们要通过MySQL的高可用架构来解决什么问题？通常情况下使用MySQL的高可用架构我们可以解决以下几方面的问题。
1.在多地区或是机房分别存放数据库的准时实备份.
2.扩展数据库的读/写负载.
3.减少数据库因故障或是计划中的停机维护时间.

那么为了解决我们上面提到的要如何选择高可用解决方案的问题，我们首先又要明确以下几个问题。
你所能容忍多少的数据丢失？
没错，虽然高可用架构的其中一个作用就是为了减少因故障停机的时间，但是意外的停机不可避免的会产生数据的丢失，而不同的高可用架构所可能会产生的数据丢失的数量也不相同，其中mha,mmm由于是其于MySQL异步复制的架构所以可能会比pxc和ndb集群在发生故障时丢失更多的事务。
避免单点故障
上面提到的几种高可用解决方案都可以解决这个问题，但是有一些基于共享存储的高可用方案，虽然MySQL实例可以避免单点但是由于多个实例使用的一同一个共享存储，这样这个共享存储就成了为了一个可能出现故障的单点，比如Oracle的RAC集群就可能会产生这样的问题。
失败转移的方式和所需要的时间
不同的高可用架构在进行失败转移时的方式有所不同，有些支持自动进行故障转移有些则需要由DBA手动进行故障转移。而不同的故障转移方式所需要的时间也不一样，通常来说支持自动故障转移的架构所需要要故障转移时间越短，同样的可以提供的系统的可靠性就越高。MHA/MMM这样的基于MySQL复制的高可用架构在进行故障转移时大约需要30秒的时间，而DRDB等基于磁盘镜像的高可用架构在进行故障转移时则差不多要15到30秒的时间；而相比来说PXC这样的架构则需要相对较少的故障转移时间。
是否需要对读/写负载进行扩展
我们进行高可用架构的另一个目的，可能就是为了对读/写负载时行负载均衡，但是并不是所有架构都可以支持读/写负载的扩展。通常情况下MHA/MMM这样的架构只能对读负载进行扩展而不能对写负载进行扩展。而ndb集群这样的架构则可以同时对读写负载进行扩展。另外，对于单纯的基于共享存储的高可用架构，由于在同一时间只有一个实例可以使用共享存储，所以对于这样的架构来说对读写操作都不能达到扩展负载的目的。

以上就是在我们选择MySQL高可用架构时所要面临的一些问题，如果你对MySQL高可用架构的实现和各自的优缺点有兴趣，还可以听听慕课网的<打造扛得住的MySQL数据库架构>这门课程，相信一定会对你有所帮助。