那么啥是MySQL集群技术捏

Mysql 集群技术

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

在企业中90%的服务器操作系统均为Linux
在企业中对于Mysql的安装通常用源码编译的方式来进行
官网：http://www.mysql.com

1.1 在Linux下部署mysql

1.1.1 安装依赖性：

[root@mysql1 ~]# yum install  cmake gcc-c++ openssl-devel ncurses-devel.x86_64 rpcgen.x86_64

1.1.2 下载并解压源码包

[root@mysql1 ~]# wget https://downloads.mysql.com/archives/get/p/23/file/mysql-boost-5.7.44.tar.gz

[root@mysql1 ~]# tar zxf mysql-boost-5.7.44.tar.gz

1.1.3 源码编译安装mysql

[root@mysql1 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@mysql1 mysql-5.7.44]# make -j4					#-j4 表示有几个核心就跑几个进程
[root@mysql1 mysql-5.7.44]# make install

1.1.4 部署mysql

生成启动脚本

修改环境变量

vim ~/.bash_profile
export PATH=$PATH:/usr/local/mysql/bin
source ~/.bash_profile

生成数据目录

修改配置文件

datadir=/data/mysql					#指定数据目录
socket=/data/mysql/mysql.sock		#指定套接字
symbolic-links=0					#数据只能存放到数据目录中，禁止链接到数据目录

数据库初始化建立mysql基本数据

[root@mysql1 ~]#mysqld --initialize --user=mysql
[root@mysql1 ~]#/etc/init.d/mysqld start
[root@mysql1 ~]#chkconfig mysqld on

初始化会有临时密码记得保存(最后一行root@localhost:后)
安全初始化

[root@mysql1 ~]：# mysql_secure_installation
Enter password for user root: 		#输入你保存的密码
New password:						#输入新密码
Re-enter new password: 				#重复密码
Press y|Y for Yes, any other key for No: no #是否启用密码插件
Change the password for root ? ((Press y|Y for Yes, any other key for No) : no						#是否要重置密码
后面全是yes

二 mysql的组从复制

2.1原理

在master上：

主服务器上的所有更改操作（如INSERT、UPDATE、DELETE等）都会记录在二进制日志中（binlog）。这个日志文件记录了所有对数据库数据的修改操作，是主从复制的基础。

当有从服务器（Slave）连接请求数据时，主服务器会创建一个Dump线程，用于读取二进制日志，并将日志内容发送给从服务器。

在slave上：

从服务器会创建一个I/O线程，向主服务器请求二进制日志的内容。I/O线程接收来自主服务器的Dump线程发送的日志数据，并将其写入到从服务器的中继日志（Relay Log）中。从服务器上还有一个SQL线程，这个线程负责读取中继日志中的事件，并在从服务器上执行这些事件，从而实现数据的同步。

2.2 配置mastesr

2.3 配置salve

测试

[root@mysql1 ~]# mysql -plee
mysql> CREATE DATABASE lee;
Query OK, 1 row affected (0.00 sec)
mysql> CREATE TABLE lee.userlist (
-> username varchar(20) not null,
-> password varchar(50) not null
-> );
Query OK, 0 rows affected (0.02 sec)
mysql> INSERT INTO lee.userlist VALUE ('lee','123');
Query OK, 1 row affected (0.02 sec)
mysql> SELECT * FROM lee.userlist;
+----------+----------+
| username | password |
+----------+----------+
| lee | 123 |
+----------+----------+
1 row in set (0.00 sec)

在slave中查看数据是否有同步过来

2.4 当有数据时添加slave2

新建172.25.254.30

[root@mysql3 ~]# /etc/init.d/mysqld restart

[root@mysql3 ~]# mysql -uroot -plee -e "create database lee;"
[root@mysql3 ~]# mysql -uroot -p lee <lee.sql
[root@mysql3 ~]# mysql -uroot -plee -e "select * from lee.userlist;"

测试：

2.5 延迟复制

延迟复制时用来控制sql线程的，和i/o线程无关
这个延迟复制不是i/o线程过段时间来复制，i/o是正常工作的
是日志已经保存在slave端了，那个sql要等多久进行回放
当master端误操作，可以在slave端进行数据备份

#在slave端
mysql> STOP SLAVE SQL_THREAD;
mysql> CHANGE MASTER TO MASTER_DELAY=60;
mysql> START SLAVE SQL_THREAD;
mysql> SHOW SLAVE STATUS\G;
Master_Server_Id: 1
Master_UUID: db2d8c92-4dc2-11ef-b6b0-000c299355ea
Master_Info_File: /data/mysql/master.info
SQL_Delay: 60 ##延迟效果
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more
updates
Master_Retry_Count: 86400

2.6 慢查询日志

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

mysql> SET GLOBAL slow_query_log=ON;	#开启慢日志
mysql> SET long_query_time=4;
mysql> SHOW VARIABLES like "long%";
mysql> SHOW VARIABLES like "slow%";
cat /data/mysql/mysql-node1-slow.log	#查询慢日志

2.7 mysql的并行复制

查看slave中的线程信息
默认情况下slave中使用的是sql单线程回放
在master中时多用户读写，如果使用sql单线程回放那么会造成组从延迟严重
开启MySQL的多线程回放可以解决上述问题

[root@mysql1 ~]# /etc/init.d/mysql start

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模式
vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce-gtid-consistency=ON
symbolic-links=0
[root@mysql1 ~]# /etc/init.d/mysqld restart

vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
server-id=2
log-bin=mysql-bin
gtid_mode=ON
enforce-gtid-consistency=ON
symbolic-links=0
[root@mysql2 ~]# /etc/init.d/mysqld restart

vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
server-id=3
log-bin=mysql-bin
gtid_mode=ON
enforce-gtid-consistency=ON
symbolic-links=0
[root@mysql3 ~]# /etc/init.d/mysqld restart

#停止slave端
[root@mysql2 ~]# mysql -p
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
[root@mysql3 ~]# mysql -p
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)

#开启slave端的gtid
mysql> CHANGE MASTER TO MASTER_HOST='172.25.254.10', MASTER_USER='repl',
MASTER_PASSWORD='lee', MASTER_AUTO_POSITION=1;
mysql> start slave;
mysql> show slave status\G;

3.3.启用半同步模式

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

#安装半同步插件
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
#查看插件情况
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
-> FROM INFORMATION_SCHEMA.PLUGINS
-> WHERE PLUGIN_NAME LIKE '%semi%';

在slave端进行同样操作

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 组复制流程

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

4.2 组复制单主和多主模式

single-primary mode(单写或单主模式)
单写模式 group 内只有一台节点可写可读，其他节点只可以读。当主服务器失败时，会自动选择新的主服务器。
multi-primary mode(多写或多主模式)
组内的所有机器都是 primary 节点，同时可以进行读写操作，并且数据是最终一致的。

4.3.实现mysql组复制

[root@mysql ~]#rm -fr /data/mysql/

[root@mysql1~]# mysqld --user=mysql --initialize
[root@mysql1 ~]# /etc/init.d/mysqld start
[root@mysql1 ~]# mysql -uroot -p初始化后生成的密码 -e "alter userroot@localhost identified by 'lee';"

#配置sql
[root@mysql1 ~]# mysql -plee
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'lee';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='lee' FOR CHANNEL
'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.00 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (2.19 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;

复制配置文件到myql-node20和mysql-node30

scp /etc/my.cnf root@172.25.254.20:/etc/my.cnf

#修改mysql2和mysl3中的配置
rm -fr /data/mysql/

20上

30上

```java
#20和30上配置sql
[root@mysql2 ~]# mysql -plee
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'lee';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='lee' FOR CHANNEL
'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.00 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (2.19 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;

测试
在另外两个节点执行与主节点一致操作

五 mysql-router（mysql路由）

MySQL Router
是一个对应用程序透明的InnoDB Cluster连接路由服务，提供负载均衡、应用连接故障转移和客户端路由。
利用路由器的连接路由特性，用户可以编写应用程序来连接到路由器，并令路由器使用相应的路由策略来处理连接，使其连接到正确的MySQL数据库服务器
Mysql route的部署方式
我们需要在所有的数据库主机之外再开一台主机mysql-router

配置mysql-router

测试

#建立测试用户
mysql> CREATE USER lee@'%' IDENTIFIED BY 'lee';
mysql> GRANT ALL ON lee.* TO lee@'%';
#查看调度效果
[root@mysql2 ~]# watch -1 lsof -i :3306
mysql -ulee -plee -h 172.25.254.10 -P 7001

六 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 搭建主两从架构

mysql -p
mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'lee';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
Query OK, 0 rows affected (0.02 sec)
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
Query OK, 0 rows affected (0.00 sec)

#在slave1和slave2中
/etc/init.d/mysqld stop
# rm -fr /data/mysql/*
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
server-id=1
log-bin=mysql-bin
gtid_mode=ON
log_slave_updates=ON
enforce-gtid-consistency=ON
symbolic-links=0

6.2.2安装MHA所需要的软件

#在MHA中
unzip MHA-7.zip

在软件中包含的工具包介绍
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.生成配置目录和配置文件
 masterha_manager --help
Usage:
masterha_manager --global_conf=/etc/masterha_default.cnf #全局配置文件，记录
公共设定
--conf=/usr/local/masterha/conf/app1.cnf #不同管理配置文件，记录各自配
置
See online reference
(http://code.google.com/p/mysql-master-ha/wiki/masterha_manager) for
details.

因为我们当前只有一套主从，所以我们只需要写一个配置文件即可
rpm包中没有为我们准备配置文件的模板
可以解压源码包后在samples中找到配置文件的模板文件

[root@mysql-mha ~]# mkdir /etc/masterha
[root@mysql-mha MHA-7]# tar zxf mha4mysql-manager-0.58.tar.gz
[root@mysql-mha MHA-7]# cd mha4mysql-manager-0.58/samples/conf/
[root@mysql-mha conf]# cat masterha_default.cnf app1.cnf >
/etc/masterha/app1.cnf
#编辑配置文件
[root@mysql-mha ~]# vim /etc/masterha/app1.cnf
[server default]
user=root #mysql管理员用户，因为需要做自动化配置
password=lee #mysql密码
ssh_user=root #ssh远程登陆用户
repl_user=repl #mysql主从复制中负责认证的用户
repl_password=lee #mysql主从复制中负责认证的用户密码
master_binlog_dir= /data/mysql #二进制日志目录
remote_workdir=/tmp #远程工作目录
#此参数使为了提供冗余检测，方式是mha主机网络自身的问题无法连接数据库节点，应为集群之外的主机
secondary_check_script= masterha_secondary_check -s 172.25.254.10 -s
172.25.254.11
ping_interval=3 #每隔3秒检测一次
#发生故障后调用的脚本，用来迁移vip
# master_ip_failover_script= /script/masterha/master_ip_failover
#电源管理脚本
# shutdown_script= /script/masterha/power_manager
#当发生故障后用此脚本发邮件或者告警通知
# report_script= /script/masterha/send_report
#在线切换时调用的vip迁移脚本，手动
# master_ip_online_change_script= /script/masterha/master_ip_online_change
manager_workdir=/etc/masterha #mha工作目录
manager_log=/var/etc/masterha/manager.log #mha日志
[server1]
hostname=172.25.254.10
candidate_master=1 #可能作为master的主机
check_repl_delay=0 ##默认情况下如果一个slave落后master 100M的relay logs的话
#MHA将不会选择该slave作为一个新的master
#因为对于这个slave的恢复需要花费很长时间
#通过设置check_repl_delay=0
#MHA触发切换在选择一个新的master的时候将会忽略复制延时
#这个参数对于设置了candidate_master=1的主机非常有用
#因为这个候选主在切换的过程中一定是新的master
[server2]
hostname=172.25.254.20
candidate_master=1 #可能作为master的主机
check_repl_delay=0
[server3]
hostname=172.25.254.30
no_master=1 #不会作为master的主机

2.检测配置：

[root@mysql-mha ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf
Fri Aug 2 16:57:41 2024 - [warning] Global configuration file
/etc/masterha_default.cnf not found. Skipping.
Fri Aug 2 16:57:41 2024 - [info] Reading application default configuration from
/etc/masterha/app1.cnf..
Fri Aug 2 16:57:41 2024 - [info] Reading server configuration from
/etc/masterha/app1.cnf..
Fri Aug 2 16:57:41 2024 - [info] Starting SSH connection tests..
Fri Aug 2 16:57:42 2024 - [debug]
Fri Aug 2 16:57:41 2024 - [debug] Connecting via SSH from
root@172.25.254.10(172.25.254.10:22) to root@172.25.254.20(172.25.254.20:22)..
Fri Aug 2 16:57:41 2024 - [debug] ok.
Fri Aug 2 16:57:41 2024 - [debug] Connecting via SSH from
root@172.25.254.10(172.25.254.10:22) to root@172.25.254.30(172.25.254.30:22)..
Fri Aug 2 16:57:41 2024 - [debug] ok.
Fri Aug 2 16:57:42 2024 - [debug]
Fri Aug 2 16:57:41 2024 - [debug] Connecting via SSH from
root@172.25.254.20(172.25.254.20:22) to root@172.25.254.10(172.25.254.10:22)..
Warning: Permanently added '172.25.254.10' (ECDSA) to the list of known hosts.
Fri Aug 2 16:57:42 2024 - [debug] ok.
Fri Aug 2 16:57:42 2024 - [debug] Connecting via SSH from
root@172.25.254.20(172.25.254.20:22) to root@172.25.254.30(172.25.254.30:22)..
Warning: Permanently added '172.25.254.30' (ECDSA) to the list of known hosts.
Fri Aug 2 16:57:42 2024 - [debug] ok.
Fri Aug 2 16:57:43 2024 - [debug]
Fri Aug 2 16:57:42 2024 - [debug] Connecting via SSH from
root@172.25.254.30(172.25.254.30:22) to root@172.25.254.10(172.25.254.10:22)..
Warning: Permanently added '172.25.254.10' (ECDSA) to the list of known hosts.
Fri Aug 2 16:57:42 2024 - [debug] ok.
Fri Aug 2 16:57:42 2024 - [debug] Connecting via SSH from
root@172.25.254.30(172.25.254.30:22) to root@172.25.254.20(172.25.254.20:22)..
Warning: Permanently added '172.25.254.20' (ECDSA) to the list of known hosts.
Fri Aug 2 16:57:42 2024 - [debug] ok.
Fri Aug 2 16:57:43 2024 - [info] All SSH connection tests passed successfully.

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 #切换的超时时间

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
--ignore_last_failover 表示忽略在/etc/masterha/目录中在切换过程中生成的锁文件

恢复故障mysql节点

[root@mysql-node20 tmp]# /etc/init.d/mysqld start
Starting MySQL. SUCCESS!
[root@mysql-node20 tmp]# mysql -p
mysql> CHANGE MASTER TO MASTER_HOST='172.25.254.10', MASTER_USER='repl',
MASTER_PASSWORD='lee', MASTER_AUTO_POSITION=1;
mysql> show slave\G
#测试一主两从是否正常
[root@mysql-mha masterha]# masterha_check_repl --conf=/etc/masterha/app1.cnf
Fri Aug 2 20:15:29 2024 - [info] Checking replication health on 172.25.254.20..
Fri Aug 2 20:15:29 2024 - [info] ok.
Fri Aug 2 20:15:29 2024 - [info] Checking replication health on 172.25.254.30..
Fri Aug 2 20:15:29 2024 - [info] ok.
Fri Aug 2 20:15:29 2024 - [warning] master_ip_failover_script is not defined.
Fri Aug 2 20:15:29 2024 - [warning] shutdown_script is not defined.
Fri Aug 2 20:15:29 2024 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

自动切换

[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-mha ~]# ls
master_ip_failover master_ip_online_change MHA-7 MHA-7.zip
[root@mysql-mha ~]# cp master_ip_failover master_ip_online_change
/usr/local/bin/
[root@mysql-mha ~]# chmod +x /usr/local/bin/master_ip_*
#修改脚本在脚本中只需要修改下vip即可
[root@mysql-mha ~]# vim /usr/local/bin/master_ip_failover
my $vip = '172.25.254.100/24';
my $ssh_start_vip = "/sbin/ip addr add $vip dev eth0";
my $ssh_stop_vip = "/sbin/ip addr del $vip dev eth0";
[root@mysql-mha ~]# vim /usr/local/bin/master_ip_online_change
my $vip = '172.25.254.100/24';
my $ssh_start_vip = "/sbin/ip addr add $vip dev eth0";
my $ssh_stop_vip = "/sbin/ip addr del $vip dev eth0";
my $exit_code = 0;
[root@mysql-mha masterha]# masterha_manager --conf=/etc/masterha/app1.cnf & 启动监
控程序
[root@mysql-node10 tmp]# ip a a 172.25.254.100/24 dev eth0 #在master节点添加VIP

模拟故障

[root@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='lee', MASTER_AUTO_POSITION=1
[root@mysql-mha masterha]# rm -rf app1.failover.complete manager.log

手动切换后查看vip变化

[root@mysql-mha masterha]# masterha_master_switch --conf=/etc/masterha/app1.cnf
--master_state=alive --new_master_host=172.25.254.10 --new_master_port=3306 --
orig_master_is_new_slave --running_updates_limit=10000
[root@mysql1 ~]# ip a