MHA,MySQL 的高可用架构

最新推荐文章于 2024-07-24 17:22:53 发布
最新推荐文章于 2024-07-24 17:22:53 发布
阅读量999 收藏 1
点赞数
分类专栏： 运维linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/houdaxiami/article/details/79796330
版权

                                                                    MHA,MySQL 的高可用架构

MHA,MySQL 的高可用架构,在基于主从架构的模式下,当主服务器挂掉之后,由 MHA 中 manager 来决定从哪台 slave 从服务器当中选择一台作 为master 主服务器,通常是比较从服务器中的数据,哪个最全,最新,更新时间的长短来判断,当决定使用哪台从服务器作为新的主服务器后, MHA 会从其 他节点处获取额外信息,避免数据不一致的情况发生,使数据一致。

MHA 有两种角色:

1.MHA manager

用于统筹管理一个主从架构集群的 master 转换,数据复制权限,以及数据库操作权限等设置,通常作为单台服务器进行配置。每一个 master/slave 集群都作为一个 application。

2.MHA node

MySQL 集群当中的节点,所有在该集群中的服务器都是一个节点,如manager,master,slave1,slave2 四台服务器,则有四个 node 节点。它通过监控具备解 析和清理 logs 功能的脚本来加快故障转移。

MHA 架构集群:

manager 172.25.50.1

master server_id=1 172.25.50.3

slave1 server_id=2 172.25.50.4

slave2 server_id=3 172.25.50.2

1)首先配置好一主两从的数据库架构,这一块就不详细描述了,需要注意的是,因为 MHA 高可用架构的关系,任何一台 MySQL 服务器都有可能成为主服务器, 所以不能像普通主从架构一般,给主服务器开启 binlog,给从服务器开启 relay_log,需要在主从服务器上都开启 binlog 与 relay_log。如该/etc/my.cnf 配置，在初始化mysql前将启动脚本的密码查件注销，以免影响后面的实验

由于做主从复制时已经配好了 master 和 slave1,所以只需要在配置一个slave2;再配置后,发现 IQ 线程为NO

查看日志发现是和主库不同步的原因


在停止 slave 输入命令使其复制时跳过 773 后开启 slave 后正常

slamysql> stop slave;

Query OK, 0 rows affected (0.28 sec)mysql> CHANGE MASTER TO

MASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=773;

Query OK, 0 rows affected (0.52 sec)

mysql> start slave;

Query OK, 0 rows affected (0.11 sec)

2、MHA 高可用的实现首先需要构建主从集群,其次,需要将各个节点之间的ssh 通信无障碍。

设置密钥通信

如 master172.25.50.1 需要向其余三个节点传送密钥,使之能够无密码访问

#ssh-keygen -t rsa -P ""

#ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.50.2#ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.50.3

#ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.50.4
其余三个节点如是。

3安装 MHA

MHA manager

#yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm  #该 manager 安装需要依赖于许多 epel 源中的插件,联网安装
MHA node 
#yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm     #四个节点都需要安装

4、配置 manager,使 manager 能够管理主从集群,手动设置一个配置文件在server default 针对于所有 MySQL 服务器的设置。user,password 用于对数据库进行管理的账号密码,这个是需要在 MySQL集群中,即 master,slave1,slave2 中授权。

如ssh_user 则是通信时使用的用户,为 root。repl_user,repl_password 用于主从数据库之间复制转移的账户密码,当主服务器 down 后,从服务器起来,需要在从服务器中进行的 change master授权。

manager_workdir,manager_log 则是用于设置 manager 的工作目录以及日志存放路径。

master_binlog_dir 用于告诉 managermaster 的 binlog 日志放置路径。

ping_interval 用于设置访问的间隔,使用 ping 方式访问。

server1,server2,server3 则是三台 MySQL 服务器,指定其 hostname,可用 IP 地址代替,若要使用主机名,则需要将主机名写入/etc/hosts 中。candidate_master=1,用于设置该服务器是否有资格成为主服务器,若为 0则无资格。

MHA manager 的安装,会提供诸多工具程序,其常见的如下所示。

Manager 节点:

- masterha_check_ssh:MHA 依赖的 SSH 环境检测工具;

- masterha_check_repl:MySQL 复制环境检测工具;

- masterha_manager:MHA 服务主程序;- masterha_check_status:MHA 运行状态探测工具;

- masterha_master_monitor:MySQL master 节点可用性监测工具;

- masterha_master_switch:master 节点切换工具;

- masterha_conf_host:添加或删除配置的节点;

- masterha_stop:关闭 MHA 服务的工具;

Node 节点:

- save_binary_logs:保存和复制 master 的二进制日志;

- apply_diff_relay_logs:识别差异的中继日志事件并应用于其它 slave;

- filter_mysqlbinlog:去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具);

- purge_relay_logs:清除中继日志(不会阻塞 SQL 线程);

mkdir masterha

cd masterha/

vim app1.cnf

[server default]

user=root

password=Hhb+1996

ssh_user=root

repl_password=Hhb+1996

repl_user=repl

master_binlog_dir=/var/lib/mysql

remote_workdir=/tmp

#secondary_check_script= masterha_secondary_check -s remote_host1 -s remote_host2

ping_interval=1

# master_ip_failover_script= /script/masterha/master_ip_failover

# shutdown_script= /script/masterha/power_manager

# report_script= /script/masterha/send_report

# master_ip_online_change_script= /script/masterha/master_ip_online_change

manager_workdir=/usr/local/masterha/

manager_log=/usr/local/masterha/manager.log
[server1]

hostname=172.25.50.1

[server2]

hostname=172.25.50.2

candidate_master=1

check_repl_delay=0

[server3]

hostname=172.25.50.3
                              



使用ma sterha_check_ssh --conf=/usr/local/masterha/app1.cnf测试通信环境是否正常；masterha_check_repl --conf=/usr/local/masterha/app1.cnf 测试复制环境是否正常

在使用masterha_check_repl --conf=/usr/local/masterha/app1.cnf测试复制环境时发现环境异常


分析报错后发现时没有在master端给prel和root授权的缘故

在master 上授权：

mysql> grant replication slave on *.* to repl@'%' identified by 'Hhb+1996';

mysql> grant replication slave on *.* to root@'%' identified by 'Hhb+1996';

授权后测试：

Nohup masterha_manager --conf=/usr/local/masterha/app1.cnf &

Nohup masterha_manager --conf=/usr/local/masterha/app1.cnf  在管理主机启动管理程序

[root@server3 ~]# pkill -9 mysqld   #此时在将3中mysql强行关闭，发现server2由slave端变成muster端，

在管理端查看刚才的日管理日志


手动切换：当master端数据库关掉后可用下面手动方法切换

masterha_master_switch--master_state=dead--conf=/usr/local/masterha/app1.cnf--dead_master_host=172.25.50.2--dead_master_port=3306--new_master_host=172.25.50.3--new_master_port=3306--ignore_last_failover

手动热切换：可以在master正常工作时使其数据库关掉，让备用mastre机接替其工作

masterha_master_switch--conf=/usr/local/masterha/app1.cnf--master_state=alive--new_master_host=172.25.50.2--new_master_port=3306 --orig_master_is_new_slave--running_updates_limit=10000


测试二: 停掉备用主机的io，然后在master主机加入数据，造成备用master和master主机二进制数据不一致，然后关掉master主机的mysql,执行manager命令，使备用master成为master，看数据是否会一致

change master to master_host='172.25.50.3', master_user='repl', master_password='Hhb+1996', master_auto_position=1;   #使master指向server3（注意：每次执行需删除app1.failover.complete,否责出错）

stop slave io_thread;  停掉备用主机io线程

在主master主机插入数据

在另一台slave中查看数据是否同步过去

在备用主机上查看数据是否同步

使备用成为master后，查看数据是否根据差异日志恢复过来

使用脚本控制master状态，

Vim /usr/local/masterha/app1.cnf     #加入需要的脚本并指定位置

 master_ip_failover_script= /usr/local/masterha/master_ip_failover

# shutdown_script= /script/masterha/power_manager

report_script= /usr/local/masterha/send_report

master_ip_online_change_script= /usr/local/masterha/master_ip_online_change

manager_workdir=/usr/local/masterha

manager_log=/usr/local/masterha/manager.log

vim master_ip_failover  #给master添加虚拟ip


vim master_ip_online_change #同样只需添加虚拟ip

vim send_report  #添加邮箱和密码

chmod +x send_report master_ip_failover master_ip_online_change   #给脚本添加执行权限

测试：

在测试时需要虚拟机进行联网

[root@foundation50 MHA]# iptables -t nat -A POSTROUTING -s 172.25.50.0/24 -j MASQUERADE   #在物理主机添加路由

vim /etc/sysconfig/network-scripts/ifcfg-eth0 #在需要联网的虚拟机上添加网关，为物理机ip

Vim /etc/resolv.conf  #添加本地解析，使其可拼通百度

/etc/init.d/network restart #重启网络使其生效

启动管理，将master机上的数据库关掉，此时的状态变化便会以邮件形式发到你的邮箱，从而达到监控报警的目的

masterha_master_switch--conf=/usr/local/masterha/app1.cnf--master_state=alive--new_master_host=172.25.50.3--new_master_port=3306--orig_master_is_new_slave --running_updates_limit=10000

通过脚本热切换，由于加了脚本，此时再执行，并不会造成muster的mysql数据库关掉，而是使原来的master主机变为备用master,可以不断进行切换

此时，server3则成为master,ip漂移到server3上

Server2 则由原来的master主机变为slave，由于此时变换并没有造成机器瘫痪，所以不会发邮箱提醒






houdaxiami
关注
专栏目录
mha高可用
mfuivivig的博客
11-03 1322
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQLReplication（二层）环境，目的在于维持Master主库的高可用性。是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。
MySQL高可用架构MHA
weixin_48861962的博客
11-04 359
目录 一、MySQL MHA介绍 1.1 什么是 MHA 1.2 MHA 的组成 1.3 MHA 的特点 二、MySQL MHA搭建 1．MHA架构部分 2．故障模拟部分 3 . 环境准备 2.1 MySQL MHA搭建的步骤（理论） 2.2 MySQL MHA搭建具体操作步骤（实操） 2.2.1 搭建步骤 一、MySQL MHA介绍 MHA（MasterHigh Availability）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automat
搭建MySQL的高可用架构（MHA）
lilygg的博客
02-27 1177
1.安装数据库 2.更改配置文件 [root@server2 ~]# vim /etc/my.cnf ################# server-id=1 log-bin=mysql-bin gtid_mode=ON enforce_gtid_consistency=ON log_slave_updates=ON [root@server1 ~]# systemctl start m...
MySQL的高可用(MHA)
最新发布
2402_84868182的博客
07-24 1198
一旦检测到主库故障，MHA 会选择一个最新的从库，并执行一系列操作将其提升为主库，包括应用剩余的 binlog 等。总之，MHA 为 MySQL 提供了一种可靠的高可用解决方案，但在实际应用中需要仔细配置和维护，以确保其正常稳定运行。设置为"true"表示从服务器会记录自己执行的更改操作，将其写入从服务器的二进制日志文件中。指定主服务器（master）的二进制日志文件名称，用于记录主服务器上的更改操作的日志文件。指定从服务器的中继日志文件名称，即用于记录主服务器的二进制日志在从服务器上执行的中继日志。
数据库MHA高可用配置和故障切换
qq_51545656的博客
12-17 1134
2、识别含有最新的更新 slave 日志 3、应用差异的中继日志（relay log）到其他的slave 4、应用从master保存的二进制日志事件 5、提升一个 salve 为新的master 6、使其他的slave连接行的master 进行复制。2．数据一致的情况下，按照配置文件顺序，选择备选主库。MHA（Master High Availability）的工作原理涉及多个步骤，主要包括主节点监控、故障检测、差异中继日志的生成和应用、Latest Slave的提升，以及其他从节点的更新。
MySQL MHA 高可用架构
事后诸葛亮的程序人生（微信：zq9017197）
01-06 3472
MySQL MHA 项目的地址：https://code.google.com/p/mysql-master-ha/，这个网站需要翻墙才能打开。MySQL MHA 是目前比较成熟的高可用解决方案。 在MySQL故障切换过程中，MHA（Master High Availability）能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中，MHA能在最大程度上保证数据的一致性
MHA管理所有数据库服务器
kali_yao的博客
09-11 719
## MHA ### 概述 #### MHA简介 - 由日本DeNA公司youshimaton开发 - 是一套优秀的实现MySQL高可用的解决方案 - 数据库的自动故障切换操作能做到在0~30秒之内完成 - MHA能确保在故障切换过程中最大限度保证数据的一致性，以达到真正意义上的高可用 #### MHA组成 - MHA Manager（管理节点） - - 可以单独部署在一台独立的机器上 - 也可以部署在某台数据库服务器上 - MHA Node（数据节点） - 存储数据的...
MySQL MHA高可用架构搭建手册
02-21
MySQL MHA高可用架构搭建手册
MySQL 高可用之MHA 工作原理和架构，实现MHA高可用实战案例
qq_43555873的博客
11-06 827
MySQL 高可用解决方案 MHA 工作原理和架构 MHA集群架构 实现 MHA 实战案例
mysql-MHA高可用
10-12
mha4mysql-node-0.56-0.el6.noarch.rpm mha4mysql-manager-0.56-0.el6.noarch.rpm
MySQL高可用架构MHA 搭建测试文档_v1.docx
04-23
总的来说，MHA结合Keepalived构建的MySQL高可用架构提供了强大的数据库冗余和故障恢复能力，对于业务连续性和数据安全性至关重要。在企业环境中，这种架构能有效降低因数据库故障导致的业务损失，提升系统的整体稳定...
MySQL高可用架构MHA软件包及脚本
12-21
MySQL高可用架构（MHA，Master High Availability）是一款用于MySQL集群的开源工具，旨在提高数据库系统的可用性和稳定性。MHA的主要目标是通过监控主库（Master）的状态，并在主库出现故障时，自动将从库（Slave）...
MySQL高可用架构之MHA
hknaruto的专栏
12-15 287
MySQL高可用架构之MHAMySQL高可用架构之MHA
MHA高可用架构
weixin_67033761的博客
06-15 306
1
MySQL高可用架构MHA(完整版)
低调说
11-17 548
MySQL高可用架构之MHA(完整版) 1.准备4台机器,做好以下配置 (1)ip与hostname对应关系 192.168.100.128 manager.test.com 192.168.100.129 master.test.com 192.168.100.130 slave01.test.com 192.168.100.131 slave02.test.com (2)配置hostname和hosts解析 hostnamectl set-hostname manager.test.com hostna
MySQL集群高可用架构之MHA
这是博客的简介的简介
09-23 4182
MySQL 高可用架构 MHA
MySQL高可用架构演进：从MHA到InnoDB Cluster
MySQL的高可用架构从早期的MHA到现在的InnoDB Cluster，经历了多个阶段的演进，旨在提高数据安全性、降低业务中断风险，同时兼顾性能和运维效率。随着技术的发展，未来的MySQL高可用解决方案将会更加成熟和智能化。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值