您的位置：首页 > 财经 > 金融 > Mysql 集群技术

Mysql 集群技术

2025/6/30 7:09:09 来源：https://blog.csdn.net/weixin_61885606/article/details/141435441  浏览:  次   关键词：Mysql 集群技术

目录

一 Mysql 在服务器中的部署方法

1.1 在Linux下部署mysql

1.1.1 安装依赖性：

1.1.2 下载并解压源码包

1.1.3 源码编译安装mysql

1.1.4 部署mysql

二 mysql的组从复制

2.1 配置mastesr

2.2 配置salve

2.3 当有数据时添加slave2

2.4 延迟复制

2.5 慢查询日志

2.6 mysql的并行复制

2.7 原理刨析

三 半同步模式

3.1半同步模式原理

3.2 gtid模式

3.3.启用半同步模式

四 mysql高可用之组复制 (MGR)

4.1 组复制流程

4.2 组复制单主和多主模式

4.3.实现mysql组复制

五 mysql-router（mysql路由）

六 mysql高可用之MHA

6.1.MHA概述

6.2 MHA部署实施

6.2.1 搭建主两从架构

6.2.2安装MHA所需要的软件

6.2.3 配置MHA 的管理环境

6.2.4 MHA的故障切换

6.2.5 为MHA添加VIP功能

一 Mysql 在服务器中的部署方法

在企业中90%的服务器操作系统均为Linux

在企业中对于Mysql的安装通常用源码编译的方式来进行

官网：http://www.mysql.com

1.1 在Linux下部署mysql

1.1.1 安装依赖性：

[root@mysql-node10 ~]# dnf install cmake gcc-c++ openssl-devel \
ncurses-devel.x86_64 libtirpc-devel-1.3.3-8.el9_4.x86_64.rpm rpcgen.x86_64

1.1.2 下载并解压源码包

[root@mysql-node10 ~]# tar zxf mysql-boost-5.7.44.tar.gz
[root@mysql-node10 ~]# cd /root/mysql-5.7.44

1.1.3 源码编译安装mysql

[root@mysql-node10 mysql-5.7.44]# cmake \
-DCMAKE_INSTALL_PREFIX=/usr/local/mysql \ #指定安装路径
-DMYSQL_DATADIR=/data/mysql \ #指定数据目录
-DMYSQL_UNIX_ADDR=/data/mysql/mysql.sock \ #指定套接字文件
-DWITH_INNOBASE_STORAGE_ENGINE=1 \ #指定启用INNODB存储引擎，默认
用myisam
-DWITH_EXTRA_CHARSETS=all \ #扩展字符集
-DDEFAULT_CHARSET=utf8mb4 \ #指定默认字符集
-DDEFAULT_COLLATION=utf8mb4_unicode_ci \ #指定默认校验字符集
-DWITH_BOOST=/root/mysql-5.7.44/boost/boost_1_59_0/ #指定c++库依赖
[root@mysql-node10 mysql-5.7.44]# make -j2 #-j2 表示有几个
核心就跑几个进程
[root@mysql-node10 mysql-5.7.44# make install

1.1.4 部署mysql

二 mysql的组从复制

2.1 配置mastesr

2.2 配置salve

slave:

2.3 当有数据时添加slave2

2.4 延迟复制

延迟复制时用来控制sql线程的，和i/o线程无关

这个延迟复制不是i/o线程过段时间来复制，i/o是正常工作的

是日志已经保存在slave端了，那个sql要等多久进行回放

2.5 慢查询日志

慢查询，顾名思义，执行很慢的查询

当执行SQL超过long_query_time参数设定的时间阈值（默认10s）时，就被认为是慢查询，这个 SQL语句就是需要优化的

慢查询被记录在慢查询日志里

慢查询日志默认是不开启的

如果需要优化SQL语句，就可以开启这个功能，它可以让你很容易地知道哪些语句是需要优化的。

mysql> SHOW variables like "slow%";
+---------------------+----------------------------------+
| Variable_name       | Value                           |
+---------------------+----------------------------------+
| slow_launch_time   | 2                               |
| slow_query_log     | OFF                             |
| slow_query_log_file | /data/mysql/mysql-node1-slow.log |
+---------------------+----------------------------------+
3 rows in set (0.00 sec)

开启慢查询日志

mysql> SET GLOBAL slow_query_log=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> SET long_query_time=4;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES like "long%";
+-----------------+----------+
| Variable_name   | Value   |
+-----------------+----------+
| long_query_time | 4.000000 |
+-----------------+----------+
1 row in set (0.00 sec)
mysql> SHOW VARIABLES like "slow%";
+---------------------+----------------------------------+
| Variable_name       | Value                           |
+---------------------+----------------------------------+
| slow_launch_time   | 2                               |
| slow_query_log     | ON                               | ##慢查询日志开启
| slow_query_log_file | /data/mysql/mysql-node1-slow.log |
+---------------------+----------------------------------+
3 rows in set (0.01 sec)
[root@mysql-node1 ~]# cat /data/mysql/mysql-node1-slow.log     #慢查询日志
/usr/local/mysql/bin/mysqld, Version: 5.7.44-log (Source distribution). started 
with:
Tcp port: 3306 Unix socket: /data/mysql/mysql.sock
Time                 Id Command   Argument

测试慢查询

mysql> select sleep (10);
[root@mysql-node1 ~]# cat /data/mysql/mysql-node1-slow.log
/usr/local/mysql/bin/mysqld, Version: 5.7.44-log (Source distribution). started 
with:
Tcp port: 3306 Unix socket: /data/mysql/mysql.sock
Time                 Id Command   Argument
# Time: 2024-07-29T17:04:07.612704Z
# User@Host: root[root] @ localhost [] Id:     8
# Query_time: 10.000773 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 0
SET timestamp=1722272647;
select sleep (10);

2.6 mysql的并行复制

在slaves中设定
[root@mysql-node2 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
server-id=2
gtid_mode=ON
enforce-gtid-consistency=ON
slave-parallel-type=LOGICAL_CLOCK #基于组提交，
slave-parallel-workers=16 #开启线程数量
master_info_repository=TABLE #master信息在表中记录，默认记录
在/data/mysql//master.info
relay_log_info_repository=TABLE #回放日志信息在表中记录，默认记录
在/data/mysql/relay-log.info
relay_log_recovery=ON #日志回放恢复功能开启
[root@mysql-node2 ~]# /etc/init.d/mysql start
Starting MySQL. SUCCESS!

2.7 原理刨析

三个线程

实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于3 个线程来操作， 一个主库线程，两个从库线程。

        二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时候， 主库可以 将二进制日志发送给从库，当主库读取事件（Event）的时候，会在 Binlog 上加锁，读取完成之 后，再将锁释放掉。

        从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库 的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志 （Relay log）。         从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同 步。

复制三步骤

步骤1：Master将写操作记录到二进制日志（binlog）。

步骤2：Slave将Master的binary log events拷贝到它的中继日志（relay log）；

步骤3：Slave重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化 的，而且重启后从接入点开始复制。

具体操作

1.slaves端中设置了master端的ip，用户，日志，和日志的Position，通过这些信息取得master的认证及 信息

2.master端在设定好binlog启动后会开启binlog dump的线程

3.master端的binlog dump把二进制的更新发送到slave端的

4.slave端开启两个线程，一个是I/O线程，一个是sql线程，

i/o线程用于接收master端的二进制日志，此线程会在本地打开relaylog中继日志，并且保存到本地 磁盘

sql线程读取本地relog中继日志进行回放

5.什么时候我们需要多个slave？

当读取的而操作远远高与写操作时。我们采用一主多从架构

数据库外层接入负载均衡层并搭配高可用机制

2.8 架构缺陷

主从架构采用的是异步机制

master更新完成后直接发送二进制日志到slave，但是slaves是否真正保存了数据master端不会检测

master端直接保存二进制日志到磁盘

当master端到slave端的网络出现问题时或者master端直接挂掉，二进制日志可能根本没有到达slave

master出现问题slave端接管master，这个过程中数据就丢失了

这样的问题出现就无法达到数据的强一致性，零数据丢失

三 半同步模式

3.1半同步模式原理

1.用户线程写入完成后master中的dump会把日志推送到slave端

2.slave中的io线程接收后保存到relaylog中继日志

3.保存完成后slave向master端返回ack

4.在未接受到slave的ack时master端时不做提交的，一直处于等待当收到ack后提交到存储引擎

5.在5.6版本中用到的时after_commit模式，after_commit模式时先提交在等待ack返回后输出ok

3.2 gtid模式

当为启用gtid时我们要考虑的问题

在master端的写入时多用户读写，在slave端的复制时单线程日志回放，所以slave端一定会延迟与 master端

这种延迟在slave端的延迟可能会不一致，当master挂掉后slave接管，一般会挑选一个和master延迟日 志最接近的充当新的master

那么为接管master的主机继续充当slave角色并会指向到新的master上，作为其slave

这时候按照之前的配置我们需要知道新的master上的pos的id，但是我们无法确定新的master和slave之 间差多少

当激活GITD之后

当master出现问题后，slave2和master的数据最接近，会被作为新的master

slave1指向新的master，但是他不会去检测新的master的pos id，只需要继续读取自己gtid_next即可

设置gtid

3.3.启用半同步模式

Slave端打开

测试

模拟故障

四 mysql高可用之组复制 (MGR)

MySQL Group Replication(简称 MGR )是 MySQL 官方于 2016 年 12 月推出的一个全新的高可用与高扩 展的解决方案

组复制是 MySQL 5.7.17 版本出现的新特性，它提供了高可用、高扩展、高可靠的

MySQL 集群服务 MySQL 组复制分单主模式和多主模式，传统的mysql复制技术仅解决了数据同步的问题，

MGR 对属于同一组的服务器自动进行协调。对于要提交的事务，组成员必须就全局事务序列中给定事务 的顺序达成一致

提交或回滚事务由每个服务器单独完成，但所有服务器都必须做出相同的决定

如果存在网络分区，导致成员无法达成事先定义的分割策略，则在解决此问题之前系统不会继续进行， 这是一种内置的自动裂脑保护机制

MGR由组通信系统( Group Communication System ，GCS ) 协议支持

该系统提供故障检测机制、组成员服务以及安全且有序的消息传递

4.1 组复制流程

4.2 组复制单主和多主模式

single-primary mode(单写或单主模式)

单写模式 group 内只有一台节点可写可读，其他节点只可以读。当主服务器失败时，会自动选择新的主 服务器，

multi-primary mode(多写或多主模式)

组内的所有机器都是 primary 节点，同时可以进行读写操作，并且数据是最终一致的。

4.3.实现mysql组复制

初始化

三台机器都做域名解析

10

20

30

测试：

在每个节点都可以完成读写

五 mysql-router（mysql路由）

MySQL Router 是一个对应用程序透明的InnoDB Cluster连接路由服务，提供负载均衡、应用连接故障转移和客户端路 由。

利用路由器的连接路由特性，用户可以编写应用程序来连接到路由器，并令路由器使用相应的路由策略 来处理连接，使其连接到正确的MySQL数据库服务器

Mysql route的部署

六 mysql高可用之MHA

6.1.MHA概述

为什么要用MHA？

Master的单点故障问题

什么是 MHA？

MHA（Master High Availability）是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。

MHA 的出现就是解决MySQL 单点的问题。

MySQL故障切换过程中，MHA能做到0-30秒内自动完成故障切换操作。

MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用。

MHA 的组成

MHA由两部分组成:MHAManager (管理节点) MHA Node (数据库节点),

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

MHA Manager 会定时探测集群中的 master 节点。

当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master， 然后将所有其他的 slave 重新指向新的 master。

MHA 的特点

自动故障切换过程中，MHA从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失

使用半同步复制，可以大大降低数据丢失的风险，如果只有一个slave已经收到了最新的二进制日 志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数 据一致性

目前MHA支持一主多从架构，最少三台服务，即一主两从

故障切换备选主库的算法

1．一般判断从库的是从（position/GTID）判断优劣，数据有差异，最接近于master的slave，成为备选 主。

2．数据一致的情况下，按照配置文件顺序，选择备选主库。

3．设定有权重（candidate_master=1），按照权重强制指定备选主。

（1）默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重，也会失效。 （2）如果check_repl_delay=0的话，即使落后很多日志，也强制选择其为备选主。

MHA工作原理

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群必须最少有3台数据库服务器， 一主二从，即一台充当Master，台充当备用Master，另一台充当从库。

MHA Node 运行在每台 MySQL 服务器上

MHAManager 会定时探测集群中的master 节点

当master 出现故障时，它可以自动将最新数据的slave 提升为新的master

然后将所有其他的slave 重新指向新的master，VIP自动漂移到新的master。

整个故障转移过程对应用程序完全透明。

6.2 MHA部署实施

6.2.1 搭建主两从架构

准备

Master节点中

Slave中

6.2.2安装MHA所需要的软件

在软件中包含的工具包介绍

1.Manager工具包主要包括以下几个工具：
masterha_check_ssh #检查MHA的SSH配置状况
masterha_check_repl #检查MySQL复制状况 
masterha_manger #启动MHA
masterha_check_status #检测当前MHA运行状态
masterha_master_monitor #检测master是否宕机
masterha_master_switch #控制故障转移（自动或者手动）
masterha_conf_host #添加或删除配置的server信息
2.Node工具包 （通常由masterHA主机直接调用，无需人为执行）
save_binary_logs #保存和复制master的二进制日志
apply_diff_relay_logs #识别差异的中继日志事件并将其差异的事件应用于其他的slave
#在MHA中
filter_mysqlbinlog #去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs #清除中继日志（不会阻塞SQL线程）

6.2.3 配置MHA 的管理环境

远程登录权限

免密登录

检测配置：

a）检测网络及ssh免密

b）检测数据主从复制情况

6.2.4 MHA的故障切换

MHA的故障切换过程 共包括以下的步骤：

1.配置文件检查阶段，这个阶段会检查整个集群配置文件配置

2.宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作

3.复制dead master和最新slave相差的relay log，并保存到MHA Manger具体的目录下

4.识别含有最新更新的slave

5.应用从master保存的二进制日志事件（binlog events）

6.提升一个slave为新的master进行复制

7.使其他的slave连接新的master进行复制

master未出现故障手动切换

#在master数据节点还在正常工作情况下 
[root@mysql-mha ~]# masterha_master_switch \
--conf=/etc/masterha/app1.cnf \ #指定配置文件
--master_state=alive \ #指定master节点状态
--new_master_host=172.25.254.20 \ #指定新master节点
--new_master_port=3306 \ #执行新master节点端口
--orig_master_is_new_slave \ #原始master会变成新的slave
--running_updates_limit=10000 #切换的超时时间

检测：

[root@mysql-mha masterha]# masterha_check_repl --conf=/etc/masterha/app1.cnf     Fri Aug 2 18:33:46 2024 - [warning] Global 
configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Aug 2 18:33:46 2024 - [info] Reading application default configuration from 
/etc/masterha/app1.cnf..
Fri Aug 2 18:33:46 2024 - [info] Reading server configuration from 
/etc/masterha/app1.cnf..
Fri Aug 2 18:33:46 2024 - [info] MHA::MasterMonitor version 0.58.
Fri Aug 2 18:33:47 2024 - [info] GTID failover mode = 1
Fri Aug 2 18:33:47 2024 - [info] Dead Servers:
Fri Aug 2 18:33:47 2024 - [info] Alive Servers:
Fri Aug 2 18:33:47 2024 - [info]   172.25.254.10(172.25.254.10:3306)
Fri Aug 2 18:33:47 2024 - [info]   172.25.254.20(172.25.254.20:3306)
Fri Aug 2 18:33:47 2024 - [info]   172.25.254.30(172.25.254.30:3306)
Fri Aug 2 18:33:47 2024 - [info] Alive Slaves:
Fri Aug 2 18:33:47 2024 - [info]   172.25.254.10(172.25.254.10:3306) 
Version=5.7.44-log (oldest major version between slaves) log-bin:enabled
Fri Aug 2 18:33:47 2024 - [info]     GTID ON
Fri Aug 2 18:33:47 2024 - [info]     Replicating from 
172.25.254.20(172.25.254.20:3306)
Fri Aug 2 18:33:47 2024 - [info]     Primary candidate for the new Master 
(candidate_master is set)
Fri Aug 2 18:33:47 2024 - [info]   172.25.254.30(172.25.254.30:3306) 
Version=5.7.44-log (oldest major version between slaves) log-bin:enabled
Fri Aug 2 18:33:47 2024 - [info]     GTID ON
Fri Aug 2 18:33:47 2024 - [info]     Replicating from 
172.25.254.20(172.25.254.20:3306)
Fri Aug 2 18:33:47 2024 - [info]     Not candidate for the new Master (no_master 
is set)
Fri Aug 2 18:33:47 2024 - [info] Current Alive Master: 
172.25.254.20(172.25.254.20:3306)
Fri Aug 2 18:33:47 2024 - [info] Checking slave configurations..
Fri Aug 2 18:33:47 2024 - [info] read_only=1 is not set on slave 
172.25.254.30(172.25.254.30:3306).
Fri Aug 2 18:33:47 2024 - [info] Checking replication filtering settings..
Fri Aug 2 18:33:47 2024 - [info] binlog_do_db= , binlog_ignore_db=
Fri Aug 2 18:33:47 2024 - [info] Replication filtering check ok.
Fri Aug 2 18:33:47 2024 - [info] GTID (with auto-pos) is supported. Skipping all 
SSH and Node package checking.
Fri Aug 2 18:33:47 2024 - [info] Checking SSH publickey authentication settings 
on the current master..
Fri Aug 2 18:33:47 2024 - [info] HealthCheck: SSH to 172.25.254.20 is reachable.
Fri Aug 2 18:33:47 2024 - [info]
172.25.254.20(172.25.254.20:3306) (current master)+--172.25.254.10(172.25.254.10:3306)+--172.25.254.30(172.25.254.30:3306)
Fri Aug 2 18:33:47 2024 - [info] Checking replication health on 172.25.254.10..
Fri Aug 2 18:33:47 2024 - [info] ok.
Fri Aug 2 18:33:47 2024 - [info] Checking replication health on 172.25.254.30..
Fri Aug 2 18:33:47 2024 - [info] ok.
Fri Aug 2 18:33:47 2024 - [warning] master_ip_failover_script is not defined.
Fri Aug 2 18:33:47 2024 - [warning] shutdown_script is not defined.
Fri Aug 2 18:33:47 2024 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

master故障手动切换

#模拟master故障
[root@mysql-node20 mysql]# /etc/init.d/mysqld stop
#在MHA-master中做故障切换
[root@mysql-mha masterha]# masterha_master_switch --master_state=dead --
conf=/etc/masterha/app1.cnf --dead_master_host=192.168.56.12 --
dead_master_port=3306 --new_master_host=192.168.56.11 --new_master_port=3306 --
ignore_last_failover

自动切换

[root@mysql-mha masterha]# rm -fr app1.failover.complete #删掉切换锁文件
#监控程序通过指定配置文件监控master状态，当master出问题后自动切换并退出避免重复做故障切换
[root@mysql-mha masterha]# masterha_manager --conf=/etc/masterha/app1.cnf 
[root@mysql-mha masterha]# cat /etc/masterha/manager.log
#恢复故障节点

恢复故障节点

[root@mysql-node20 mysql]# /etc/init.d/mysqld start
mysql> CHANGE MASTER TO MASTER_HOST='172.25.254.10', MASTER_USER='repl', 
MASTER_PASSWORD='lee', MASTER_AUTO_POSITION=1

清除锁文件

[root@mysql-mha masterha]# rm -rf app1.failover.complete manager.log

6.2.5 为MHA添加VIP功能

#模拟故障
[root@mysql-node10 ~]# /etc/init.d/mysqld stop #关闭主节点服务
[root@mysql-mha masterha]# cat manager.log
#恢复故障主机
[root@mysql-node20 mysql]# /etc/init.d/mysqld start
mysql> CHANGE MASTER TO MASTER_HOST='172.25.254.10', MASTER_USER='repl', 
MASTER_PASSWORD='lee', MASTER_AUTO_POSITION=1
[root@mysql-mha masterha]# rm -rf app1.failover.complete manager.log

版权声明:

本网仅为发布的内容提供存储空间，不对发表、转载的内容提供任何形式的保证。凡本网注明“来源：XXX网络”的作品，均转载自其它媒体，著作权归作者所有，商业转载请联系作者获得授权，非商业转载请注明出处。

我们尊重并感谢每一位作者，均已注明文章来源和作者。如因作品内容、版权或其它问题，请及时与我们联系，联系邮箱：809451989@qq.com，投稿邮箱：809451989@qq.com

最新新闻

热搜词

Python操作Sqlite3 珠海盈致MES系统何以成为制造业数字化转型的智能引擎？ 递归复制文件夹内容 MogoDb监控 网络架构搭建中的 QinQ 与端口安全策略 解决手机每次复制都弹出google的nearby服务-分享到附近的设备

声明：本站所有新闻及新闻图片来源于其他网站，如有侵权，请及时联系我们！

客户服务 | 关于我们 | 版权声明

版权所有：

Copyright 2024 尧图网 All Rights Reserved.QQ:809451989