MYSQL集群技术

小兔会写代码

于 2024-08-25 22:17:20 发布

阅读量389

点赞数 3

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/xx1005906zz/article/details/141416699

版权

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

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

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

1.1 在Linux下部署mysql

1.1.1 安装依赖性：

在redhat9中

dnf install cmake gcc-c++ openssl-devel ncurses-devel.x86_64 rpcgen.x86_64 -y

#其中此软件包是要自己导入的
#libtirpc-devel-1.3.3-8.el9_4.x86_64.rpm
dnf install libtirpc-devel-1.3.3-8.el9_4.x86_64.rpm -y

在redhat7中

dnf install cmake gcc-c++ openssl-devel ncurses-devel.x86_64 -y

#其中此软件包是要自己导入的
#libtirpc-devel-1.3.3-8.el9_4.x86_64.rpm
dnf install libtirpc-devel-1.3.3-8.el9_4.x86_64.rpm -y

1.1.2 下载并解压源码包

#导入从官网下载的mysql的压缩包
#解压
tar zxf mysql-boost-5.7.44.tar.gz

cd mysql-5.7.44/

1.1.3 源码编译安装mysql

cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql -DMYSQL_DATADIR=/data/mysql -DMYSQL_UNIX_ADDR=/data/mysql/mysql.sock -DWITH_INNOBASE_STORAGE_ENGINE=1 -DWITH_EXTRA_CHARSETS=all -DDEFAULT_CHARSET=utf8mb4 -DDEFAULT_COLLATION=utf8mb4_unicode_ci -DWITH_BOOST=/root/mysql-5.7.44/boost/boost_1_59_0/

make -j4  && make install

成功

1.1.4 部署mysql

#生成启动脚本
yum install initscripts-10.11.6-1.el9.x86_64 -y
cd /usr/local/mysql/support-files/
cp mysql.server /etc/init.d/mysqld

#修改环境变量
vim ~/.bash_profile
source ~/.bash_profile

#生成数据目录
useradd -s /sbin/nologin -M mysql
mkdir -p /data/mysql
chown mysql.mysql /data/mysql/

#修改配置文件
vim /etc/my.cnf

#数据库初始化建立mysql基本数据
mysqld --initialize --user=mysql
 /etc/init.d/mysqld start
mysql_secure_installation   #nnyyyy

然后就可以登录数据库了，也可以使用。

二、mysql的组从复制

2.1 配置mastesr

vim /etc/my.cnf

#重启
/etc/init.d/mysqld restart

#进入数据库中
mysql -uroot -p

#在数据库中
CREATE USER 'repl'@'%' IDENTIFIED BY 'gxx';         ##生成专门用来做复制的用户，此用户是用于slave端做认证用

GRANT REPLICATION SLAVE ON *.* TO repl@'%';         ##对这个用户进行授权

SHOW MASTER STATUS;                                 ##查看master的状态

2.2 配置salve

vim /etc/my.cnf

#重启
/etc/init.d/mysqld restart

#进入数据库中
mysql -uroot -p

#在数据库中
CHANGE MASTER TO
MASTER_HOST='172.25.254.10',MASTER_USER='repl',MASTER_PASSWORD='gxx',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=350;

#MASTER_LOG_POS=350这个参数可能主机不一样会变化，要注意查看是多少，才能连接上。

#布置完，启动
start slave;

#查看
SHOW SLAVE STATUS\G;

确保这两个是yes就是连接成功。

测试

#在master数据库中

#创建表
CREATE DATABASE gxx;

CREATE TABLE gxx.userlist (
-> username varchar(20) not null,
-> password varchar(50) not null
-> );

#写入数据
INSERT INTO gxx.userlist VALUE ('hhn','zeb');

SELECT * FROM gxx.userlist;


#在slave中查看数据是否有同步过来
SELECT * FROM gxx.userlist;

master中

slave测试

2.3 当有数据时添加slave2

#重启
/etc/init.d/mysqld restart
#从master节点备份数据
mysqldump -uroot -pgxx gxx > gxx.sql
注意

生产环境中备份时需要锁表，保证备份前后的数据一致
mysql> FLUSH TABLES WITH READ LOCK;
备份后再解锁
mysql> UNLOCK TABLES;
mysqldump 命令备份的数据文件，在还原时先 DROP TABLE ，需要合并数据时需要删除此语句

2.4 延迟复制

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

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

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

当 master 端误操作，可以在 slave 端进行数据备份

# 在 slave 端

测试：

在 master 中写入数据后过了延迟时间才能被查询到

2.5 慢查询日志

慢查询，顾名思义，执行很慢的查询
当执行SQL超过long_query_time参数设定的时间阈值（默认10s）时，就被认为是慢查询，这个SQL语句就是需要优化的
慢查询被记录在慢查询日志里
慢查询日志默认是不开启的
如果需要优化SQL语句，就可以开启这个功能，它可以让你很容易地知道哪些语句是需要优化的。

开启慢查询日志

2.6 mysql的并行复制

查看 slave 中的线程信息

默认情况下 slave 中使用的是 sql 单线程回放

在 master 中时多用户读写，如果使用 sql 单线程回放那么会造成组从延迟严重

开启 MySQL 的多线程回放可以解决上述问题

在 slaves 中设定

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

#在master端和slave端开启gtid模式

3.3.启用半同步模式

在 master 端配置启用半同步模式

在 slave 端开启半同步功能

3.4.测试

在 master 端写入数据

模拟故障：

# 在 slave 端

# 在 master 端插入数据

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

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

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

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

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

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

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

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

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

4.1 组复制流程

首先我们将多个节点共同组成一个复制组，在执行读写（ RW ）事务的时候，需要通过一致性协议层（Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里 “ 大多数人 ” （对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于（N/2+1 ），这样才可以进行提交，而不是原发起方一个说了算。而针对只读（RO ）事务则不需要经过组内同意，直接提交即可

4.2 组复制单主和多主模式

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

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

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

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

4.3.实现mysql组复制

在master中

#先删除/data/mysql/中的文件内容
rm -rf /data/mysql/*

#初始化密码
mysqld --user=mysql --initialize

#启动
/etc/init.d/mysqld start

mysql -uroot -p初始化后生成的密码

如果觉得登录麻烦可以使用

#在数据库中布置登录
ALTER USER 'root'@'localhost' IDENTIFIED BY 'gxx';

#就可以直接使用mysql -pgxx登录

在slave1/2中也是如此

先删除文件夹内的内容

rm -rf /data/mysql/*

#初始化密码
mysqld --user=mysql --initialize

#启动
/etc/init.d/mysqld start

mysql -uroot -p初始化后生成的密码

在三台的数据库中配置最终会得出

五、mysql-router（mysql路由）

MySQL Router

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

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

5.1Mysql route的部署方式

#安装mysql-router
rpm -ivh mysql-router-community-8.4.0-1.el7.x86_64.rpm

#配置mysql-router
vim /etc/mysqlrouter/mysqlrouter.conf
[routing:ro]
bind_address = 0.0.0.0
bind_port = 7001
destinations = 172.25.254.10:3306,172.25.254.20:3306,172.25.254.30:3306
routing_strategy = round-robin
[routing:rw]
bind_address = 0.0.0.0
bind_port = 7002
destinations = 172.25.254.30:3306,172.25.254.20:3306,172.25.254.10:3306
routing_strategy = first-available

#启动
systemctl start mysqlrouter.service

测试

六、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 节点中

在slave1/2中

首先是slave1

在slave2中也一样（我就不放截图了）

6.2.2安装MHA所需要的软件

#在MHA中
yum install *.rpm -y
在MySQL1/2/3中

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

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

filter_mysqlbinlog # 去除不必要的 ROLLBACK 事件（ MHA 已不再使用这个工具）

purge_relay_logs #清除中继日志（不会阻塞 SQL 线程）

6.2.3 配置MHA 的管理环境

1.生成配置目录和配置文件

生成配置文件

编辑配置文件

#创建密钥

#保持互通

检测网络及ssh免密

检测数据主从复制情况

在数据节点master端（允许root远程登陆）

# 执行检测

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数据节点还在正常工作情况下

检测：

master故障手动切换

模拟 master 故障

在 MHA-master 中做故障切换

恢复故障 mysql 节点

测试一主两从是否正常

6.2.5为MHA添加VIP功能

模拟故障

#MySQL1
/etc/init.d/mysqld stop

[root@mysql-mha masterha]# cat manager.log

恢复故障主机

[root@mysql2 mysql]# /etc/init.d/mysqld start

mysql> CHANGE MASTER TO MASTER_HOST='172.25.254.10',MASTER_USER='repl',MASTER_PASSWORD='gxx', MASTER_AUTO_POSITION=1；

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