数据库之MySQL集群方案策略(一) - ☆野生架构师☆

时间:2024-04-17 16:37:39

数据库之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)

    可参考:MySQL-MMM实现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数据库集群MHA上线实施方案

    目前在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版本以上  

  PXC
    PXC是Percona公司的(Percona XtraDB Cluster) 简称PXC。它是基于Galera协议的高可用集群方案。可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据强一致性。
  MHA
    MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。
  MGR
    MySQL官方推荐的一款高可用集群方案MySQL Group Replication,基于Paxos协议的状态机复制,彻底解决了基于传统的异步复制和半同步复制中数据一致性问题无法保证的情况,也让MySQL数据库涉及的领域更广,打开互联网金融行业的大门。    

    MGR是基于现有的MySQL架构实现的复制插件,可以实现多个主对数据进行修改,使用paxos协议复制,不同于异步复制的多Master复制集群。

    支持多主模式,但官方推荐单主模式:

    多主模式下,客户端可以随机向MySQL节点写入数据

    单主模式下,MGR集群会选出primary节点负责写请求,primary节点与其它节点都可以进行读请求处理.

推荐 PXC 或者 MGR方案,但根据自身实际情况来定。
其实要不是系统遗留原因,我更愿意推荐postgresql,mysql有点乱,多个引擎,多个版本,会造成不必要的麻烦。
当时在做云南汽车信息网数据库选型的时候,就从oracle、db2、mssql2000、mysql、postgresql中就选中postgresql,在项目中运行非常稳定,而又足够先进,当时车型数据库存所有的车型和大量图片,可惜08年从公司出来后就再没机会用它。