在我们下定决心将企业核心应用从企业级数据库迁移到开源数据库产品、使用本地磁盘代替共享存储之前。我觉得我们必须要面对并回答以下几个问题之后才能真正的将开源进行到底，将想法付诸于实践。下面我们来看一下我们在将OLTP应用迁移到MySQL数据库之上之前，我们必须要回答的几个问题：
(1) 允许在极端情况下备库接管服务后，数据存在暂时的不一致吗（主从架构下在主库 crash 后可能存在部分写操作没有及时同步的备库的问题）？
(2) MySQL数据库在数据库故障时应用服务也将中断 3-30s ，这样的场景是否能够接受？
(3) 我们对数据库的可扩展性、吞吐能力、响应时间及用户体验是否有较高的要求？
只有回答了如上三个问题，以下3类OLTP类型的MySQL架构设计 方案，才能真正的具备可参考性与实际意义。下面我们来扒一扒笔者目前考虑到适合OLTP应用开源解决方案。
方案一、多主同步复制方案PXC
PXC，即Percona Xtradb Cluster，它采用Galera引擎，可以实现多个节点间的数据同步复制以及读写并且可保障数据库的服务高可用及数据一致性。其架构如下所示：
一、 PXC的优点
(1) 数据同步复制
(2) 多个可同时读写节点，但需要事先进行分库分表，让各个节点分别写不同的表或者库
(3) 可以保证数据严格一致性
(4) 适合读多写少的业务系统
二、 PXC的缺点
(1) 不支持XA事务
(2) 集群吞吐量/性能取决于响应最慢的节点，事务效率与主从架构相比低了不止一个数量级
(3) 需要调整
(4) 只支持InnoDB引擎
(5) 所有表都要有主键
(6) 不允许大事务产生
(7) 不支持LOCK TABLE等显式锁操作
(8) 存在写冲突，锁冲突、死锁问题较多，不能解决热点更新问题，可扩展性差
(9) 如果并发事务量很大的话，官方建议采用InfiniBand网络，降低因网络延迟带来的瓶颈
(10) 需要引入多个第三方插件，集成复杂度高
方案二、主从复制方案MHA
MHA即Master High Availability Manager and Tools for MySQL是一个MySQL高可用管理工具，目的在于维持Master主库的高可用性及数据的一致性。其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个Slave数据库作为新的Master，并将其它Slave指向它。
其架构如下，请参考：
一、 MHA的优点
1. 自动监控Master故障转移、故障后节点之间的数据同步
2. 不会有性能损耗，适用于任何存储引擎
3. 具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性
4. 可实现同城应用级别双活
二、 MHA的缺点
1. 如果主服务器硬件故障或无法通过ssh访问，进行故障转移可能导致丢失当前数据
2. 切换时间较长,整个切换时间大约需要9-12s
方案三、主主复制方案MM
利用MySQL原生支持主从单向复制、主主双向复制，该架构解决了主库单点及写瓶颈等问题。 其架构如下，请参考：
一、 MM架构优点
1. 支持快速切换，一般3s之内即可切换到备机
2. 配置管理简单、不需要第三方插件
二、 MM架构缺点
1. 如果数据库服务器硬件故障可能导致丢失当前操作数据
关于以上方案的总结
（一）对于PXC架构，其优点很多但缺点同时也非常的明显，其核心优势就是保证了各节点数据的一致性，劣势就是其在可扩展性、锁冲突、写扩大方面存在问题，PXC为了保证数据的一致性其要求每个节点都要将数据写入到磁盘才算完成，这样就存在一个效率问题。也就是说每个事务的响应时间依赖于整个集群最慢的节点，且其对网络质量要求非常高。另一个问题就是我们需要考虑清楚，我们的开源的方向在哪里？是跟着一个小众分支开源社区Percona，还是跟着主流MySQL官方开源社区发展的问题。
（二）对于MHA架构其优点就是通过MHA插件解决主库的单点问题及因主库挂掉后尽量保证接管的从库与宕机后的主库的数据一致性且数据的同步功能是原生的，其缺点就是在主库故障切换后不能保证数据零丢失，其实这里更准确的说法不应该是数据丢失应该主库与从库数据不一致。
在以下情况MHA可以保证接管后的节点与主库数据时一致性的：
(1) 在不发生硬件故障的情况下是可以从修复后的主库找回数据并由DBA手动补回备库，最终实现数据的一致性；
(2) 若只是数据库故障，MHA具备将所有已落实的数据自动同步到备库从而实现数据的零丢失；
(3) 直接使用MySQL的半同步机制，两阶段提交来保证数据的一致性，这个方法与PXC的实现方式相似
（三）对于MM双主架构其优缺点与MHA相似，都是采用MySQL原生的数据同步机制。不同之处就是MM架构在主故障时切换时间更短，缺点就是产生数据不一致的可能性更多一下。另外在MM架构中我们也可以尝试引入MHA数据补偿工具来尽量降低在主备切换时导致的数据不一致性问题或者直接使用MySQL的半同步机制来保证数据一致性。
(1) 允许在极端情况下备库接管服务后，数据存在暂时的不一致吗（主从架构下在主库 crash 后可能存在部分写操作没有及时同步的备库的问题）？
(2) MySQL数据库在数据库故障时应用服务也将中断 3-30s ，这样的场景是否能够接受？
(3) 我们对数据库的可扩展性、吞吐能力、响应时间及用户体验是否有较高的要求？
只有回答了如上三个问题，以下3类OLTP类型的MySQL架构设计 方案，才能真正的具备可参考性与实际意义。下面我们来扒一扒笔者目前考虑到适合OLTP应用开源解决方案。
方案一、多主同步复制方案PXC
PXC，即Percona Xtradb Cluster，它采用Galera引擎，可以实现多个节点间的数据同步复制以及读写并且可保障数据库的服务高可用及数据一致性。其架构如下所示：
一、 PXC的优点
(1) 数据同步复制
(2) 多个可同时读写节点，但需要事先进行分库分表，让各个节点分别写不同的表或者库
(3) 可以保证数据严格一致性
(4) 适合读多写少的业务系统
二、 PXC的缺点
(1) 不支持XA事务
(2) 集群吞吐量/性能取决于响应最慢的节点，事务效率与主从架构相比低了不止一个数量级
(3) 需要调整
(4) 只支持InnoDB引擎
(5) 所有表都要有主键
(6) 不允许大事务产生
(7) 不支持LOCK TABLE等显式锁操作
(8) 存在写冲突，锁冲突、死锁问题较多，不能解决热点更新问题，可扩展性差
(9) 如果并发事务量很大的话，官方建议采用InfiniBand网络，降低因网络延迟带来的瓶颈
(10) 需要引入多个第三方插件，集成复杂度高
方案二、主从复制方案MHA
MHA即Master High Availability Manager and Tools for MySQL是一个MySQL高可用管理工具，目的在于维持Master主库的高可用性及数据的一致性。其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个Slave数据库作为新的Master，并将其它Slave指向它。
其架构如下，请参考：
一、 MHA的优点
1. 自动监控Master故障转移、故障后节点之间的数据同步
2. 不会有性能损耗，适用于任何存储引擎
3. 具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性
4. 可实现同城应用级别双活
二、 MHA的缺点
1. 如果主服务器硬件故障或无法通过ssh访问，进行故障转移可能导致丢失当前数据
2. 切换时间较长,整个切换时间大约需要9-12s
方案三、主主复制方案MM
利用MySQL原生支持主从单向复制、主主双向复制，该架构解决了主库单点及写瓶颈等问题。 其架构如下，请参考：
一、 MM架构优点
1. 支持快速切换，一般3s之内即可切换到备机
2. 配置管理简单、不需要第三方插件
二、 MM架构缺点
1. 如果数据库服务器硬件故障可能导致丢失当前操作数据
关于以上方案的总结
（一）对于PXC架构，其优点很多但缺点同时也非常的明显，其核心优势就是保证了各节点数据的一致性，劣势就是其在可扩展性、锁冲突、写扩大方面存在问题，PXC为了保证数据的一致性其要求每个节点都要将数据写入到磁盘才算完成，这样就存在一个效率问题。也就是说每个事务的响应时间依赖于整个集群最慢的节点，且其对网络质量要求非常高。另一个问题就是我们需要考虑清楚，我们的开源的方向在哪里？是跟着一个小众分支开源社区Percona，还是跟着主流MySQL官方开源社区发展的问题。
（二）对于MHA架构其优点就是通过MHA插件解决主库的单点问题及因主库挂掉后尽量保证接管的从库与宕机后的主库的数据一致性且数据的同步功能是原生的，其缺点就是在主库故障切换后不能保证数据零丢失，其实这里更准确的说法不应该是数据丢失应该主库与从库数据不一致。
在以下情况MHA可以保证接管后的节点与主库数据时一致性的：
(1) 在不发生硬件故障的情况下是可以从修复后的主库找回数据并由DBA手动补回备库，最终实现数据的一致性；
(2) 若只是数据库故障，MHA具备将所有已落实的数据自动同步到备库从而实现数据的零丢失；
(3) 直接使用MySQL的半同步机制，两阶段提交来保证数据的一致性，这个方法与PXC的实现方式相似
（三）对于MM双主架构其优缺点与MHA相似，都是采用MySQL原生的数据同步机制。不同之处就是MM架构在主故障时切换时间更短，缺点就是产生数据不一致的可能性更多一下。另外在MM架构中我们也可以尝试引入MHA数据补偿工具来尽量降低在主备切换时导致的数据不一致性问题或者直接使用MySQL的半同步机制来保证数据一致性。
