mysql 保存图片二进制_MySQL集群

如有文章侵权请联系删除，欢迎对内容有误处提出意见！

如何解决从节点读数据延迟的问题也是研究的重点，将在下一篇文章中介绍。

一、MySQL集群的优缺点

优点：

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

缺点：

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

二、MySQL集群的解决方案

读写分离、主从复制

应用程序对于数据库而言都是写少读多，这样就可以这样设计：

主库：只负责写数据(写库，DML->insertdeleteupdate)

从库：只负责读数据(读库，select)

这样就可以解决如下问题：

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

三、混合式MySQL集群解决方案

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

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

四、主从复制

1、主从复制原理

1.1 概念：

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

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

MySQL主从复制是一个异步的复制过程，主节点将变更的数据保存在二进制日志中，通过二进制输出线程发送更新数据提醒到从库，从节点通过I/O线程从二进制日志中读取更新的数据，并执行更新记录，使得从节点的内容与主节点保持一致。

1.2 涉及到的线程：

对于每一个主从复制连接，都涉及到三个进程完成：从节点I/O进程、从节点SQL进程、二进制输出进程

二进制输出进程：主节点会生成一个二进制输出进程，用来给从节点的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进程已经从主节点拉取到了已变更的数据并且保存在本地中继日志中，当服务再次起来之后，就可以完成数据的同步。

1.3 主从复制过程描述：

当数据通过主节点去变更数据时(DML操作)，主节点会将更改后的数据记录到二进制日志中，从节点的I/O进程先连接主节点，负责拉取主节点上的二进制日志(此时二进制文件包含了更改后的数据)，I/O进程从主节点拉取二进制日志后，将二进制日志保存到从节点的中继日志中，从节点的SQL进程会对中继日志进行读取，然后在解析后在从节点上面做一个重新的执行，以保证主从节点数据同步更新。

1.4 主从复制用处

• 用于实时性的故障切换
• 读写分离，高并发下更好的利用各个服务器提供查询服务
• 备份，避免影响业务