一、Mysql 在服务器中的部署方法
在Linux下部署mysql
安装依赖性
[root@mysql ~]# yum install cmake gcc-c++ openssl-devel ncurses-devel.x86_64 libtirpc-devel-1.3.3-8.el7_4.x86_64.rpm rpcgen.x86_64 -y
下载并解压源码包
[root@mysql ~]# tar -zxf mysql-boost-5.7.44.tar.gz
源码编译安装mysql
[root@mysql 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 mysql-5.7.44]# make -j4 #-j2 表示有几个核心就跑几个进程
然后make install
[root@mysql mysql-5.7.44]# make install
注意过程不能有报错
MySQL安装及初始化
生成启动脚本
[root@mysql ~]# cd /usr/local/mysql/support-files/
[root@mysql support-files]# cp mysql.server /etc/init.d/mysqld
修改环境变量
生成数据目录
修改配置文件
[root@mysql ~]# cat /etc/my.cnf
[mysqld]
datadir=/data/mysql #指定数据目录
socket=/data/mysql/mysql.sock #指定套接字
symbolic-links=0 #数据只能存放到数据目录中，禁止链接到数据目录
数据库初始化建立mysql基本数据
数据库安全初始化
[root@mysql ~]# mysql_secure_installation
二、MySQL的主从复制
MySQL 主从复制是一种常用的数据库架构技术，它可以实现数据的备份、负载均衡和高可用性。在 MySQL 主从复制中，一个主数据库（Master）将数据变更同步到多个从数据库（Slave），从而实现数据的冗余和分布式处理。
主从复制的原理
- 主数据库将数据变更记录到二进制日志（Binary Log）中。
- 从数据库连接到主数据库，并请求读取二进制日志。
- 主数据库将二进制日志发送给从数据库。
- 从数据库将接收到的二进制日志应用到自己的数据库中，从而实现数据的同步。
主从复制的配置步骤
-
配置主数据库
- 开启二进制日志功能。
- 设置唯一的服务器 ID。
- 创建用于从数据库连接的用户，并授予复制权限。
-
配置从数据库
- 设置唯一的服务器 ID。
- 指定主数据库的连接信息，包括主机名、端口号、用户名和密码。
- 启动从数据库的复制线程。
主从复制的应用场景
-
数据备份
- 从数据库可以作为主数据库的备份，当主数据库出现故障时，可以快速切换到从数据库，保证数据的可用性。
-
负载均衡
- 可以将读操作分发到多个从数据库上，从而减轻主数据库的负载，提高系统的性能。
-
高可用性
- 通过配置多个从数据库，可以实现主数据库的故障转移，提高系统的可用性。
master
slave
重启数据库
master
slave
master开启二进制日志
重启数据库
进入数据库配置用户权限
master
mysql> create user repl@'%' identified by '123456'; #生成专门用来做复制的用户，此用户是用于slave端做认证用
mysql> grant replication slave on *.* to repl@'%'; #对这个用户进行授权
mysql> show master status; #查看master的状态 
slave
mysql> change master to master_host='172.25.254.128',master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=595;
mysql> start slave;
mysql> show slave status\G;
在slave阶段中默认情况下是开启了写功能的，但是建议关闭slave节点的写功能来保证数据一致性
测试
master
slave
当有数据时添加mysql-node2
添加一个新节点mysql-node2 安装数据库并进行相关的配置
生产环境中备份时需要锁表，保证备份前后的数据一致mysql> FLUSH TABLES WITH READ LOCK;备份后再解锁mysql> UNLOCK TABLES;mysqldump 命令备份的数据文件，在还原时先 DROP TABLE ，需要合并数据时需要删除此语句
从master节点备份数据
[root@mysql ~]# mysqldump -uroot -p tc > tc.sql
将备份的数据传输到新的节点上
[root@mysql ~]# scp tc.sql root@172.25.254.153:/mnt/
利用master节点中备份出来的tc.sql在mysql-node2中拉平数据
[root@mysql-node2 ~]# mysql -uroot -p123456 -e"create database tc;"
[root@mysql-node2 mnt]# mysql -uroot -p123456 tc < tc.sql
mysql> change master to master_host='172.25.254.128',master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=1499;
master插入数据
mysql-node2（原始数据在，新插入的数据也在）
延迟复制
在slave端
mysql> stop slave sql_thread;
mysql> change master to master_delay=60;
mysql> start slave sql_thread;
mysql> show slave status\G;
测试一下
mysql-node2（等一分钟后）
慢查询日志
开启慢查询日志
mysql> set global slow_query_log=on;
MySQL主从复制缺陷
MySQL 主从复制架构存在以下一些缺陷：
数据一致性问题
-
主从延迟
- 在主库写入数据后，从库可能需要一定时间才能同步完数据。如果应用在此时读取从库，可能会得到旧的数据，导致数据不一致。例如，在一些对数据实时性要求很高的业务场景中，如金融交易系统，这种延迟可能会带来严重的问题。
- 造成主从延迟的原因有很多，比如从库的硬件性能比主库差、网络延迟高、主库写入压力大等。
-
复制中断后的不一致
- 如果主从复制过程中出现网络故障、从库宕机等情况，导致复制中断，在恢复复制后，可能会出现数据不一致的情况。此时需要进行数据修复，这是一个复杂且可能存在风险的过程。
故障切换问题
-
自动切换的复杂性
- 虽然可以通过一些工具实现主从复制架构下的自动故障切换，但这个过程并不简单。需要考虑如何检测主库故障、如何选择新的主库、如何保证切换过程中的数据一致性等问题。
- 例如，在一些高并发的系统中，故障切换可能会导致短暂的服务中断，影响用户体验。
-
脑裂问题
- 在某些情况下，可能会出现两个节点都认为自己是主库的情况，即脑裂。这会导致数据的混乱和不一致，修复起来也非常困难。
性能瓶颈
-
单主库的写入瓶颈
- 所有的写入操作都必须在主库上进行，当写入压力很大时，主库可能会成为性能瓶颈。即使有多个从库分担读负载，但主库的写入性能仍然可能无法满足业务需求。
- 例如，在一些大型电商平台的促销活动期间，数据库的写入量会大幅增加，主库可能无法承受这么大的压力。
-
从库的复制压力
- 从库在进行数据复制时也会消耗一定的系统资源，如果从库数量过多或者主库写入量过大，从库可能会因为复制压力过大而影响其读性能。
三、MySQL的并行复制
在slaves中设定
四、MySQL半同步模式
MySQL 的半同步复制模式是在传统异步复制和全同步复制之间的一种折衷方案，其主要目的是在一定程度上保证数据的强一致性，同时尽量减少对性能的影响。以下是其原理
基本概念
在传统的异步复制中，主库将事务写入 binlog 日志后，就可以向客户端返回成功响应，而不必等待从库接收并应用这些日志。这可能导致在主库发生故障切换到从库时，从库丢失一些尚未复制的事务。
全同步复制则要求主库在将事务写入 binlog 日志后，必须等待所有从库都接收并应用完这些日志后，才能向客户端返回成功响应。这种方式虽然能保证数据的强一致性，但会极大地影响主库的性能，特别是在从库数量较多或者网络延迟较高的情况下。
半同步复制则介于两者之间，主库在将事务写入 binlog 日志后，至少等待一个从库接收并写入 relay log（中继日志）后，才向客户端返回成功响应。
工作流程
-
主库执行事务
- 当客户端向主库发起一个事务请求时，主库开始执行这个事务，并将事务的操作记录到 binlog 日志中。
-
事务提交
- 主库在事务执行完成后，准备提交事务。此时，主库会检查是否有至少一个从库已经接收到了该事务的 binlog 日志并写入到 relay log 中。如果有，主库则认为该事务已经成功复制到至少一个从库，可以安全地提交事务，并向客户端返回成功响应。
- 如果没有从库确认接收到了该事务的 binlog 日志，主库会等待一段时间，等待从库的响应。如果在等待时间内有从库响应，主库则提交事务并返回成功响应；如果等待超时，主库会切换回异步复制模式，提交事务并返回成功响应，但会记录一条警告信息。
-
从库接收并应用事务
- 从库通过 I/O 线程从主库读取 binlog 日志，并将其写入到本地的 relay log 中。然后，从库的 SQL 线程会读取 relay log 中的事务，并在从库上执行这些事务，从而实现数据的同步。
优点
-
提高数据一致性
- 相比异步复制，半同步复制能够在一定程度上保证主库和从库之间的数据一致性。当主库发生故障切换到从库时，丢失数据的可能性大大降低。
-
减少数据丢失风险
- 在主库出现故障时，如果采用异步复制，可能会有一些事务还未复制到从库就丢失了。而半同步复制则可以减少这种风险，因为至少有一个从库已经接收到了事务的 binlog 日志。
缺点
-
性能影响
- 由于主库需要等待从库的响应，所以半同步复制会在一定程度上影响主库的性能，特别是在网络延迟较高或者从库性能较差的情况下。
-
复杂性增加
- 半同步复制的配置和管理相对复杂，需要考虑网络延迟、从库数量、等待超时时间等因素。如果配置不当，可能会导致性能下降或者数据不一致的问题。
gtid模式
当为启用gtid时我们要考虑的问题
当激活GITD之后
设置gtid
在master端和slave端开启gtid模式
master
slave
查看日志
停止slave端
开启slave端的gtid
master
启用半同步模式
在master端配置启用半同步模式
安装半同步插件
查看插件情况
打开半同步功能 （默认已经打开了）
如果没打开，使用一下命令
在slave端开启半同步功能
安装半同步插件
重启IO线程，半同步才能生效
测试一下
模拟故障
在slave端
slave开启IO线程
数据成功写入
五、MySQL高可用之组复制 (MGR)
组复制流程
组复制单主和多主模式
single-primary mode(单写或单主模式)
multi-primary mode(多写或多主模式)
实现mysql组复制
编辑主配置文件
[root@mysql ~]# cat /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0
server-id=1 #配置server唯一标识号
gtid_mode=ON #启用全局事件标识
enforce-gtid-consistency=ON #强制gtid一致
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"# 禁用指定存储引擎master_info_repository=TABLE #复制事件数据到表中而不记录在数据目录中
relay_log_info_repository=TABLE
binlog_checksum=NONE #禁止对二进制日志校验
log_slave_updates=ON #打开数据库中继，#当slave中sql线程读取日志后也会写入到自己的binlog中
log_bin=binlog #重新指定log名称
binlog_format=ROW #使用行日志格式
plugin_load_add='group_replication.so' #加载组复制插件
transaction_write_set_extraction=XXHASH64 #把每个事件编码为加密散列
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"#通知插件正式加入 或创建的组 名 名称为 uuid 格式group_replication_start_on_boot=off #在server启动时不自动启动组复制
group_replication_local_address="172.25.254.128:33061" #指定插件接受其他成员的信息端口
group_replication_group_seeds="172.25.254.10:33061,172.25.254.152:33061,172.25.254.153:33061"
# 本地地址允许访问成员列表group_replication_ip_whitelist="172.25.254.0/24,127.0.0.1/8" #主机白名单
group_replication_bootstrap_group=off
group_replication_single_primary_mode=OFF #使用多主模式
group_replication_enforce_update_everywhere_checks=ON #组同步中有任何改变检测更新group_replication_allow_local_disjoint_gtids_join=1 #放弃自己信息以master事件为主
对数据库进行初始化
启动数据库并进入数据库修改密码
配置sql
注意这块的MEMBER_HOST下面是主机名，所以我们一定要做解析（三个节点都需要做解析）
复制配置文件到myql-node1和mysql-node2并修改
对myql-node1和mysql-node2的数据库进行初始化
配置sql
测试
在myql-node1和mysql-node2上插入数据
假如myql-node1下线了
myql-node1上线是不会自动加入组复制的
要想加入，需要执行以下命令
mysql> START GROUP_REPLICATION;
六、MySQL-router（mysql路由）
MySQL-router概述
主要功能
-
路由功能
- MySQL Router 可以根据配置将客户端的连接请求路由到合适的 MySQL 服务器实例上。例如，在主从复制架构中，它可以将读请求路由到从库，将写请求路由到主库，实现读写分离，提高数据库的性能和可用性。
- 它通过解析 MySQL 协议，能够在不修改客户端应用程序的情况下实现透明的路由。
-
负载均衡
- 在多个 MySQL 服务器实例组成的集群中，MySQL Router 可以实现负载均衡，将客户端的连接均匀地分配到不同的服务器上，避免单个服务器负载过高。
- 支持多种负载均衡算法，如轮询、随机等，可以根据实际需求进行选择。
-
高可用性
- 当 MySQL 服务器实例出现故障时，MySQL Router 可以自动检测到故障，并将连接请求路由到其他可用的服务器上，实现自动故障转移，提高系统的可用性。
- 它通过定期检测服务器的健康状态，确保只将连接请求路由到正常运行的服务器上。
工作原理
-
配置文件
- MySQL Router 通过读取配置文件来了解 MySQL 服务器实例的拓扑结构和路由规则。配置文件中可以指定主库、从库的地址，以及路由策略等信息。
- 例如，可以在配置文件中指定多个从库，并设置负载均衡算法为轮询，这样 MySQL Router 就会将读请求依次分配到不同的从库上。
-
连接管理
- 当客户端连接到 MySQL Router 时，Router 会根据配置文件中的路由规则将连接请求转发到相应的 MySQL 服务器实例上。
- 如果连接的服务器出现故障，Router 会自动切换到其他可用的服务器上，保持客户端连接的连续性。
-
健康检测
- MySQL Router 会定期对配置文件中指定的 MySQL 服务器实例进行健康检测，以确定它们的可用性。
- 如果检测到服务器故障，Router 会更新内部的路由表，将连接请求路由到其他正常的服务器上。
优点
-
轻量级和易于部署
- MySQL Router 是一个轻量级的中间件，安装和配置相对简单。它可以快速部署在现有的 MySQL 架构中，无需对客户端应用程序进行大规模的修改。
-
透明的路由和负载均衡
- 对于客户端应用程序来说，MySQL Router 实现了透明的路由和负载均衡，客户端无需关心数据存储在哪个服务器上，只需要连接到 Router 即可。
-
高可用性
- 通过自动故障转移和健康检测功能，MySQL Router 提高了 MySQL 数据库的高可用性，确保系统在服务器故障时能够继续提供服务。
缺点
-
单点故障
- 如果 MySQL Router 本身出现故障，客户端将无法连接到 MySQL 服务器。为了解决这个问题，可以部署多个 Router 实例，并使用负载均衡器来实现高可用性。
-
性能开销
- 由于 MySQL Router 需要解析 MySQL 协议并进行路由和负载均衡，它会引入一定的性能开销。在高并发的环境下，可能会对系统性能产生一定的影响。
-
配置复杂性
- 虽然 MySQL Router 的配置相对简单，但对于复杂的数据库架构，配置文件可能会变得比较复杂，需要仔细规划和管理。
Mysql route的部署方式
上传需要的rpm包
安装mysql-router
master
slave
配置mysql-router
[root@mysql ~]# vim /etc/mysqlrouter/mysqlrouter.conf
启动服务并查看端口
建立测试用户
注意：mysql router 并不能限制数据库的读写，访问分流
上面演示的是轮询，还可设置为最先响应，具体配置如下
[routing:rw]bind_address = 0.0.0.0bind_port = 7002destinations = 172.25.254.163:3306,172.25.254.152:3306,172.25.254.128:3306routing_strategy = first-available
七、MySQL高可用集群MHA
MHA概述
MySQL 高可用集群 MHA（Master High Availability）是一套优秀的 MySQL 主从复制环境下的高可用解决方案。
主要功能
-
自动故障转移
- MHA 可以自动检测 MySQL 主库的故障，并在短时间内实现故障转移，将从库提升为主库，确保数据库服务的连续性。
- 例如，当主库发生硬件故障或软件错误导致不可用时，MHA 能够快速识别并选择一个最佳的从库进行切换，最大限度地减少服务中断时间。
-
数据一致性保证
- 在进行故障转移时，MHA 会确保数据的一致性。它会通过分析从库的中继日志（relay log），找到与主库最接近的同步点，并在新主库上应用剩余的事务，以保证数据的完整性。
- 这样可以避免在故障转移后出现数据丢失或不一致的情况。
-
主库在线切换
- MHA 支持在线主库切换，即可以在不影响业务的情况下，将主库切换到另一个节点。这对于计划内的维护操作或性能优化非常有用。
- 例如，可以在业务低峰期进行主库切换，以进行硬件升级或软件更新。
-
监控和管理
- MHA 提供了一套监控工具，可以实时监控 MySQL 主从复制环境的状态，包括主库和从库的健康状况、复制延迟等。
- 同时，MHA 还提供了一些管理命令，方便管理员进行故障排除和维护操作。
MHA 的组成
工作原理
-
节点角色
- MHA 集群由一个管理节点（Manager Node）和多个数据库节点（Database Node）组成。管理节点负责监控和管理整个集群，数据库节点则是实际的 MySQL 服务器实例。
- 在主从复制环境中，通常有一个主库和多个从库。管理节点会定期检查主库的健康状况，并与从库进行通信，以获取复制状态信息。
-
故障检测
- MHA 通过多种方式检测主库的故障，包括网络连接检测、MySQL 进程状态检测、复制状态检测等。
- 如果管理节点发现主库不可用，它会立即启动故障转移流程。
-
故障转移流程
- 首先，管理节点会选择一个最佳的从库作为新的主库。选择的标准通常包括从库的复制延迟、数据完整性、服务器性能等因素。
- 然后，管理节点会在新主库上应用剩余的事务，以保证数据的一致性。同时，它会将其他从库重新指向新主库，并启动复制。
- 最后，管理节点会通知客户端应用程序新主库的地址，以便客户端能够继续连接到数据库服务。
优点
-
高可用性
- MHA 能够在主库故障时快速实现故障转移，确保数据库服务的连续性，提高了系统的可用性。
-
数据一致性
- 通过严格的数据一致性保证机制，MHA 可以避免在故障转移后出现数据丢失或不一致的情况。
-
易于部署和管理
- MHA 的安装和配置相对简单，管理员可以通过命令行工具或图形界面进行管理和监控。
-
支持多种存储引擎
- MHA 支持 MySQL 多种存储引擎，包括 InnoDB、MyISAM 等，可以满足不同业务场景的需求。
缺点
-
依赖于外部工具
- MHA 需要依赖一些外部工具，如 SSH、Perl 等。这可能会增加部署和维护的复杂性。
-
性能开销
- MHA 在进行故障检测和故障转移时会消耗一定的系统资源，可能会对数据库性能产生一定的影响。
-
配置复杂性
- 对于复杂的数据库架构，MHA 的配置可能会比较复杂，需要仔细规划和调整参数。
故障切换备选主库的算法
MHA部署实施
新增一个节点作为mysql-mha
上传需要的安装包
解压缩
做解析
做免密认证
搭建一主两从架构
修改两从的配置文件
对数据库进行初始化
启动mysql并进入数据库修改密码
master
slave
安装MHA所需要的软件
[root@mysql-mha MHA-7]# yum install *.rpm -y
注意把mha4mysql-node-0.58-0.el7.centos.noarch.rpm拷贝给master和slave节点
安装（master和slave都需要安装）
1.Manager 工具包主要包括以下几个工具：masterha_check_ssh# 检查 MHA 的 SSH 配置状况masterha_check_repl# 检查 MySQL 复制状况masterha_manger# 启动 MHAmasterha_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 # 识别差异的中继日志事件并将其差异的事件应用于其他的 slavefilter_mysqlbinlog # 去除不必要的 ROLLBACK 事件（ MHA 已不再使用这个工具）purge_relay_logs # 清除中继日志（不会阻塞 SQL 线程）
配置MHA 的管理环境
生成配置目录和配置文件
[root@mysql-mha MHA-7]# 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.
在master节点上，创建用户并赋予权限，因为连接数据库时使用的是root用户，是不被允许远程连接的
编辑配置文件
[server default]
user=root #mysql管理员用户，因为需要做自动化配置
password=123456 #mysql密码
ssh_user=root #ssh远程登陆用户
master_binlog_dir= /data/mysql #二进制日志目录
remote_workdir=/tmp #远程工作目录
secondary_check_script= masterha_secondary_check -s 172.25.254.128 -s 172.25.254.155 #此参数使为了提供冗余检测，方式是mha主机网络自身的问题无法连接数据库节点，应为集群之外的主机
ping_interval=3 #每隔3秒检测一次
# master_ip_failover_script= /script/masterha/master_ip_failover #发生故障后调用的脚本，用来迁移vip
# shutdown_script= /script/masterha/power_manager #电源管理脚本
# report_script= /script/masterha/send_report #当发生故障后用此脚本发邮件或者告警通知
# master_ip_online_change_script= /script/masterha/master_ip_online_change #在线切换时调用的vip迁移脚本，手动
[server default]
manager_workdir=/etc/masterha #mha工作目录
manager_log=/etc/masterha/manager.log #mha日志[server1]
hostname=172.25.254.128
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.152
candidate_master=1 #可能作为master的主机
check_repl_delay=0[server3]
hostname=172.25.254.153
no_master=1 #不会作为master的主机
check_repl_delay=0
mha主机和其他主机配置免密
八、MySQL高可用集群故障迁移
MHA（Master High Availability）是一套用于 MySQL 高可用的解决方案，它可以在主服务器出现故障时自动进行故障切换，以确保数据库服务的高可用性。
MHA 故障切换的过程
MHA 故障切换的优势
-
快速切换
- MHA 能够在很短的时间内完成故障切换，通常可以在几秒钟到几十秒钟内完成，大大减少了数据库服务的中断时间。
-
数据一致性
- 通过在切换过程中停止故障主服务器的写入操作，并进行数据补偿，可以确保切换后的数据一致性。
-
自动化操作
- MHA 可以自动检测主服务器故障并进行切换，无需人工干预，大大降低了运维成本和风险。
-
支持多种复制架构
- MHA 支持多种 MySQL 复制架构，包括传统的主从复制、半同步复制等，可以满足不同场景的需求。
MHA故障切换方式
master 未出现故障手动切换
-
场景与目的：
- 通常在计划内的维护、升级或者需要进行数据库架构调整等情况下进行。比如要对主服务器的硬件进行升级，或者要迁移数据库到新的服务器环境中。
- 为了避免对业务的影响，选择在业务低峰期进行手动切换，确保切换过程平稳过渡。
-
切换步骤：
- 管理员通过 MHA 提供的管理工具或者命令行接口发出切换指令。
- MHA 管理器接收到指令后，开始评估从服务器的状态，包括复制延迟、数据完整性、服务器负载等因素。
- 选择一个最合适的从服务器作为新的主服务器。这个选择过程通常是自动的，但管理员也可以根据具体情况进行干预和调整。
- 对选中的从服务器进行一系列操作，如设置为读写模式、修改数据库配置参数等，使其成为新的主服务器。
- 通知其他从服务器更改主服务器的指向，开始从新主服务器进行复制。
- 最后，确认切换是否成功，检查新主服务器和从服务器的状态，确保数据库服务正常运行。
-
优势：
- 可控性高：管理员可以根据实际情况选择最佳的切换时机和新主服务器，确保切换过程对业务的影响最小化。
- 便于规划：可以提前做好切换的准备工作，如通知相关人员、备份数据等，提高切换的成功率和安全性。
master 故障手动切换
-
场景与目的：
- 当主服务器出现故障，但自动切换未能成功启动或者管理员认为自动切换不可靠时，可以选择手动切换。
- 手动切换可以让管理员更好地控制切换过程，避免出现数据丢失或不一致的情况。
-
切换步骤：
- 管理员首先确认主服务器确实出现故障，无法恢复正常运行。可以通过检查服务器的状态、数据库连接情况、日志文件等方式进行判断。
- 然后，像在 master 未出现故障手动切换中一样，管理员通过管理工具或命令行接口发出切换指令。
- MHA 管理器开始执行切换流程，选择新主服务器、进行配置调整、通知从服务器等操作。
- 管理员在切换过程中密切关注切换进度和数据库状态，及时处理可能出现的问题。
-
优势：
- 应急处理：在自动切换失败的情况下，手动切换可以作为一种有效的应急措施，确保数据库服务尽快恢复。
- 数据安全：管理员可以在切换过程中采取额外的措施来保护数据的安全，如进行数据备份、验证数据完整性等。
自动切换
-
场景与目的：
- 适用于主服务器出现意外故障，且需要快速恢复数据库服务的情况。自动切换可以在无人值守的情况下自动完成故障切换，减少数据库服务的中断时间。
-
切换步骤：
- MHA 管理器持续监控主服务器的状态，包括网络连接、数据库服务的响应情况、复制状态等。
- 当检测到主服务器故障时，MHA 管理器自动选择一个合适的从服务器作为新的主服务器。这个选择过程基于预先设定的策略，如复制延迟最小、数据最完整等。
- 对新主服务器进行配置调整，使其能够接受写入操作，并通知其他从服务器更改主服务器的指向。
- 自动切换过程通常在很短的时间内完成，以确保数据库服务的高可用性。
-
优势：
- 快速响应：能够在主服务器故障发生后迅速启动切换流程，减少数据库服务的中断时间，提高系统的可用性。
- 无需人工干预：减少了人为错误的可能性，特别适用于无人值守的生产环境。
- 自动化管理：减轻了管理员的工作负担，提高了数据库管理的效率
repl_user=repl #mysql 主从复制中负责认证的用户
repl_password=123456 #mysql 主从复制中负责认证的用户密码
master未出现故障手动切换
在master数据节点还在正常工作情况下
[root@mysql-mha ~]# masterha_master_switch \
> --conf=/etc/masterha/app1.cnf \ #指定配置文件
> --master_state=alive \ #指定master节点状态
> --new_master_host=172.25.254.152 \ #指定新master节点
> --new_master_port=3306 \ #执行新master节点端口
> --orig_master_is_new_slave \ #原始master会变成新的slave
> --running_updates_limit=10000 #切换的超时时间
检测一下（172.25.254.152成为master）
再切换回来
测试一下
master故障手动切换
[root@mysql-mha ~]# masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=172.25.254.128 --dead_master_port=3306 --new_master_host=172.25.254.152 --new_master_port=3306 --ignore_last_failover--ignore_last_failover 表示忽略在 /etc/masterha/ 目录中在切换过程中生成的锁文件
测试一下
[root@mysql-mha masterha]# rm -rf app1.failover.complete # 删掉切换锁文件# 监控程序通过指定配置文件监控 master 状态，当 master 出问题后自动切换并退出避免重复做故障切换[root@mysql-mha masterha]# masterha_manager --conf=/etc/masterha/app1.cnf
给mysql-node1添加一个ip，这个ip为172.25.254.155，也就是配置文件中的ip
我们把master上的mysql停掉，看能否自动切换
[root@mysql-mha masterha]# tail -f /etc/masterha/manager.log
九、MySQL高可用集群的VIP管理
上传需要的脚本
[root@mysql-mha masterha]# vim /usr/local/bin/master_ip_failover
[root@mysql-mha masterha]# vim /usr/local/bin/master_ip_online_change
修改配置文件
为master添加VIP 172.25.254.100
把master上的MySQL停掉
然后我们启动监控并查看日志
VIP跳到了172.25.254.152上了
恢复故障主机
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
