MySQL是一个关系数据库管理系统，由瑞典MySQL AB公司开发，属于Oracle旗下产品。MySQL是最流行的关系数据库管理系统之一，在Web应用方面，MySQL是最好的RDBMS（Relational Database Management System）应用软件之一。
MySQL是开源系统，community（社区）版免费下载应用，但是商业版需要收费。国内电商巨头如淘宝、京东等都是在MySQL开源产品的基础上做了定制开发的。
MySQL商业应用时基本都是集群部署，MySQL集群方案很多，每个方案都有自己的优缺点，需要在不同的应用场景选择适合的集群方案。
MySQL主从复制集群是最经典的集群方案（如图7-38所示），一般采用一主两从或一主多从部署方式。
图7-38 主从复制集群
主从复制的集群方案，一般会做读写分离的处理。来自Web服务器的写操作，都会直接访问主数据库，而读操作直接访问从数据库。
MySQL主从复制是通过重放binlog日志，实现主库数据异步复制到多个从库中（如图7-39所示）。即主库执行的sql命令，通过binlog会在从库同样执行一遍，从而达到主从复制的效果。
主从复制集群的优势如下。
· 如果让后台读操作连接从数据库，让写操作连接主数据库，能起到读写分离的作用，这个时候多个从数据库可以做负载均衡。
· 可以在某个从数据库中暂时中断复制进程来备份数据，这样不影响主数据的对外服务和数据库整体性能。
主从复制集群的缺陷如下。
· 从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
图7-39 MySQL主从复制机制
· 对主库与从库之间的网络速度要求高，若网络延迟太高，将加重上述的滞后效应，造成最终数据的不一致。
· 主节点为单一主机，如果主节点出现故障，集群会整体瘫痪。
二，MHA ClusterMHA（Master High Availability）是在MySQL Replication的基础上进行的优化，目前是一个比较成熟的解决方案，它由日本DeNA公司研发。
MHA是多主多从结构（如图7-40所示），主要提供更多的主节点，需要配合Keepalived等一起使用。要搭建MHA，要求一个复制集群中必须最少有四台数据库服务器，即一台充当Master，一台充当备用Master，另外两台充当从库。
图7-40 MHA架构图
MHA集群方案的优势如下。
· MHA可以进行故障的自动检测和转移，在MySQL节点故障切换过程中，MHA能做到在0～20s内自动完成数据库的故障切换操作。
· 具备自动数据补偿能力，在主库异常崩溃时能够最大限度地保证数据的一致性。
· 解决了主从方案的单点故障问题，使集群的高可用性大大提升（单点故障是指系统中一点失效，就会让整个系统无法运作的缺陷）。
MHA集群方案的劣势如下。
· MHA架构实现了读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入SQL Proxy，但无论如何都需要改动代码。
· MHA没有提供从节点的负载均衡读方案，可以使用F5、LVS、HAPROXY或者SQL Proxy等工具自己实现。
· 需要编写脚本或利用第三方工具来实现VIP的配置。
· MHA启动后只能监控主服务器是否可用，没办法监控从服务器。
· 需要基于SSH免认证登录配置，存在一定的安全隐患。
三，Galera Cluster（PXC）Galera Cluster（集群）是由Codership开发的MySQL多主结构集群（如图7-41所示），这些主节点互为其他节点的从节点。
PXC（Percona Xtradb Cluster）集群是基于Galera Cluster的升级版（如图7-42所示），Percona Server使用XtraDB存储引擎。
PXC在功能和性能上较MHA有着很显著的提升，如提升了在高负载情况下的InnoDB的性能，为DBA提供了一些非常有用的性能诊断工具，另外有更多的参数和命令来控制服务器行为。
图7-41 Galera Cluster
图7-42 PXC Cluster
PXC采用的是多主同步复制，并针对同步复制过程中会大概率出现的事务冲突和死锁进行优化，即复制不是基于MySQL官方的binlog，而是Galera复制插件，重写了wsrep api。
异步复制中，主库将数据更新传播给从库后立即提交事务，而不论从库是否成功读取或重放数据变化。在这种工作模式下，主库事务提交后的短时间内，主库与从库数据并不一致。
同步复制中，主库的单个事务提交需要在所有从库上同步更新。换句话说，当主库提交事务时，集群中所有节点的数据保持一致。
对于读操作，从每个节点读取到的数据都是相同的。对于写操作，当数据写入某一节点后，集群会将其同步到其他节点。
Galera Cluster（PXC）方案的优势如下。
· 客户端可以向任何一台机器进行读写操作，所有服务器的地位相同。
· 查询时从本地节点查找数据，所有数据在本地节点都有，无须远程节点调用。
· 所有节点的写操作都是同步复制的，这可以保证节点数据的强一致性。
· 解决了主从架构数据复制的延迟问题，基本上可以达到实时同步。
· 整个集群具有高可用性，不存在单点故障。任何节点在任意时间失效，都不影响集群的整体运行。
· 故障节点自动从集群中移除，不影响其他节点工作。
· 读查询可以配置负载均衡。
Galera Cluster（PXC）方案的局限性如下。
· Galera集群可以做到数据的强一致性，但这是以牺牲性能为代价的，因此PXC集群的数据写入速度较慢。
· 添加新节点时，需要全部复制已存在节点的数据，如果数据超过100GB，代价会很高。
· 所有节点的数据都是一致的，这导致相同数据的备份太多。
· 应该尽可能地控制PXC集群的规模，因为节点越多，数据同步速度越慢。
· 所有PXC节点的硬件配置要一致，如果不一致，配置低的节点将拖慢数据同步速度。
· 目前的复制仅仅支持InnoDB存储引擎，任何写入其他引擎的表，包
括mysql.表将不会复制，但是DDL语句会被复制，因此创建用户将会被复制，但是insert into mysql.user…将不会被复制。
· DELETE操作不支持没有主键的表，没有主键的表在不同的节点顺序将不同，如果执行SELECT…LIMIT…将出现不同的结果集。
· 在 多 主 环 境 下 LOCK/UNLOCK TABLES 不 支 持 ， 以 及 锁 函 数GET_LOCK()、RELEASE_LOCK()等也不支持。
· 查询日志不能保存在表中，如果开启查询日志，只能保存到文件中。
· 允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义，任何大型操作将被拒绝，如大型的LOAD DATA操作。
· 由于集群是乐观的并发控制，所以事务commit可能在该阶段中止。如果有两个事务向集群中不同节点的同一行写入数据并提交，失败的节点将中止。对于集群级别的中止，集群会返回死锁错误代码
（Error: 1213 SQLSTATE: 40001（ER_LOCK_DEADLOCK））。
· XA事务不支持，因为在提交上可能回滚。
· 整个集群的写入吞吐量由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
· 如果DDL语句出现问题将破坏集群一致性。
· 锁冲突、死锁问题相对更多。使用建议如下。
PXC是以牺牲性能来保证数据的强一致性的，Replication方案在性能上是高于PXC的，所以两者用途也不一致。PXC一般只用于重要的交易数据存储，如订单数据、用户数据等。
四，MGR ClusterMGR（MySQL Group Replication）是MySQL 5.7.17提出的集群方案（如图7-43所示），它既可以很好地保证数据一致性，又具备故障检测和转移功能，MGR还支持多节点写入，这是一项被普遍看好的技术。
图7-43 MGR Cluster
MGR（MySQL Group Replication）是MySQL自带的一个插件，可以灵活部署。MySQL MGR集群是多个MySQL Server节点共同组成的分布式集群，每个Server都有完整的副本，它是基于行（ROW）格式的二进制日志文件。
MGR是一个多主结构，通过组复制（Group Replication）机制实现各节点数据的一致性，这与Replication的异步复制、PXC的同步复制都不相同。
如图7-43所示，DB1、DB2、DB3构成的MGR集群，集群中每个DB都有MGR层，MGR层功能也可简单理解为由Paxos模块和冲突检测Certify模块实现。
Paxos模块基于Paxos算法，确保所有节点收到相同广播消息，Transactionmessage（交易信息）就是广播消息的内容结构；冲突检测Certify（保证）模块进行冲突检测确保数据的最终一致性。
当DB1上有事务T1要执行时，T1对DB1来说是本地事务，对于DB2、DB3来说是远端事务；DB1在事务T1被执行后，会把执行事务T1的信息广播给集群中各个节点，包括DB1本身；通过Paxos模块广播给MGR集群中的各个节点，半数以上的节点同意并且达成共识，之后共识信息进入各个节点的冲突检测Certify模块，各个节点各自进行冲突检测验证，最终保证事务在集群中的最终一致性。
在冲突检测通过之后，本地事务T1在DB1直接提交即可，否则直接回滚。远端事务T1在DB2和DB3分别先更新到relaylog，然后应用到binlog，完成数据的同步，否则直接放弃该事务。
五，NDB ClusterMySQL NDB Cluster与MySQL Server是完全不同的产品，它是使用非共享架构，通过多台服务器构建成集群，实现多节点读写的关系数据库。
它具有在线维护功能，并且可排除单一故障，具有非常高的可用性。此外，它的主要数据保存在内存中，可以高速处理大量的事务，是面向实时性应用程序的一款数据库产品（如图7-44所示）。
图7-44 NDB Cluster
NDB Cluster广泛应用于电信行业，例如阿尔卡特朗讯、诺基亚、NEC等有大量的使用案例。在线游戏行业通过NDB进行会话管理，例如Big FishGames、Blizzard Entertainment、Zynga。
此外，由于NDB具有非常高的可用性，所以在PayPal（贝宝支付）的反欺诈系统中采用了NDB。MySQL NDB Cluster架构按照节点类型分为以下三部分。
· 管理服务器（Management Server）：管理服务器通过对配置文件config.ini的维护来对其他节点进行管理。该文件可以用来配置多少副本需要维护、在数据节点上为数据和索引分配多少内存、数据节点的位置、数据节点上保存数据的磁盘位置、SQL节点的位置信息等，管理节点只能有一个。
· SQL节点（SQL Node）：SQL节点可以理解为应用程序和数据节点的一个桥梁，应用程序不能直接访问数据节点，只能先访问SQL节点，然后SQL节点再去访问数据节点来返回数据。Cluster中可以有多个SQL节点，通过每个SQL节点查询到的数据都是一致的，一般来说，SQL节点越多，分配到每个SQL节点的负载就越小，系统的整体性能就越好。
· 数据节点（Data Node）：数据节点用来存放数据，可有多个数据节点
