数据库之MySQL集群方案策略(一)
2020-07-30 16:49 ☆野生架构师☆ 阅读(1869) 评论(0) 编辑 收藏 举报零、为什么需要群集？
在现在的科技环境下，我们的项目中往往会处理越来越多的数据量，随着数据量的递增，单一的数据库已经无法满足我们的业务要求，因此为了解决这一系列的数据库瓶颈，我们有了集群的搭建方案。
一、MySQL版本
引擎对比：
1、myisam没有事务支持
MariaDB针对MyISAM改进，Aria占用空间小，并且允许在系统之间轻松进行复制。
2、innodb提供事务支持，innodb在做任何操作时，会做一个日志操作，便于恢复。
它是MariaDB 10.2（以及MySQL）的默认存储引擎。
3、xtradb是innodb存储引擎的增强版本，拥有更高性能。
MariaDB在10.0.9版本起使用XtraDB来代替MySQL的InnoDB。
在MariaDB 10.1之前XtraDB是最佳选择，它是InnoDB的性能增强分支，并且是MariaDB 10.1之前的默认引擎。
版本对比：
1、Percona提供了高性能XtraDB引擎，还提供了PXC高可用解决方案，并且附带了percona-toolkit等DBA管理工具箱。
2、MariaDB在10.2.6版本里移除Percona XtraDB，换回默认InnoDB，现在10.5默认是InnoDB。
综合多年使用经验和性能对比，首选Percona分支，其次是MariaDB，如果你不想冒险，那就选择MYSQL官方版本。推荐MariaDB
二、Mysql群集方案
方案一：共享存储
一般共享存储采用比较多的是 SAN/NAS 方案。
SAN：共享存储，主库从库用的一个存储。SAN的概念是允许存储设施和解决器（服务器）之间建立直接的高速连接，通过这种连接实现数据的集中式存储。
优点：
1、保证数据的强一致性；
2、与mysql解耦，不会由于mysql的逻辑错误发生数据不一致的情况；
缺点：
1、SAN价格昂贵；
方案二：操作系统实时数据块复制
这个方案的典型场景是 DRBD，DRBD架构(MySQL+DRBD+Heartbeat)
DRDB：这是linux内核板块实现的快级别的同步复制技术。通过各主机之间的网络，复制对方磁盘的内容。当客户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据即可以保证明时同步。
优点：
1、相比于SAN储存网络，价格低廉；
2、保证数据的强一致性；
3、与mysql解耦，不会由于mysql的逻辑错误发生数据不一致的情况；
缺点：
1、对io性能影响较大；
2、从库不提供读操作；
方案三：主从复制架构
单点模式、主备模式、主从模式
单点模式：
单点模式是最简单的单机模式，只有一台数据库服务器，部署最简单。但是存在单点风险，一旦这台服务器挂掉，整个系统也就挂掉了。
主备模式：
为了解决单点模式的风险，主备模式产生。目前，主备模式应该是各个线上服务系统的最低配置了，比如你在各个云平台购买的数据库服务一般都会开启备份功能。一旦主节点出现问题，还可以切换到备份节点，不至于整个系统瘫痪。
主备又分为一主一备、一主多备。多个备份是为了保证更高的安全性，万一主节点出现问题的时候，碰巧备份节点也出问题呢。
当主节点出现问题的时候要切换到备份节点，切换方式又分为手动切换和自动切换。手动切换具有一定的延时，当主节点出现问题时，只能等运维人员发现或者收到系统通知。
主从模式：
主从配置一般都是和读写分离相结合，主服务器负责写数据，从服务器负责读数据，并保证主服务器的数据及时同步到从服务器。
主从模式又分为一主一从、一主多从和多主多从，越往后部署越复杂，同时，系统稳定性更高。主从模式可以更好的分担数据库压力，将插入更新操作和查询操作分开，提高系统整体性能。
架构一、主从复制(一主多从)
架构二、MMM架构(双主多从 Master-Master replication manager for Mysql)
MMM，全称为Master-Master replication manager for Mysql，是一套支持双主故障切换和双主日常管理的脚本程序，MMM使用Perl语言开发。主要用来监控和管理MySQL Master-Master(双)复制。特别适合DBA做维护等需要主从复制的场景，通过双主架构避免了重复搭建从库的麻烦。虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时备选主的预热。
MMM优缺点
优点：
1、高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。
2、自动的主主Failover切换，一般3s以内切换备机
3、多个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实现高可用。
架构三、MHA架构(多主多从 Master High Availability Manager and Toolsfor MySQL)
目前在Mysql高可用方面是一个相对成熟的解决方案。它是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQLReplication 环境，目的在于维持Master主库的高可用性。
MHA优缺点：
优点：
1、自动监控Master故障转移、故障后节点之间的数据同步
2、不会有性能损耗，适用于任何存储引擎
3、具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性
4、可实现同城应用级别双活
5、最大程度上保证数据的一致性
缺点：
1、MHA架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入SQL Proxy。但无论如何都需要改动代码；
2、关于读负载均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可，建议使用LVS；
3、MHA Manager Node 主要负责主库在crash时将bin log完整同步到slave库、监控主备库的状态及切换。
方案四：数据库高可用架构
这种方式比较经典的案例包括 MGR(MySQL Group Replication)和 Galera 等，最近业内也有一些类似的尝试，如使用一致性协议算法，自研高可用数据库的架构等。
1.MGR(MySQL Group Replication，MySQL官方开发的一个实现MySQL高可用集群的一个工具。第一个GA版本正式发布于MySQL5.7.17中)
MGR是基于现有的MySQL架构实现的复制插件，可以实现多个主对数据进行修改，使用paxos协议复制，不同于异步复制的多Master复制集群。
支持多主模式，但官方推荐单主模式：
1、多主模式下，客户端可以随机向MySQL节点写入数据
2、单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理.
优点：
1、基本无延迟，延迟比异步的小很多
2、支持多写模式，但是目前还不是很成熟
3、数据的强一致性，可以保证数据事务不丢失
缺点:
1、仅支持innodb
2、只能用在GTID模式下，且日志格式为row格式
适用的业务场景：
1、对主从延迟比较敏感
2、希望对对写服务提供高可用，又不想安装第三方软件
3、数据强一致的场景
读写负载大问题
读负载大：
1、增加slave
2、加中间层(MyCat，ProxySQL，Maxscale)
3、读写分离
关于写负载大：
1、分库分表
2、增加中间层
2.Galera
方案五：MySQL Cluster和PXC
MySQL Cluster(ndb存储引擎，比较复杂，业界并没有大规模使用)
PXC(Percona XtraDB Cluster)
RXC方案与Replication方案的对比
RXC采用同步复制，事务在所有集群节点要么同时提交，要么不提交
Replication采用异步复制，无法保证数据的一致性
三、常用方案：
目前大多公司目前采用的有三种，PXC，MHA，MGR，MySQL5.6版本的采用MHA，5.7版本的采用MGR。注：所以mysql版本最好在5.7或8.0版本以上
MGR是基于现有的MySQL架构实现的复制插件，可以实现多个主对数据进行修改，使用paxos协议复制，不同于异步复制的多Master复制集群。
支持多主模式，但官方推荐单主模式：
多主模式下，客户端可以随机向MySQL节点写入数据
单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理.
