方案选型
业界类似方案调研
MySQL集群高可用方案、方式目前有很多种，前期我们广泛考量并调研了以下方案，在技术上做了简单对比，最终选定MHA和PXC进行进一步可行性验证。
1．存储层的HA - DRBD/SAN：存储层块设备同步方案，数据更新频繁，需要专门（相对昂贵）的设备；DRBD在测试阶段出现了性能问题，相对的高成本和性能问题使我们最终放弃。
2．MMM/MHA：目前比较流行的方案，尤其MHA，相对轻量级，可控、可自行修改源代码，但缺乏商业支持，一旦Binary Log补齐出问题导致转接失败则会非常被动，尤其在Slave多的情况下稳定是第一需求。所以在准生产部署实施后选择了放弃。
3．Galera MySQL (PXC/MariaDB Galera Cluster)：有好的商业支持，在性能和HA上平衡得很好。其中PXC的外围工具相对较为成熟，成为了我们最终的选择。
4．MySQL Fabric：刚刚GA不久的产品，功能还在完善中，并且需要结合多主进行使用，不能直接提供想要的HA功能。有Oracle公司的支持，将来或许是个好的产品。
5．MySQL Cluster (NDB)：类似RAC的方案，对网络压力较大，成熟度方面口碑欠佳，业界生产环境使用较少。而且不是乐观锁机制，笔者认为其更适用于少写多读。
锁定PXC
PXC的优势还是显而易见的：
1．Galera的WriteSet协议的乐观锁机制是在性能和可用性上是一个很好的平衡点——比MySQL的同步复制性能更好，比异步复制更能保证数据一致性。当然前提条件是要按照最佳实践正确地使用PXC，合理控制Deadlock的回滚带来的额外成本，或者从根本上慎重考虑是否启用多节点来编写。
2．成熟靠谱的商业支持。在前期，针对公司集群的具体情况，DBA团队和Percona的远程技术工程师一起做了细致完备的准备工作，Percona工程师的技术支持亦高效合理，这一点在后来我们创建更多的技术问题Ticket时也得到进一步验证。
3．因为三节点较好的一致性保证，相比MHA的补差量的方式，PXC造成大面积Slave同步同时中断的可能性较低。由于DBA团队人员相对较少，一旦Slave大面积出现问题时，即使使用自动化脚本，人手也难以应付。因此，能够保证大多数Slave的正常工作是我们现阶段必须时刻考虑的因素。
最终方案
总体上来看，目前主DC的集群建设已经完成并运转正常；跨DC的方案也已经确定并在实施的准备过程中。最终我们要实现的是PXC集群+跨DC的Master-Master同步，可以最小限度地减少对维护窗口的依赖，并最大程度地提高集群可用性。
更多细节如下：
单DC方案：
细节方面请参照后面的讨论。
跨DC方案：
在讨论跨DC方案时，最终我们没有采用单PXC集群跨DC的方式，而是计划采用Master-Master模式，并构建两个PXC集群之间的双主复制关系，这样既可以更好的保证Slave的平滑切换，又可以防止跨DC网络抖动引起的性能问题，甚至是集群脑裂的发生。
PXC从POC到落地需要解决的技术细节
5.5 to 5.6兼容性和升级
Oracle公司确实在MySQL兼容性方面做了很多工作，这里要提的一点是，切记纸上谈兵，要认真做兼容性回归测试之后才能做大面积升级，尤其是对于最重要的和运行次数最多的模块。案例1，在测试一切顺利，大家都认为多此一举的时候，Point Release中的一个重要模块的报错让我们警醒起来，经过仔细排查和分析，出现该问题的根本原因是JDBC Driver在一个GROUP_CONCAT的返回数据类型上有细微的差别，导致报出异常程序停止；案例2，我们的环境中用到的比较老版本的ODBC同样存在5.6兼容性问题，好在这个问题会导致数据直接连接不上，得以在上线前发现并解决。
NIC Bonding还是双网卡分流
由于三节点之间的流量直接决定整个集群的性能，我们曾经考虑让IST/SST/Flow Control/Internal Communication的流量单独使用一块网卡，使其和数据访问隔离分流。虽然最终我们采用万兆网卡Bonding方案，这里仍要提醒大家的是：分流是一个可行方案；并需要注意不要因为网络原因触发Flow Control。
是否启用GTID
最初考虑过不想一次做过多改动，先上PXC然后Enable GTID。但经过仔细考虑，最终决定先上GTID，然后基于GTID上PXC，关键点是：只有启用了GTID才可能有Slave的自动无缝Switch Master。GTID可以保证在不同Master之间，即使Binary Log的文件名和Position不同，但只要逻辑意义上的Transaction点一致就能通过GTID定位，如果没有GTID, Slave从一个Master切换到另外一个Master在技术上虽然仍可行，但需要解析Binary Log，通过Xid定位反推不同Master的不同Binary Log和Position，细节此处不过多讨论，可行但操作相对困难且易错。当在PXC启用GTID时，我们发现GTID中的UUID: xxxx-xxx-xxxx的UUID部分，并不是PXC节点中的任何一个节点的UUID，而是PXC以Bootstrap方式启动时生成的UUID，这一点也需要注意。查阅文档后也得到了验证。
性能VS单点Master
翻阅了官方测试资料，也参考了其它DBA人员的测试结果后，我们还是要结合FreeWheel公司的业务特点做自己的测试，在四种场景下使用Sysbench做的压测对比结果如下：
1．单节点
2．两节点
3．三节点
4．三节点+其中一个节点在做SST全量恢复
TPS (Transaction Per Sec) 越大性能越好。
RTT (Average Response Time) 越小性能越好。
可以看到，在我们单节点写入的各场景下，PXC的性能损失并不大。
利用NSC实现Public VIP和Private VIP的设计
基础架构上FreeWheel有专业的NetScaler设备，也有网络专家支持，在综合各方面的因素之后，最终我们决定大胆启用双VIP的方式，三节点的PXC01/02/03前面挂一个Public VIP: VIP01给所有应用访问使用，01宕机自动转接02，以此类推到03；同时再挂一个Private VIP: VIP01-Private给所有的Slave连接到Master时使用，VIP转接逻辑同上。这里在考虑VIP探活机制上有过几次反复讨论和调整，使用过的方案有：
i.TCP 3306探活，最基础的探测；MySQL hang或者网络特别繁忙、极端情况下容易误判。
ii.MySQL协议层面只读“select 1；”探活；粒度适中，但FC发生时有小概率可能转接到不可写节点。
iii.MySQL心跳表Update写成功探活；会产生不必要的Binary Log记录进而造成GTID的复杂化，这个方式主要用以应对小概率FC场景。
依次尝试下来，最终我们稳定在方案ii作为线上方案。目前一切平稳。
关于横向扩展的考虑
首先要说明，PXC一般来讲是HA方案而并不是Scale Out方案，但实际上如果安排合理，也是可以考虑借力于PXC的。
1．关于读
只要是OLTP的读，尤其是更新的热数据集，在02/03节点的读应该不影响01节点的性能，或者说不伤害整个集群的性能。换言之就是可以提高整个集群的吞吐，毕竟02/03节点只是Standby资源。
2．关于写
不同于读，这里必须考虑不同节点更新数据时的锁冲突问题，一旦WriteSet协议下的二阶段Authentication失败，就会造成一阶段已执行事务回滚，得不偿失。铁律是必须保证不同节点的更新数据没有交集。
3．FreeWheel特有的多Slave扩展的需求
由业务特征决定，我们的一集群目前有几十个Slaves，个别Slave还在第三层复制关系中，三级复制，基本已经达到一个MySQL实例能带动Slave的极限。但是随着业务的增长和新功能的开发，对于Slave的需求还在不断增长，PXC强一致性的三节点给了我们机会，可以顺理成章地在02/03节点上挂接Slave，雪中送炭，极大缓解了DBA小组满足Slave需求的后备方案的压力。
受益于PXC
1．不再担心主节点硬件或者电源问题等的宕机事件：
在Staging环境，由于托管机房的误操作问题，发生过01/02节点的电源被误掉电的情况，令人欣喜的是我们的DBA并没有被Call，第二天上班看监控邮件才发现VIP自动做了切换，一切如常。
2．零宕机前提下硬件/OS层面的变更成为可能：
PXC刚刚上线我们就遇到了内存上的压力，研究后发现同等情况下PXC确实会占用稍高些的内存。没有犹豫，直接进行滚动宕机硬件内存升级，整个集群对外服务零宕机，半个小时一切顺利完成。
3．软件的滚动升级和部分Schema大表更改的滚动更成为可能：
将来，无宕机升级5.7可以采用滚动升级的方式进行；一些类似索引操作或者Schema Default值的更改。
4．提供了可满足大量Slave需求的可能
比如01节点用于写操作，02/03节点用于带Slave，或者其他类似的变通方案，尤其是临时需要生产环境流量的测试Slave需求，可以毫不犹豫地挂接在02或者03上。
5．多读多写的潜在能力：
当对实时性数据读取需求高的应用过多时，我们可以考虑启用02/03作为读节点。当写数据可以在业务上保证无冲突时，同样可以考虑启用02/03节点。