MySql集群模式

缺乏、安全感 2022-05-19 01:13 202阅读 0赞

**一 MySQL Cluster**

**1、Cluster的介绍**

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

下面是最小配置的cluster，使用两台机器：

![v2-64105c0a6d8a141279b16edf8bcf75bd_hd.jpg][]

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

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

![v2-8c7e4efb8508846564c01d002f8c5ba1_hd.jpg][]

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

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

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

![v2-09b2f9e2524e9902d9223ebe84c1cce1_hd.jpg][]

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

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

![v2-ac229b4edf18684ca89210fe5694f0e0_hd.jpg][]

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

![v2-1097530237c7ff5b8c052891e56afd26_hd.jpg][]

![v2-e402ce99ca3c2058c80e787f7a38e9c6_hd.jpg][]

上图坏掉了两个数据节点、四个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服务器之间的异步数据复制。

![v2-6e6c34c13ec4901694a57353ec086cb5_hd.jpg][]

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

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

![v2-138bc211a26e590519ff72a127e8c529_hd.jpg][]

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

当master出现问题时：

![v2-b580a01f5823881c147314706132337c_hd.jpg][]

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，从而形成链式复制、双向复制、环式复制。但双向复制和环式复制，在官方文档中并不提倡，因为容易产生冲突，冲突之后也没有自动解决的机制。

如下图：

![v2-c29f8065e27187ac3fc127c56b67564a_hd.jpg][]

**三 Mycat实现MySQL集群**

**1、Mycat概述**

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

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

![v2-a1217564b1dd515fd0b8555455cb015e_hd.jpg][]

Mycat架构图

![v2-eb61d0cb2eebfc44e80c1a59e3382279_hd.jpg][]

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

读写分离

读写分离定义

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

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

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

优缺点

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

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

更多信息请查看：

[https://zhuanlan.zhihu.com/p/30840802][https_zhuanlan.zhihu.com_p_30840802]

[v2-64105c0a6d8a141279b16edf8bcf75bd_hd.jpg]: /images/20220519/e75302d4eb95433198c6538bea41b7b3.png
[v2-8c7e4efb8508846564c01d002f8c5ba1_hd.jpg]: /images/20220519/ece88b5b564340139b5eed1d0f353ed1.png
[v2-09b2f9e2524e9902d9223ebe84c1cce1_hd.jpg]: /images/20220519/61b13d1bf5b74c6390ed240aa7cb7a3b.png
[v2-ac229b4edf18684ca89210fe5694f0e0_hd.jpg]: /images/20220519/1986332ef64a4d52967fc0c66a8ca104.png
[v2-1097530237c7ff5b8c052891e56afd26_hd.jpg]: /images/20220519/69c6e412557444058e61a432c12ad7a2.png
[v2-e402ce99ca3c2058c80e787f7a38e9c6_hd.jpg]: /images/20220519/47caacd1dce147399a977203d9984ae5.png
[v2-6e6c34c13ec4901694a57353ec086cb5_hd.jpg]: /images/20220519/7604b676233b4315b713b8de4294dc90.png
[v2-138bc211a26e590519ff72a127e8c529_hd.jpg]: /images/20220519/4a5f32a543aa47d69d0d92f1b8c5175a.png
[v2-b580a01f5823881c147314706132337c_hd.jpg]: /images/20220519/d9d46a3f027849d0aa8c78235eabeffe.png
[v2-c29f8065e27187ac3fc127c56b67564a_hd.jpg]: /images/20220519/6e0fe09f48e34859995798de6e8c7e6c.png
[v2-a1217564b1dd515fd0b8555455cb015e_hd.jpg]: /images/20220519/d5ad6f1a8861457aa0b7a4e8ae6d5b3d.png
[v2-eb61d0cb2eebfc44e80c1a59e3382279_hd.jpg]: /images/20220519/0a9f70023675408dac6ec0e6db39be25.png
[https_zhuanlan.zhihu.com_p_30840802]: https://zhuanlan.zhihu.com/p/30840802