mysql集群

MySQL集群的优缺点

优点：

• 某一从节点失效后可快速自动切换。
• 是一种分布式体系结构，没有单点故障。
• 吞吐量高、延迟短。
• 可扩展性强，支持在线扩容。

缺点：

• 不支持外键。
• 占用磁盘空间大、内存占用率高。
• 部署配置很复杂。

1 主从复制集群

主从复制是选取一个mysql数据库作为主库（只负责写数据），然后一个或者多个mysql数据库作为从库（只负责读数据）。将主库的数据单向异步的复制到从库中，使得主库和从库的数据一致。

这样就可以解决如下问题（主从复制用处）：

• 主从分开后，在业务请求高并发时，只在从服务器上执行查询工作，降低主服务器的压力。
• 主从分开后，当主服务器有问题时，可迅速切换到从服务器，不会影响线上环境。
• 备份在从服务器进行，以避免备份期间影响主服务器服务。

主从复值原理：

主节点称为master、从节点称为slave。Binary log叫做二进制日志。relay log叫做中继日志。Data change数据变更。

MySQL默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据。

二进制输出进程：主节点会生成一个二进制输出进程，用来给从节点的I/O进程传二进制日志。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个二进制输出进程，而每个从节点都有自己的I/O进程、SQL进程。

I/O进程：当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的二进制日志。I/O线程接收到主节点二进制输出进程发来的更新之后，保存在本地中继日志relay-log中。

SQL进程：更新内容保存在中继日志中，但是还没有执行，从节点SQL线程负责读取中继日志中的内容，解析后执行，最终保证主从数据的一致性。

为什么需要I/O和SQL两个进程：从节点用I/O进程和SQL进程将拉取更新数据和执行更新数据分成两个独立的任务，可以提高读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点拉取更新的数据，尽管SQL进程此时还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了已变更的数据并且保存在本地中继日志中，当服务再次起来之后，就可以完成数据的同步。

2 主主复制集群

主从复制只能Master往Slave单向异步复制数据，而主主复制则是Master与Slave互相进行数据复制。

主主复制是基于主从复制的，实际上就是在之前的Slave与Master角色互换，在原Master上执行Slave的操作，在原Slave上执行Master的操作。

3 pxc集群

PXC曾经属于一套近乎最完美的mysql高可用集群解决方案(现mgr总体上要优于pxc)，mysql主从复制是异步提交的，一个事务提交到了Master，可能还没有同步到Slave，事务就已经返回了，可能导致Master与Slave数据不一致，数据被丢失。

由于主从复制的弱一致性，所以主从复制不适用于数据可靠性要求比较高的系统，如订单系统。

这类系统适合采用基于同步复制，数据强一致性的pxc集群。

pxc集群主要特点:

• 同步复制
• 任何节点都可以读写
• 数据同步的强一致性

pxc集群使用的端口:

• 3306： mysql服务端口
• 4444： 请求全量同步(SST)端口
• 4567： 数据库节点之间通信端口
• 4568 ：请求增量同步(IST)端口

混合式MySQL集群解决方案

混合式集群现在应用比较广泛，扩展性强。

中间件的目的： 如果没有中间件，应用程序就会直接与多节点数据库相连，开发难度大。如果使用一个中间件也行，但是会对这单一中间件造成负担过大问题。
代理proxy的目的： 可解决多个中间件之间负载不均衡问题，实现负载均衡。
PXC集群架构的目的： 由于主从数据库之间需要进行数据同步，但是很难保证实时同步，这就是所谓的弱一致性，此外，如果同步过程中由于网络等问题就会出现数据丢失等问题，就会导致用户从从数据库中读不到数据。PXC架构就是解决上述问题，PXC提供读写强一致性功能，可以保证数据在任何一个节点写入的同时可立刻同步到其他节点，无延迟。