使用MHA对mysql主从架构中的主节点做高可用

MHA:Master HA(主从结构的高可用方案)只是实现了对主节点高可用,它是建构在mysql主从复制结构之上的,也就是说需要事先把mysq配置成传统的复制集群。

MHA在监控到master节点故障时,会提升其中拥有最新数据的slave节点称为新的master,在此期间,MHA会通过其它从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点在线切换的功能,即按需切换master/salve节点。

MHA服务有两种角色,MHA Manager(管理节点)和MHA Node(数据节点):

MHA Manager:通常单独部署在一台独立的机器上管理多个master/slave集群,每个master/slave集群称作一个Application;

MHA Node:运行在每台MySQL服务器上(master/slave/manager),它通过监控具备分析和清理logs功能的脚本来加快故障转移。

MySQL复制集群中的master故障时,MHA按如下步骤进行故障转移:

一旦主节点掉线,主节点上会有丢失的事件还没有复制到从节点上,为了避免出现事件丢失而导致数据不一致,MHA会在管理节点上保存一份主节点上二进制日志事件的副本;因此,当主节点掉线后,从管理节点上保存的事件中就能读出所有的事件,并且查找从各从节点中的中继日志中事件指针指向的位置,来判断哪个节点与主节点的事件更接近,并把管理节点本地备份冗余的二进制日志事件读出处理应用在这个最接近的从节点上,使这个从节点与主节点事件同步,并把其它从节点的主节点指向这个被修复的最近从节点,从而提升这个从节点提升了新的主;

为了完成这个功能MHA强依赖与ssh服务;因为它要通过ssh协议从主节点不断读取各种数据,把二进制日志事件同步到本地,以保证主节点掉线本地仍能获取到二进制日志事件;

然后,就在最近的从节点上重放管理节点上的事件,实现拥有与掉线的主节点一样的数据;

实验环境:物理机win7,虚拟机4台centos7

node1:MHA Manager

node2:MariaDB master

node3:MariaDB slave

node4:MariaDB slave

各节点的/etc/hosts文件配置内容添加:

192.168.255.2 node1.stu11.com node1

192.168.255.3 node2.stu11.com node2

192.168.255.4 node3.stu11.com node3

192.168.255.5 node4.stu11.com node4

首先,配置一个msyql主从复制结构:

安装MariaDB5.5,细节略。

在node2:

]# vim /etc/my.cnf

]# systemctl start mariadb.service

查看二进制日志事务的位置:

注意:一定要在创建拥有复制权限的账号之前查看二进制日志事务的位置:这两个从节点也都需要用到这个复制权限账号,因为它们其中一个都有可能会成为新的主节点;它们也都需要创建一个拥有复制权限的账号被其它节点复制二进制日志;

> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO ‘repluser‘@‘192.168.255.%‘ IDENTIFIED BY ‘replpass‘;

> FLUSH PRIVILEGES;

在node3:

]# vim /etc/my.cnf

]# systemctl start mariadb.service

> CHANGE MASTER TO MASTER_HOST=‘192.168.255.3‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘replpass‘,MASTER_LOG_FILE=‘master-bin.000005‘,MASTER_LOG_POS=245;

>  START SLAVE;

在node4:

]# vim /etc/my.cnf

]# systemctl start mariadb.service

> CHANGE MASTER TO MASTER_HOST=‘192.168.255.3‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘replpass‘,MASTER_LOG_FILE=‘master-bin.000005‘,MASTER_LOG_POS=245;

> START SLAVE;

以上配置完成mysql的主从复制结构。

在node2:创建一个拥有管理权限的用户账号且能够远程连接;

> GRANT ALL ON *.* TO ‘mhauser‘@‘192.168.255.%‘ IDENTIFIED BY ‘mhapass‘;

> FLUSH PRIVILEGES;

在node1:

]# ssh-keygen -t rsa -P ‘‘

在一个主机生成密钥对,让其余每个节点都有私钥即可实现相互ssh通信;

设定密钥权限为600:

]# chmod go=  .ssh/authorized_keys

把私钥和认证文件复制到各节点一份:

]# scp -p .ssh/id_rsa .ssh/authorized_keys node2:/root/.ssh

]# scp -p .ssh/id_rsa .ssh/authorized_keys node3:/root/.ssh

]# scp -p .ssh/id_rsa .ssh/authorized_keys node4:/root/.ssh

node1安装node和manager程序包:node2,3,4安装安装MHA的node:

mha4mysql-manager-0.56-0.el6.noarch.rpm

mha4mysql-node-0.56-0.el6.noarch.rpm

]# yum install mha4mysql-*

]# mkdir /etc/masterha

]# vim /etc/masterha/app1.cnf

]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

显示:[info] All SSH connection tests passed successfully

表示各节点间ssh互信通信成功;

]# masterha_check_repl --conf=/etc/masterha/app1.cnf

输出信息最后一行类似如下信息,表示其通过检测:

MySQL Replication Health is OK

此时,MHA高可用mayql主从复制配置完成,可演示当,node2主节点掉线,由node3,4其中之一提升为新的主节点;

在node2:

]# killall mysqld mysqld_safe

在node4:

查看,可显示为已经更换了新的主节点;

实现当主节点掉线,从节点之中自动切换为一个新的主节点上来;此时,MHA已经完成mysql的主从自动切换;

当掉线的主节点再次加入到主从结构中时,要在新主节点上做一次备份,并且记录日志的名字和位置;把这个备份的内容导入到新增加的这个从节点上,让从节点从指定的位置开始往后复制即可;

时间: 2024-10-14 14:35:41

使用MHA对mysql主从架构中的主节点做高可用的相关文章

MySQL(三):MHA实现MySQL主从架构中主服务器的高可用,zabbix完成manager重启

MHA(Master High Availability)是目前在MySQL高可用方面相对成熟的一个解决方案,MHA在监控到master节点故障时,会提升其中拥有最新数据的slave节点成为新的master节点,在此期间,MHA会通过于其它从节点获取额外信息来避免一致性方面的问题.MHA还提供了master节点的在线切换功能. MHA 服务有两种角色,MHA Manager(管理节点)和 MHA Node(数据节点): MHA Manager:通常单独部署在一台独立机器上管理多个 master/

mysql-poxy 实现mysql主从架构读写分离

在高并发系统设计中,后端数据库的性能往往会成为系统的瓶颈,这时候就需要进行合理的设计,以分摊后端数据库的压力,比如在数据层前面构建缓存层.数据文件存放在RAID这样的设备.对数据进行分库分表分区存放.合理利用索引.进行数据的读写分离等.mysql-proxy提供了mysql数据库的读写分离能力,mysql-proxy通过Lua脚本能分析得出用户的sql请求,如果发现在是read请求,则会转化到master-slave模型的slave中,如果是write请求,则会转发到master中,以达到读写分

mysql主从同步中出现的问题梳理

之前部署了Mysql主从复制环境(MySQL复制环境(主从/主主)部署总结性梳理),在mysql同步过程中会出现很多问题,导致数据同步异常.以下梳理了几种主从同步中可能存在的问题:1)slave运行过慢不能与master同步,也就是MySQL数据库主从同步延迟MySQL数据库slave服务器延迟的现象是非常普遍的,MySQL复制允许从机进行SELECT操作,但是在实际线上环境下,由于从机延迟的关系,很难将读取操作转向到从机.这就导致了有了以下一些潜规则:"实时性要求不高的读取操作可以放到slav

MySQL 主从架构配置详解

无论是哪一种数据库,数据的安全都是至关重要的,因此熟练掌握数据库的安全备份功能,是作为开发人员,特别是后端开发人员的一项必备技能.MySQL 数据库内建的复制功能,可以帮助我们对数据进行异地备份,读写分离,在较大程度上避免数据丢失.数据库服务器压力过大甚至宕机带来的损失. 使用MySQL 主从架构一年多了,想起当年学习这些东西的时候,苦于完整的中文资料比较少,当时英文又不太好,遇到不少问题.刚好最近也有一段时间没更新博客了,心血来潮,决定翻译一下 MySQL 官网的英文文档,官网文档讲解的非常详

MySQL主从架构详解

1.复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

使用innobackupex基于从库搭建mysql主从架构

?? MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用Xtrabackup可以快速轻松的构建或修复mysql主从架构.本文描述了基于现有的从库来快速搭建主从,即作为原主库的一个新从库.该方式的好处是对主库无需备份期间导致的相关性能压力.搭建过程中使用了快速流备份方式来加速主从构建以及描述了加速流式备份的几个参数,供大家参考. 有关流式备份可以参考:Xtrabackup 流备份与恢复 1.备份从库###远程备份期间

MySQL主从架构之Master-Slave主从同步

MySQL复制 MySQL复制是指将主库上的DDL和DML操作通过二进制日志传到从库上,使主库和从库上的数据保持同步 MySQL主从架构:优点:故障时候可以切库:读写分离:从库执行其他业务例如备份. 1:Master-Slave    主从同步 2:Master-Slave-Slave……级联 3:Master-Master   互为主备 [主从同步]Master-Slave 注:需要主库打开log-bin ;设置server-id #mysqldump -uroot -p --all-data

使用Innobackupex快速搭建(修复)MySQL主从架构

MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用Xtrabackup可以快速轻松的构建或修复mysql主从架构.本文描述了使用innobackupex快速来搭建或修复主从架构.供大家参考. 1.基于主库做一个完整备份 # mkdir -p /log/bakforslave # innobackupex --user=root -password=*** --socket=/tmp/mysql.sock --def

SSM+MySQL开发架构中SQL mapper文件的解析和审计

SSM+MySQL已是Java开发的主流架构.在SSM+MySQL架构中,SQL一般写在mapper映射文件中,对于mapper文件的审计一直是个头疼的问题,测试人员很难覆盖mapper文件中动态SQL的所有情况,开发人员更是无法罗列每一个select id对应的所有SQL.在和开发同时沟通后,觉得自己可以写一个小工具来解决这一痛点!笔者作为一名DBA,自学了golang,经过七个月的努力初步完成了myaudit这一款实用性极强的SQLAudit小工具的开发,欢迎使用和吐槽,项目地址:https