MySql集群模式

一 MySQL Cluster

1、Cluster的介绍

MySQL Cluster的关键部分--sql node(MySQL Server)、data node(storage或者ndbd)。至于它的结构,我们从图形来进行理解。

下面是最小配置的cluster,使用两台机器:

MySql集群模式_第1张图片

上图有两个数据节点(用于保存持久化数据的)、两个SQL节点(提供给应用程序访问的前端)。

下面是用了五台机器的cluster:

MySql集群模式_第2张图片

上图有三个SQL节点,两个数据节点。每个节点都独自使用一台机器。

2、数据存储的冗余与分布

sql节点不存储数据;数据节点之间可以是冗余数据,也可以是分布存储,即一份数据拆成多份,保存在不同的节点上。见下图:

MySql集群模式_第3张图片

上图表述在4个数据节点的情况下,拆分一个表的存储。左上是一张表,字段是ID、CAPITAL、COUNTRY、UTC。目前MySQL Cluster是根据数据节点的个数,和replica的个数(即冗余的份数),对主键进行HASH,分布存储到各个节点中。每一个组的成员个数与replica的个数相同。

当有数据节点出现宕机情况时,系统仍然可用。如下图:

MySql集群模式_第4张图片

下面是集群的高可用方案:

MySql集群模式_第5张图片

MySql集群模式_第6张图片

上图坏掉了两个数据节点、四个SQL节点、一个管理节点,cluster仍然是“活”的。

3、Cluster的优缺点

l 能运行在普通硬件上,不需要专业的存储设备;

l 一个节点失败不会导致其他节点失败;

l 数据节点和前端(SQL节点)都可以避免单点失效;

l 数据的冗余是同步方式,不像复制采用异步方式;一个数据节点实效,它的备份节点的数据不会与其不一致;

l 不能在线增加和舍弃节点(需要做全备和恢复,需要重启整个cluster);

l 本身不实现动态的负载均衡;

l 管理复杂程度比复制高;

l 目前应用的广泛程度远不及它的复制。

4、Cluster的限制

l 自增长列必须是主键;

l 不支持事务的部分回滚,重复键或者类似的错误会导致整个事务回滚;

l 只支持read committed隔离级别;

l varchar占用与char相同的空间;

l 外键被忽略;

l 保存点被忽略;

l 执行范围扫描时,开销相对昂贵;

l 最大节点数为63;

l 数据节点最多为48;

l 不适宜处理大事务;

l commit时不能保证日志刷新到硬盘;

l delete某个表的数据,释放的空间,只由在同一个表的insert时再被使用,不会被其他表使用;

l 限制比较多,参见官方文档,不一一列出了。

二 MySQL Replication(master+slave)

1、Replication的基本原理

MySQL Replication是两个MySQL服务器之间的异步数据复制。

MySql集群模式_第7张图片

两个MySQL服务器,一个为Master(主),一个为Slave(从)。master开启二进制日志;slave启动一个线程连接master,来不断地获取master的二进制日志,并写到本地的relay binlog文件中;slave启动另一个线程把reIay binlog文件中的日志应用到slave数据库中;master中有一个线程负责与slave通讯,不断的读取二进制日志,并传递给slave。

2、只基于复制的高可用方案

MySql集群模式_第8张图片

slave可以用做master的备份;slave可以分流读操作;备份到其他介质时,可从slave备份,而不增加master的负载。

当master出现问题时:

MySql集群模式_第9张图片

master失效时,通过手工操作,让应用只访问slave。

3、复制(Replication)的优缺点

l slave可以作为master的备份;

l 是异步的,不会给master带来很大的压力,但某些情况下,当master宕掉时,可能有些数据还未复制到slave中去;

l 配置简单;

l master和slave相对独立,建立新的复制关系时不必停机;当其中一方宕机,另一方还可以继续运转;宕机的一方经过恢复后,重新建立复制关系,也不需要正在运转的一方停机;

l 应用广泛,这是MySQL非常成熟的技术,大量的案例都使用了复制;

l slave可以分流数据库读操作,但这需要应用程序分别处理数据库的读和写;

l 可以对slave进行备份,而不影响master;特别是可以lock所有表,然后做文件拷贝,甚至停止slave的MySQL服务,然后做文件拷贝,数据量大时,比mysqldump速度快。

4、复制(Replication)的限制

一个master可以带多个slave;一个slave只能有一个master;slave也同时可以作为master,从而形成链式复制、双向复制、环式复制。但双向复制和环式复制,在官方文档中并不提倡,因为容易产生冲突,冲突之后也没有自动解决的机制。

如下图:

MySql集群模式_第10张图片

三 Mycat实现MySQL集群

1、Mycat概述

Mycat从定义和分类来看,它是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。

MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。而在最终用户看来,无论是那种存储方式,在MyCat里,都是一个传统的数据库表,支持标准的SQL语句进行数据的操作,这样一来,对前端业务系统来说,可以大幅降低开发难度,提升开发速度。

MySql集群模式_第11张图片

Mycat架构图

MySql集群模式_第12张图片

Mycat支持基于MySQL主从复制状态的高级读写分离控制机制

读写分离

读写分离定义

为了确保数据库产品的稳定性,很多数据库拥有双机热备功能。也就是,第一台数据库服务器,是对外提供增删改查业务的生产服务器;第二台数据库服务器,仅仅接收来自第一台服务器的备份数据。一般来说,为了配置方便,以及稳定性,这两台数据库服务器,都用的是相同的配置。

在实际运行中,第一台数据库服务器的压力,远远大于第二台数据库服务器。因此,很多人希望合理利用第二台数据库服务器的空闲资源。

从数据库的基本业务来看,数据库的操作无非就是增删改查这4个操作。但对于“增删改”这三个操作,如果是双机热备的环境中做,一台机器做了这三个操作的某一个之后,需要立即将这个操作,同步到另一台服务器上。出于这个原因,第二台备用的服务器,就只做了查询操作。进一步,为了降低第一台服务器的压力,干脆就把查询操作全部丢给第二台数据库服务器去做,第一台数据库服务器就只做增删改了。

优缺点

优点:合理利用从数据库服务器的空闲资源。

缺点:本来第二台数据库服务器,是用来做热备的,它就应该在一个压力非常小的环境下,保证运行的稳定性。而读写分离,却增加了它的压力,也就增加了不稳定性。因此,读写分离,实质上是一个在资金比较缺乏,但又需要保证数据安全的需求下,在双机热备方案上,做出的一种折中的扩展方案。

更多信息请查看:

https://zhuanlan.zhihu.com/p/30840802

你可能感兴趣的:(数据库,mysql,linux,集群相关,分布式,mysql,数据库,集群,分布式,mycat)