首页 > 其他分享 >第十八章 MHA 高可用（一）

第十八章 MHA 高可用（一）

时间：2022-09-18 10:35:06浏览次数：62  
标签：log 可用 第十八章 MHA manager master db03 root

第十八章 MHA 高可用

1.准备三台机器
	IP：10.0.0.51  主机名：db01  内存：2G
	IP：10.0.0.52  主机名：db02  内存：2G
	IP：10.0.0.53  主机名：db03  内存：2G
2.优化

一、MHA概述

1.简介

MHA能够在较短的时间内实现自动故障检测和故障转移，通常在10-30秒以内;在复制框架中，MHA能够很好地解决复制过程中的数据一致性问题，由于不需要在现有的replication中添加额外的服务器，仅需要一个manager节点，而一个Manager能管理多套复制，所以能大大地节约服务器的数量;另外，安装简单，无性能损耗，以及不需要修改现有的复制部署也是它的优势之处。

MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群，也可以部署在一台Slave上。当Master出现故障时，它可以自动将最新数据的Slave提升为新的Master,然后将所有其他的Slave重新指向新的Master。整个故障转移过程对应用程序是完全透明的。

2.原理

当Master出现故障时，它可以自动将最新数据的Slave提升为新的Master,然后将所有其他的Slave重新指向新的Master。

整个故障转移过程对应用程序是完全透明的。

3.原理图解

#原理步骤
1.主库出现故障，立刻保存binlog（主库上的node节点）
2.对比多个从的relay-log找出数据最新的从库（从库上的node节点）
3.将数据最新的从库数据同步到其他从库
4.将数据最新的从库提升为主库（我们可以指定某一台机器优先提升为主库）
5.通过出现故障主库的binlog补全新的主库数据
6.其他从库重新做主从，以新的主库为主

#问题：
	1.如果主库断电，如何保存binlog，或者将binlog给新的主库同步？
	2.relay-log不是一直保存，执行完会删除，那如果删除怎么对比数据最新的从库？
	3.从库开启binlog，也不记录，那么提升为主库之后，从库如何同步？

4.MHA架构

#MHA架构特点：
1.MHA属于C/S结构（manager,node）
2.manager尽量避免和master主库放在一起
3.一个manager节点可以管理多套主从集群
4.所有的机器都要安装node节点
5.manager是通过ssh协议去管理node节点的，所以所有机器之间都要做ssh免密
6.MHA可以在mysql主从运行中添加，不影响mysql的使用
7.主库的binlog是node节点进行保存的
8.从库提升为主库也是由node节点完成的

二、MHA工具

1.manager相关工具

#解压源码包
[root@db01 ~]# tar xf mha4mysql-manager-0.56.tar.gz
#查看工具
[root@db01 ~]# ll mha4mysql-manager-0.56/bin/

#检查主从复制状态
masterha_check_repl
#检查ssh免密连接
masterha_check_ssh
#检查MHA启动状态
masterha_check_status
#配置主机信息的工具
masterha_conf_host
    [server2]
    hostname=10.0.0.52
    port=3306
    [server3]
    hostname=10.0.0.53
    port=3306
#manager的启动程序
masterha_manager
#监控MHA主节点状态
masterha_master_monitor
#切换主库
masterha_master_switch
#建立TCP连接工具
masterha_secondary_check
#停止MHA工具
masterha_stop

#我们手动需要使用的工具：
	masterha_check_repl
	masterha_check_ssh
	masterha_manager
	masterha_stop

2.node节点相关工具

#解压包
[root@db01 ~]# tar xf mha4mysql-node-0.56.tar.gz

#查看工具
[root@db01 ~]# ll mha4mysql-node-0.56/bin/

#对比从库的relay-log，选出数据最新的从库
apply_diff_relay_logs
#防止数据回滚
filter_mysqlbinlog
#删除relay-log，我们要关闭自动删除relay-log
purge_relay_logs
#保存binlog日志
save_binary_logs

三、MHA优点

1）Masterfailover and slave promotion can be done very quickly
自动故障转移快

2）Mastercrash does not result in data inconsistency
主库崩溃不存在数据一致性问题

3）Noneed to modify current MySQL settings (MHA works with regular MySQL)
不需要对当前mysql环境做重大修改

4）Noneed to increase lots of servers
不需要添加额外的服务器(仅一台manager就可管理上百个replication)

5）Noperformance penalty
性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
#ping www.baidu.com（icmp协议）
#sql ping 检测主库是否存活

6）Works with any storage engine
只要replication支持的存储引擎，MHA都支持，不会局限于innodb

四、部署MHA

1.环境准备

主机 IP 身份
db01 10.0.0.51 master
db02 10.0.0.52 slave
db03 10.0.0.53 slave，manager

2.做主从

1）配置三台机器

[root@db01 ~]# cat /etc/my.cnf
[mysqld]
server_id=1
log_bin=mysql-bin

[root@db02 ~]# cat /etc/my.cnf
[mysqld]
server_id=2
log_bin=mysql-bin

[root@db03 ~]# cat /etc/my.cnf
[mysqld]
server_id=3
log_bin=mysql-bin

2）授权主从用户

mysql> grant replication slave on *.* to rep@'172.16.1.%' identified by '123';
Query OK, 0 rows affected (0.00 sec)

3）查看binlog信息

mysql> show master status;
+------------------+----------+
| File             | Position |
+------------------+----------+
| mysql-bin.000004 |      120 |
+------------------+----------+

4）从库执行同步

#执行同步语句
change master to
master_host='172.16.1.51',
master_user='rep',
master_password='123',
master_log_file='mysql-bin.000004',
master_log_pos=120;

#启动线程
mysql> start slave;
Query OK, 0 rows affected (0.01 sec）

3.部署MHA之前的操作

1.检查主从状态
2.所有数据库配置关闭自动删除relay-log的功能
	#主库：
	mysql> set GLOBAL relay_log_purge=0;
	Query OK, 0 rows affected (0.00 sec)
	[root@db01 ~]# vim /etc/my.cnf
    [mysqld]
    relay_log_purge=0
    #从库
    [root@db02 ~]# vim /etc/my.cnf
    [mysqld]
    relay_log_purge=0
    [root@db03 ~]# vim /etc/my.cnf
    [mysqld]
    relay_log_purge=0
3.配置从库只读
	set global read_only=1;
4.检查三台机器server_id必须全都不相同
5.从库也要创建主从用户
	grant replication slave on *.* to rep@'172.16.1.%' identified by '123';
6.开启从库保存binlog
	[root@db01 ~]# vim /etc/my.cnf
    [mysqld]
    log_slave_updates
    [root@db02 ~]# vim /etc/my.cnf
    [mysqld]
    log_slave_updates
    [root@db03 ~]# vim /etc/my.cnf
    [mysqld]
    log_slave_updates
    #重启从库
    [root@db02 ~]# systemctl restart mysqld
    [root@db03 ~]# systemctl restart mysqld


#三台机器配置文件

#主库
[root@db01 ~]# vim /etc/my.cnf
[mysqld]
server_id=1
innodb_data_file_path=ibdata1:76M;ibdata2:12M:autoextend
log_bin=mysql-bin
relay_log_purge=0
log_slave_updates

#从库1
[root@db02 ~]# vim /etc/my.cnf
[mysqld]
server_id=2
log_bin=mysql-bin
relay_log_purge=0
log_slave_updates

#从库2
[root@db03 ~]# vim /etc/my.cnf
[mysqld]
server_id=3
log_bin=mysql-bin
relay_log_purge=0
log_slave_updates

4.部署MHA

1）安装依赖（所有机器）

[root@db01 ~]# yum install perl-DBD-MySQL -y
[root@db02 ~]# yum install perl-DBD-MySQL -y
[root@db03 ~]# yum install perl-DBD-MySQL -y

2）安装manager节点依赖（db03）

[root@db03 ~]# yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

3）安装node节点（所有机器）

#上传代码包
[root@db01 ~]# rz mha4mysql-manager-0.56-0.el6.noarch.rpm
[root@db02 ~]# rz mha4mysql-manager-0.56-0.el6.noarch.rpm
[root@db03 ~]# rz mha4mysql-manager-0.56-0.el6.noarch.rpm

#安装
[root@db01 ~]# yum localinstall -y mha4mysql-node-0.56-0.el6.noarch.rpm
[root@db02 ~]# yum localinstall -y mha4mysql-node-0.56-0.el6.noarch.rpm
[root@db03 ~]# yum localinstall -y mha4mysql-node-0.56-0.el6.noarch.rpm

4）部署manager节点（db03）

#上传代码包
[root@db03 ~]# rz mha4mysql-manager-0.56-0.el6.noarch.rpm

#安装
[root@db03 ~]# yum localinstall -y mha4mysql-manager-0.56-0.el6.noarch.rpm

5）添加一个MHA管理数据库的用户（所有机器）

#主库执行即可 应为主从同步数据了
mysql> grant all on *.* to mha@'172.16.1.%' identified by 'mha';
Query OK, 0 rows affected (0.01 sec)

6）配置软连接

#如果不能直接执行数据库命令的时候，如果不创建命令软连接，检测mha复制情况的时候会报错
[root@db03 ~]# ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
[root@db03 ~]# ln -s /application/mysql/bin/mysql /usr/bin/mysql

7）编写MHA配置文件（db03）

#创建存放配置文件的目录
[root@db03 ~]# mkdir /service/mha -p

#编辑配置文件
[root@db03 ~]# vim /service/mha/app1.cnf
#注释
[root@db01 ~]# cat /service/mha/app1.cnf 
#默认配置
[server default]
#自定义日志文件
manager_log=/service/mha/manager
#自定义工作目路
manager_workdir=/service/mha/app1
#主库的binlog目录
master_binlog_dir=/usr/local/mysql/data
#MHA管理数据库的用户
user=mha
#MHA管理数据库的用户密码
password=mha
#检测主库存活的间隔时间
ping_interval=2
#主从复制的用户
repl_user=rep
#主从复制的密码
repl_password=123
#指定ssh免密的用户
ssh_user=root

#指定主机
[server1]
hostname=172.16.1.51
port=3306

[server2]
#candidate_master=1
#check_repl_delay=0
hostname=172.16.1.52
port=3306

[server3]
hostname=172.16.1.53
port=3306

candidate_master=1
#默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master
check_repl_delay=0

8）创建工作目录

[root@db03 ~]# mkdir /service/mha/app1

9）配置服务器免密

#创建秘钥对
[root@db01 ~]# ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1
[root@db02 ~]# ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1
[root@db03 ~]# ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1

#发送公钥，包括自己
[root@db01 ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
[root@db02 ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
[root@db03 ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]

10）启动前检测

1.检查ssh免密
[root@db03 ~]# masterha_check_ssh --conf=/service/mha/app1.cnf

2.检查主从状态
[root@db03 ~]# masterha_check_repl --conf=/service/mha/app1.cnf
#如果报错，可能是没有配置反向解析，所有节点都要配置
[root@db01 ~]# vim /etc/my.cnf
skip-name-resolve

11）启动MHA

[root@db03 ~]# nohup masterha_manager --conf=/service/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /service/mha/app1/manager.log 2>&1 &

nohup 									#后台启动
masterha_manager 						#MHA启动程序
--conf=/service/mha/app1.cnf 			  #指定配置文件
--remove_dead_master_conf 				  #移除死掉的主节点配置
--ignore_last_failover 					  #忽略最后一次切换
< /dev/null > /service/mha/app1/manager.log 2>&1 &		#把日志写入到指定文件

#安全机制
	1.完成一次切换后，会生成一个锁文件
	2.再次进行切换时，会检查锁文件
	3.如果锁文件存在，则不能进行切换，8小时后才能进行再次切换

12）查看日志测试切换

#监控日志
[root@db03 ~]# tail -f /service/mha/manager

#停掉主库
[root@db01 ~]# systemctl stop mysqld

标签：log,可用,第十八章,MHA,manager,master,db03,root
From： https://www.cnblogs.com/GAO321/p/16704322.html

相关文章

  • docker 高可用集群搭建 sentinel
    1首先先准备3份配置文件redis6380.confredis6381.confredis6382.conf修改里面的端口号2分别启动三台redis这里设置redis6380为master因此我们启动第一台re......
  • 22-Nginx高可用(基于Keepalived实现双机主备)
    双机主备HA其实就是高可用,现在部署的其实就是一台Nginx,但凡是单节点,都会存在宕机的可能性,所以我们需要一个备用机,来完成高可用,解决单点故障问题Keepalived......
  • CVTE 2023 校园招聘 内推（后续持续可用）
    【内推方式】内推码为：[email protected] （邮箱就是内推码）1.登陆campus.cvte.com网申2.进入个人中心报名选择“2023秋季校园招聘”3.招聘信息来......
  • Redis的高可用Sentinel
    Redis的高可用Sentinel什么是SentinelRedis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的......
  • 干货 | 仅需4步，即可用 Docker搭建测试用例平台 TestLink
    ⬇️点击“下方链接”，提升测试核心竞争力！>>更多技术文章分享和免费资料领取本文节选自霍格沃兹测试学院内部教材Testlink是基于WEB的测试用例管理系统，主要功能是：测试......
  • keepalived结合nfs实现生产环境高可用
    keepalived结合nfs实现生产环境高可用-oldlai1、服务器无可厚非会遇到意外宕机的情况，如果服务端出现故障，那么客户端挂载的目录将不可用，如果这个目录是挂载给用户作为静态......
  • MHA实战案例
    一、机器环境准备MHA：192.168.247.150 2vcpu2G centos7master:192.168.247.1512vcpu4Grocky8.6 mysql8.0.26slave-01:192.168.247.1522vcpu4Grocky8.6 ......
  • kubelet忽然不可用
    原因，有可能机器的cpu信息有变化（扩容或者缩容）解决办法：删掉/opt/var/lib/kubelet目录下（或者/data/lib/kubelet）cpu_manager_state文件然后monitrestartkubelet（或者sys......
  • keepalived实现lvs高可用
    keeplaived实现lvs高可用名称ipnode1(lvs,keepalived)192.168.6.152node2(lvs,keepalived)192.168.6.153rs1192.168.6.135rs2192.168.6.154#在......
  • CDH开启高可用后，NameNode主备节点切换
    获取NamenodeID查看nn1的状态hdfshaadmin-getServiceStatenamenode30#standbyhdfshaadmin-getServiceStatenamenode37#active修改nn2为standby状态hdf......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99