mysql 单机和集群学习比较

叁歲伎倆 2022-07-14 14:42 242阅读 0赞

前一阵应公司领导需要，要我做个mysql关于集群的学习报告，因为时间比较短暂，所以做的很多方面都没有涉及到

mysql根据应用场景的不同，可以分为单机版和集群版

**单机单****实例**：

只提供一个服务，一个端口，应用场景：针对小型系统，常用单机单实例

优点：结构简单易维护，人员、设备资源成本较低

缺点：容易出现故障，故障恢复时间长，易达到性能瓶颈;MySQL对多核CPU利用率低

**单机多实例**：

是指在一台物理的PC服务器上运行多个MySQL数据库实例。

优点：

1.节省成本，如果可以缩减机器的数量，考虑到节省电力和机房使用的成本，比单机单实例的方案更便宜。

2.充分利用资源，提升利用率，将MySQL实例绑定在不同的CPU节点，不仅提高了CPU利用率，同时解决了MySQL对多核CPU的利用率问题。

**单机遇到的问题：**

一：升级过程繁琐，机器切换会使服务暂时中断，并造成原有计算资源的浪费

二：越往高端的服务器，所花费的代价越大；

三：一旦该服务器或应用软件失效，会导致整个服务的中断。

**集群**

集群（Cluster）技术是指一组相互独立的计算机，利用高速通信网络组成一个计算机系统，每个群集节点（即集群中的每台计算机）都是可以自主运行的一个独立服务器。这些服务器可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据，并以单一系统的模式加以管理

优点：性能有较高的提升，可用性和可扩展性提高，能处理更多的事物。

缺点：可能借助第三方软件，导致维护成本比较高，存储成本较高。

**集群特点：**

高可用性HAC（Highavailability cluster）：

通过增加系统冗余来提供高可用服务，特点是当系统中如果服务节点发生故障，后备的节点可以迅速的接替故障节点提供服务，故障节点维修返回之后作为当前节点的后备节点，最大限度的保证集群中服务的可用性，这类系统一般用在对系统可靠性有高的要求的领域，比如银行、电信等等

负载均衡集群LBC(load  balance cluster)：

利用一个集群中多台单机，类似并行地提供服务，通常没有采用负载均衡的情况下，用户请求越多，造成处理排队或者网络拥塞，导致请求的响应变慢，机器的性能表现变差，负载均衡集群保证集群中任意节点都能响应用户的请求，这样用户发出服务请求后，根据负载均衡策略将请求分发至集群中的某一节点，客观的提高了系统的可用性和稳定性。

高性能HPC（Highperformance cluster）：

利用一个集群中的多台机器共同完成同一件任务，例如map-reduce系统，每个子节点完成一部分任务，使得整体上完成任务的速度更快、可靠性更高，集群作为一个集体表现出强劲的性能，该集群应用比较广泛，包括天气预报、航天、资源勘探等计算量大，计算复杂的环境。

**常见集群：**

**双机热****备**

就是使用两台服务器，互相备份，共同执行同一服务。当一台服务器出现故障时，可以由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务。

分类：

active/active模式

**active/active****模式**  
是指两台机都是同时工作，有真正做到负载均衡的作用

借图如下：

![Center][]

![Image 1][]![Image 1][]![Image 1][]

**active/standby****模式**

是指单纯的一台机器在跑流量，另一台机器实时地同步数据库，一旦主机宕机，备机立刻进入工作状态。

![Image 1][]![Image 1][]![Center 1][]

**Keepalived+lvs+mysql主主复制**

是比较常用的一种Mysql高可用方案，其中lvs 提供读负载均衡，Keepalived通过虚拟vip漂移实现故障自动转移，而Mysql虽然配置成主主复制，但是一般都是采用单点写入来保证数据一致性。

整个方案实现非常简单，仅需两台服务器即可，安装配置也相对简单，但需要自己写脚本实现keepalived服务的开启和关闭。（图摘自网络）

![Image 1][]![Center 2][]

优点：

l 实现方便，高可用效率好，可以根据服务与系统的可用性多方面进行切换。

l 可以将写VIP和读VIP分别进行设置，为读写分离做准备。

l 扩展很方便。可以在后面添加多个从服务器，并做到负载均衡。

缺点：

l安装配置比单写入稍微复杂，需要另外一个VIP。管理比单写入复杂。

l会出现脑裂问题： （脑裂问题解释：脑裂（split-brain），指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。）

**MySQL Cluster**

MySQLCluster 实际上是在无共享存储设备的情况下实现的一种完全分布式数据库系统，其主要通过NDBCluster（简称NDB）存储引

擎来实现。不仅仅具有高可用性，而且可以自动切分数据，冗余数据等高级功能。

MGM：管理节点负责管理其他节点的配置

NDB节点：这类节点用于保存Cluster的数据。NDB 节点主要是实现底层数据存储功能，来保存Cluster的数据。有一个非常重要的参数叫NoOfReplicas，这个参数指定了每一份数据被冗余存储在不同节点上面的份数

SQL节点：也就是我们常说的MySQLServer。主要负责实现一个数据库在存储层之上的所有事情，比如连接管理，这是用来访问Cluster数据的节点。（图片来源于网络）

![Image 1][]![Center 3][]

**NDB节点：**

来自任何给定表的行都会以透明化方式被拆分成多个分区/片段。在每个片段中会包含一个单独数据节点，负责保留全部数据内容并处理指向该数据的所有读取及写入操作。每个数据节点还拥有一套搭档体系，二者共同构成一个节点组; 搭档节点中保存有该数据片段的辅助副本，但同时也拥有着自己的主片段。MySQLCluster利用两步式提交协议实现数据同步，从而确保当某项事务被提交之后、所引发的变更将被同时存储在两个数据节点当中。

在默认情况下，表的主键会被作为分片键使用，而MySQLCluster将对该分片键执行MD5散列处理、从而选择需要保存哪个片段/分区。如果某一事务或者查询需要访问来自多个数据节点的数据，那么其中一个数据节点会充当事务协调方的角色，并将具体工作分配给其它相关数据节点; 接下来访问结果会得到整合，并最终提供给应用程序。

优点：

a) 99.999%的高可用性

b)快速的自动失效切换，NDB集群不需要依赖第三方组件

c)灵活的分布式体系结构，没有单点故障

d)高吞吐量和低延迟

缺点：

a)存在很多限制，比如：不支持外键

b)部署、管理、配置很复杂

**MHA**

MHA（MasterHigh Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。

（1）.10-30s实现masterfailover（9-12s可以检测到主机故障，7-10s可以关闭主机，再用很短的时间应用差异日志）

（2）部署简单，无需对现有M-S结构做任何改动（至少3台，保证切换后仍保持M-S结构）

（3）. 支持手动在线切换（主机硬件维护），downtime几乎很短0.5-2s

（4）. 保证故障切换后多从库数据的一致性

（5）. 完全自动化的failover及快速复制架构恢复方案（一主多从）

（6）. 恢复过程包括：选择新主库、确认从库间relaylog差异、新主库应用必要语句、其他从库同步差异语句、重新建立复制连接

![Center 4][]

**具体结构：**

该软件由两部分组成：MHAManager（管理节点）和MHANode（数据节点）

MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。

MHA  Node 运行在每台 MySQL 服务器上， MHAManager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master ，然后将所有其他的 slave 重新指向新的 master 。

![Image 1][]

MHA的工作原理

（1）从宕机崩溃的master保存二进制日志事件（binlogevents）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relaylog）到其他的slave；

（4）应用从master保存的二进制日志事件（binlogevents）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

问题：

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL5.5的半同步复制(master只保证slaves中的一个操作成功，就返回，其他slave不管。)，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

**补充：半同步复制（****Semisynchronous****replication****）**介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relaylog中才返回给客户端

![Image 1][] ![Center 5][]

因为时间原因，暂时就整理了这些，后续还将补充

[Center]: /images/20220714/01ac746b3925439fb5f16880817f16ba.png
[Image 1]: 
[Center 1]: /images/20220714/38dd07b482a94257a2ccb357aa0dccdf.png
[Center 2]: /images/20220714/febb38d0e0b04cd8b330f35640cb3f58.png
[Center 3]: /images/20220714/10b76af72f91460dbe740bb312b8c764.png
[Center 4]: /images/20220714/52452ca839fb4153bd3b56b8177550cb.png
[Center 5]: /images/20220714/fe9703a6cd2b451fb4dd20a8f7f16d68.png