CentoOS7.9搭建mysql5.7分布式集群+主从复制+读写分离知识整理

一、集群介绍

MySQL的高可用架构无论是社区还是官方，一直在技术上进行探索，这么多年提出了多种解决方案，比如MMM, MHA, NDB Cluster, Galera Cluster, InnoDB Cluster, 腾讯的PhxSQL, MySQL Fabric., aliSQL。

架构方案对比

MySQL Replication架构

MySQL Replication是MySQL非常出色的一个功能，该功能将一个MySQL实例中的数据复制到另一个MySQL实例中。整个过程是异步进行的，但由于其高效的性能设计，复制的延时非常小。多数的集群方案都基于此功能进行设计。

MySQL的复制（replication）是一个异步的复制，从一个MySQLinstace（称之为Master）复制到另一个MySQLinstance（称之Slave）。整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在Master（IO进程）上。

要实施复制，首先必须打开Master端的binarylog（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。复制的基本过程如下：

Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取指定日志指定位置之后的日志信息，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；

Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的某个位置开始往后的日志内容，请发给我”;

Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

结论

功能太单一，不符需求，不考虑。

主从复制原理

根据上图说明mysql的主从复制原理：

（1）、在mysql_master上更新数据，写入二进制日志（Binary log）,并通知存储引擎提交事务

（2）、mysql_slave启用I/O线程将master的binary log复制到slave的中继日志（Relay log），

（3）、mysql_slave启用SQL线程从Relay log中读取事件，并重放其中的事件从而更新slave数据，使其与master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小。

读写分离原理

在主从复制的基础上，master更新数据同步到slave服务器中，master只负责写入数据，slave只提供读取数据，从而实现了数据库性能的优化，以及提升了服务器的安全性。

实现mysql读写分离的方法：

1）基于程序代码内部实现

在代码中根据select 、insert进行路由分类，这类方法也是目前生产环境下应用最广泛的。优点是性能较好，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手。

2）、基于中间代理层实现

代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后转发到，后端数据库，有以下代表性的程序。

（1）mysql_proxy。mysql_proxy是Mysql的一个开源项目，通过其自带的lua脚本进行sql判断。

（2）Atlas。是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。支持事物以及存储过程。

（3）Amoeba。由阿里巴巴集团在职员工陈思儒使用序java语言进行开发，阿里巴巴集团将其用户生产环境下，但是他并不支持事物以及存数过程。

MMM架构

 MySQL-MMM是Master-Master Replication Manager for MySQL（mysql主主复制管理器）的简称，是Google的开源项目（Perl脚本）。

 MMM基于MySQL Replication做的扩展架构，主要用来监控mysql主主复制并做失败转移。其原理是将真实数据库节点的IP（RIP）映射为虚拟IP（VIP）集，在这个虚拟的IP集中，有一个专用于write的IP，多个用于read的IP，这个用于Write的VIP映射着

数据库集群中的两台master的真实IP（RIP），以此来实现Failover的切换，其他read的VIP可以用来均衡读（balance）。

优点：

1、自动的主主Failover切换，一般3s以内切换备机

2、多个Slave读的负载均衡。。

缺点：

1、无法完全保证数据的一致性（在db1宕机过程中，一旦db2落后于db1,这时发生切换，db2变成了可写状态，数据的一致性就无法保证）

2、无论何时，只有一个数据库可写；db1宕机后，write VIP会指向db2，当db1恢复后，db1不会自动变成可写主，需要手动move_role 或者db2宕机。

所以read host要包括db1，不然容易造成浪费；

3、由于是使用虚拟IP浮动技术，类似Keepalived，故RIP（真实IP）要和VIP（虚拟IP）在同一网段；如果是在不同网段也可以，需要用到虚拟路由技术。

4、monitor单点问题，或许可以用keepalived来解决。

结论

 MMM架构在以前非常流行，但现在难免有些落伍，mysql本质上还是已单机模式安装在服务器上，无法方便的横向扩展。不考虑

MHA架构

 MHA（Master High Availability）由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作（以的眼光来说太慢了），并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

某种意义上来说MHA架构是MMM架构的升级版，但是又缺少了vip的功能，一般会配合keepalived使用补完vip的功能。

优点

1、自动监控Master故障转移、故障后节点之间的数据同步

2、不会有性能损耗，适用于任何存储引擎

3、具备自动数据补偿能力，在主库异常崩溃时能够4、最大程度的保证数据的一致性

5、可实现同城应用级别双活

6、最大程度上保证数据的一致性

缺点

1、MHA架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入SQL Proxy。但无论如何都需要改动代码；

2、关于读负载均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可，建议使用LVS；

3、MHA Manager Node 主要负责主库在crash时将bin log完整同步到slave库、监控主备库的状态及切换。

结论：

 最大的问题做读写分离时需要改动代码，与开发耦合太高，不利于当前部署以及后期改造。不考虑。

InnoDB Cluster架构

 MySQL InnoDB集群为MySQL提供了完整的高可用性解决方案。 MySQL Shell包含AdminAPI，使您可以轻松配置和管理一组至少三个MySQL服务器实例，以充当InnoDB集群。 每个MySQL服务器实例都运行MySQL Group Replication，它提供了在InnoDB集群内复制数据的机制，具有内置故障转移功能。Admin API无需在InnoDB集群中直接使用组复制。 MySQL Shell可以根据您部署的集群自动配置自身，将客户端应用程序透明地连接到服务器实例。如果服务器实例意外故障，群集将自动重新配置。在默认的单主模式下，InnoDB集群具有单个读写服务器实例 - 主要实例。多个辅助服务器实例是主要副本的副本。如果主服务器出现故障，则辅助服务器将自动升级为主服务器。MySQL路由器检测到此情况并将客户端应用程序转发到新主服务器。高级用户还可以将群集配置为多主结构。

一般采用MySQL Router、Cluster和MySQL Shell构成的Mysql InnoDB Cluster高可用方案进行搭建

结论：

 InnoDB Cluster支持自动Failover、强一致性、读写分离、读库高可用、读请求负载均衡，横向扩展的特性，是比较完备的一套方案。但是部署起来复杂，想要解决router单点问题好需要新增组件，如没有其他更好的方案暂考虑该方案。

 一般采用MySQL Router、Cluster和MySQL Shell构成的Mysql InnoDB Cluster高可用方案进行搭建

结论：

 InnoDB Cluster支持自动Failover、强一致性、读写分离、读库高可用、读请求负载均衡，横向扩展的特性，是比较完备的一套方案。但是部署起来复杂，想要解决router单点问题好需要新增组件，如没有其他更好的方案暂考虑该方案。

Mycat架构

基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得MYCAT一开始就拥有一个很好的起点。一个彻底开源的，面向企业应用开发的大数据库集群。

功能介绍

支持事务、ACID、可以替代MySQL的加强版数据库

一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群

一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server

结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品

一个新颖的数据库中间件产品

适合数据大量写入的存储需求，不适合大量查询的环境

支持MySQL、Oracle、Sqlserver、Mongodb等

提供数据读写分离服务

提供数据分片服务

基于阿里巴巴Cobar进行研发的开源软件

MYCAT监控

1.支持对Mycat、Mysql性能监控

2.支持对Mycat的JVM内存提供监控服务

3.支持对线程的监控

4.支持对操作系统的CPU、内存、磁盘、网络的监控

在这里插入图片描述

优点

1、Mycat作为主数据库中间件，是与代码弱关联的，所以代码是不用修改的，使用Mycat后，连接数据库是不变的，默认端口是8066。连接方式和普通数据库一样，如：jdbc:mysql://192.168.0.2:8066/

2、自带监控，提供较全面的监控服务

3、可实现数据库的读写分离，在后端的主从复制数据库集群中，通过MYCAT配置，将前台的写操作路由到主数据库中，将读操作路由到从数据库上。

4、MYCAT可以实现读写分离下的读操作负载均衡，将大量的读操作均衡到不同的从库上，主要出现在一主多从情形下。

5、MYCAT可实现数据库的高可用，在数据库主节点可用的情况下，配置一台可写从节点，这两个节点都配置在MYCAT中，当主节点宕机时，MyCAT会自动将写操作路由到备用节点上，但并不支持在切换之后的继续主从同步。

5、当读写分离已经不能满足持续增加的访问量时，MYCAT可实现数据库的垂直拆分，将所有的数据库表按照模块划分，不同类型的表拆分到不同的数据库服务器。

随着业务量的增长，垂直拆分之后如果又出现了数据库性能问题，则需要进行水平切分，这就是俗称的分库分表。将数据量很大的表数据切分到不同的服务器库中，表结构是一样的，而使用MYCAT实现水平切分，对前端应用是完全透明的，不用调整前台逻辑。

缺点

TPS性能低下

最近版本维护越来越少了

总结

 Mycat也并不是配置以后，就能完全解决分表分库和读写分离问题。Mycat配合数据库本身的复制功能，可以解决读写分离的问题，但是针对分表分库的问题，不是完美的解决。或者说，至今为止，业界没有完美的解决方案。

分表分库写入能完美解决，但是，不能完美解决主要是联表查询的问题，Mycat支持两个表联表的查询，多余两个表的查询不支持。 其实，很多数据库中间件关于分表分库后查询的问题，都是需要自己实现的，而且节本都不支持联表查询，Mycat已经算做地非常先进了。分表分库的后联表查询问题，需要通过合理数据库设计来避免。这是一套比较好的数据库集群方案，值得考虑。

PhxSQL

优点

高性能：由于Proxy接管了MySQL Client的请求，为了使整个集群的读写性能接近单机MySQL，Proxy使用协程模型提高自身的处理能力。

Proxy的协程模型使用开源的Libco库。Libco库是微信团队开源的一个高性能协程库，具有以下特点：

用同步方式写代码，实现异步代码的性能。

支持千万级的并发连接。

项目地址/tencent-wechat/libco

完全兼容MySQL：为了已有的应用程序能够不做任何修改就能迁移到PhxSQL，Proxy需兼容MySQL的所有功能。

缺点

MySQL Fabric

 Oracle在5月推出了一套为各方寄予厚望的MySQL产品 – MySQL Fabric，从字面上不太能看出它是啥，但是从名称上还是有迹可循的。fabric是“织物”的意思，这意味着它是用来“织”起一片MySQL数据库。MySQL Fabric是一套数据库服务器场(Database Server Farm)的架构管理系统。

MySQL Fabric是什么？

 MySQL Fabric能“组织”多个MySQL数据库，是应用系统将大于几TB的表分散到多个数据库，即数据分片(Data Shard)。在同一个分片内又可以含有多个数据库，并且由Fabric自动挑选一个适合的作为主数据库，其他的数据库配置成从数据库，来做主从复制。在主数据库挂掉时，从各个从数据库中挑选一个提升为主数据库。之后，其他的从数据库转向新的主数据库复制新的数据。注意：这里说的“自动”是指由MySQL Fabric在后台完成，而不需要用户手动更改配置。最重要的是，MySQL Fabric是GPL的开源软件，也就是在符合GPL的规范下，你可以自由的使用和修改这个软件。

mysql备份

 关于数据的备份，其实是件比较头疼的事，服务器容量有限，不可能存放在磁盘上，幸好项目环境是运行在阿里云的内网环境的云服务器上，可以连接阿里云oss。遂决定采用以下方案：

上传binlog日志至oss

结合crontab设定定时任务，周期的上传文件至oss

上传数据库备份至oss

创建备份用户，在上传日志文件时，同时触发mysqldump 脚本生成sql文件上传至oss

参考文档：

mysql5.7集群方案对比

分布式数据库搭建详细教程

mysql5.7的主从复制+读写分离

Centos7.5基于MySQL5.7的 InnoDB Cluster 多节点高可用集群环境部署记录

集群知识

主从复制

主从复制

主从复制-都是主

NDB Cluster

Amoeba

mycat、maxscale、proxysql

mycat

如果觉得《CentoOS7.9搭建mysql5.7分布式集群+主从复制+读写分离知识整理》对你有帮助，请点赞、收藏，并留下你的观点哦！