MySQL高可用解决方案---MHA

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:

一主两从一管理,一共四台设备

MHA的作用是做master的高可用,当主节点MySQL故障时,会将和主节点数据最接近的一个从节点提升为主节点,同时如果其他从节点有更新的数据也会同步到此“准主节点”上。如果在主节点有数据已经提交但是所有的从节点还未完成复制,则从节点提升为主节点后只能将此数据回退,没有别的办法。


准备事项:


1、同步时间

1
ntpdate 172.18.0.1

2、配置主机域名,在主节点即node1上操作

1
2
3
4
5
6
7
8
vim  /etc/hosts
192.168.1.101 node1  #主节点
192.168.1.106 node2  #从节点
192.168.1.107 node3  #从节点
192.168.1.100 node4  #manager
scp  /etc/hosts   node2: /etc/hosts
scp  /etc/hosts   node3: /etc/hosts
scp  /etc/hosts   node4: /etc/hosts

3、MHA需要ssh无密钥验证

1
2
3
4
5
6
ssh -keygen -t rsa -P  ''
cd    /root/ . ssh /
ssh -copy- id  -i . /id_rsa .pub  root@node1
scp  id_rsa{,.pub} authorized_keys  node2: /root/ . ssh
scp  id_rsa{,.pub} authorized_keys  node3: /root/ . ssh
scp  id_rsa{,.pub} authorized_keys  node4: /root/ . ssh


下面开始具体步骤:


1、配置主从复制集群

1
2
3
4
5
6
7
8
9
node1:
vim  /etc/my .cnf.d /server .cnf  
  [server]
   skip_name_resolve=ON
   innodb_file_per_table=ON
   server_id = 1
   log_bin = master-log
   relay_log = relay-log
   #主节点也要配置中继日志,因为主节点故障再恢复时就会称为从节点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
node2:
vim  /etc/my .cnf.d /server .cnf  
[server]
   skip_name_resolve=ON
   innodb_file_per_table=ON
   server_id = 2
   relay_log = relay-log
   log_bin = master-log
   relay_log_purge = OFF
   read_only = ON
   
   node3:
vim  /etc/my .cnf.d /server .cnf  
[server]
   skip_name_resolve=ON
   innodb_file_per_table=ON
   server_id = 3
   relay_log = relay-log
   log_bin = master-log
   relay_log_purge = OFF
   read_only = ON

开启服务

1
systemctl  start mariadb.service


2、在主节点授权复制账号

1
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO  'repluser' @ '192.168.1.%'  IDENTIFIED BY  'centos' ;

主节点授权管理设备的管理账号

1
GRANT ALL ON *.* TO  'mhaadmin' @ '192.168.1.%'  IDENTIFIED BY  'centos' ;

写入磁盘

1
FLUSH PRIVILEGES;


3、在从节点配置

1
2
3
4
5
CHANGE  MASTER TO MASTER_HOST= '192.168.1.101' ,MASTER_USER= 'repluser' ,MASTER_PASSWORD= 'centos' ,MASTER_LOG_FILE= 'master-log.000003' ,MASTER_LOG_POS=245;
START SLAVE ;
SHOW SLAVE STATUS\G;
SELECT USER FROM mysql.user;
#能看到复制授权账户和管理账户已经同步


4、安装MHA软件包

在manager节点安装manager和node包

1
2
yum -y  install  mha4mysql-manager-0.56-0.el6.noarch.rpm
yum -y  install  mha4mysql-node-0.56-0.el6.noarch.rpm


5、在node上安装node包

1
yum -y  install   mha4mysql-node-0.56-0.el6.noarch.rpm


6、在manager上配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
mkdir  /etc/masterha
vim  /etc/masterha/app1 .cnf
[server default]
user=mhaadmin
password=centos
manager_workdir= /data/masterha/app1
manager_log= /data/masterha/app1/manager .log
remote_workdir= /data/masterha/app1
ssh_user=root
repl_user=repluser
repl_password=centos
ping_interval=1
 
[server1]
hostname =192.168.1.101
ssh_port=22
candidate_master=1
 
[server2]
hostname =192.168.1.106
ssh_port=22
candidate_master=1
 
[server3]
hostname =192.168.1.107
ssh_port=22
candidate_master=1


7、检查配置并启动服务

1
2
3
4
5
6
检查
masterha_check_ssh --conf= /etc/masterha/app1 .cnf
masterha_check_repl --conf= /etc/masterha/app1 .cnf 
 
启动manager服务器
masterha_manager  --conf= /etc/masterha/app1 .cnf


8、测试

此时模拟主节点故障

1
2
3
SHOW MASTER STATUS; 
SHOW SLAVE STATUS;
#在从节点查看从节点信息,此时有一个从节点已经升级为主节点


9、修复原主节点

1
2
3
4
5
6
7
8
9
10
11
vim  /etc/my .cnf.d /server .cnf     #添加两行
relay_log_purge = OFF
read_only = ON
 
再次开启服务上线
systemctl  start mariadb.service
 
CHANGE  MASTER TO MASTER_HOST= '192.168.1.106' ,MASTER_USER= 'repluser' ,MASTER_PASSWORD= 'centos' ,MASTER_LOG_FILE= 'master-log.000003' ,MASTER_LOG_POS=320; 
START SLAVE;
SHOW SLAVE STATUS\G;
#此时的主节点就是替代的原从节点


10、在manager上检查复制功能

1
2
3
4
5
masterha_check_repl --conf= /etc/masterha/app1 .cnf
出现如下字样就说明主从已经切换了,而且原主节点此时也变成了从节点
192.168.1.106(192.168.1.106:3306) (current master)
  +--192.168.1.101(192.168.1.101:3306)
  +--192.168.1.107(192.168.1.107:3306)


11、再次启动MHA

1
2
3
nohup  masterha_manager  --conf= /etc/masterha/app1 .cnf &>  /data/masterha/app1/manager .log &
#在后台执行,并剥离与当前终端的关系
#当主节点再次down掉,此程序会自动结束同时主从节点自动切换。然后我们还要再次手动开启MHA


至此实验结束


本文转自  a_pan  51CTO博客,原文链接:http://blog.51cto.com/panpangao/1981848

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
95
分享
相关文章
【IDEA】java后台操作mysql数据库驱动常见错误解决方案
【IDEA】java后台操作mysql数据库驱动常见错误解决方案
209 0
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
133 82
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
469 3
Mysql高可用架构方案
云数据库:从零到一,构建高可用MySQL集群
在互联网时代,数据成为企业核心资产,传统单机数据库难以满足高并发、高可用需求。云数据库通过弹性扩展、分布式架构等优势解决了这些问题,但也面临数据安全和性能优化挑战。本文介绍了如何从零开始构建高可用MySQL集群,涵盖选择云服务提供商、创建实例、配置高可用架构、数据备份恢复及性能优化等内容,并通过电商平台案例展示了具体应用。
MySQL in 太多的解决方案
MySQL in 太多的解决方案
807 0
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
MySQL自增ID耗尽应对策略:技术解决方案全解析
在数据库管理中,MySQL的自增ID(AUTO_INCREMENT)属性为表中的每一行提供了一个唯一的标识符。然而,当自增ID达到其最大值时,如何处理这一情况成为了数据库管理员和开发者必须面对的问题。本文将探讨MySQL自增ID耗尽的原因、影响以及有效的应对策略。
320 3
MySQL自增ID耗尽解决方案:应对策略与实践技巧
在MySQL数据库中,自增ID(AUTO_INCREMENT)是一种特殊的属性,用于自动为新插入的行生成唯一的标识符。然而,当自增ID达到其最大值时,会发生什么?又该如何解决?本文将探讨MySQL自增ID耗尽的问题,并提供一些实用的解决方案。
183 1
一个 MySQL 数据库死锁的案例和解决方案
本文介绍了一个 MySQL 数据库死锁的案例和解决方案。
441 3
JPA不识别MySQL枚举类型的解决方案
在JPA中处理MySQL的枚举类型,需要在实体类与数据库之间进行适当的转换。可以选择使用 `@Enumerated`注解、实现自定义的转换器,或者使用原生SQL查询来解决JPA不直接支持MySQL枚举类型的问题。选择最佳方案时,应考虑项目的具体需求和架构。通过正确的映射和转换,可以确保JPA与MySQL数据库间高效且安全的数据交互。
198 6
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等