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

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

MHA(Master High Availability)是目前在MySQL高可用方面相对成熟的一个解决方案,MHA在监控到master节点故障时,会提升其中拥有最新数据的slave节点成为新的master节点,在此期间,MHA会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能。


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

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

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


环境

本次实验环境共有四个节点,其角色分配如下所示。

manager: MHA Manager

master:  MariaDB master

slave1:  MariaDB slave

slave2:  MariaDB slave


修改各节点名字,各节点的/etc/hosts 文件配置内容中添加:

172.16.1.2 manager.zrs.com manager

172.16.1.3 master.zrs.com master

172.16.1.4 slave1.zrs.com slave1

172.16.1.5 slave2.zrs.com slave2


初始主节点master配置:

server_id=1

relay_log=relay-log

log_bin=master-log


节点slave1的配置:

server_id=2 

relay_log=relay-log

log_bin=master-log

relay_log_purge=0

read_only=1


节点slave2的配置:

server_id=3

relay_log=relay-log

log_bin=master-log

relay_log_purge=0

read_only=1


下面进行主从复制架构


主服务器

授权从服务器,并刷新

MariaDB [(none)]> grant replication slave,replication client on *.* to 'repluser'@'172.16.1.4'identified by 'replpass';


MariaDB [(none)]> grant replication slave,replication client on *.* to 'repluser'@'172.16.1.5'identified by 'replpass';


MariaDB [(none)]>  flush privileges;


从服务器配置

两个slave都指定主服务器

MariaDB [(none)]> change master to master_host='172.16.1.3',master_user='repluser',master_password='replpass',master_log_file='binlog.000003',master_log_pos=245;


开启io线程和sql线程

MariaDB [(none)]> start slave io_thread;

MariaDB [(none)]> start slave sql_thread;


在所有MySQL节点授权

MariaDB [(none)]> GRANT ALL ON *.* TO 'mhamngr'@'172.16.1.%' IDENTIFIED BY 'mhapass';


建立免钥通信

MHA集群中的各节点彼此之间均需要基于ssh互信通信,以实现远程控制及数据管理功能。可在Manager节点生成密钥对,并设置其可远程连接本地主机后,将私钥文件及authorized_keys文件复制给余下的所有节点即可。


[root@manager ~]# ssh-keygen -t rsa -P ''

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): .ssh/id_rsa          

Your identification has been saved in .ssh/id_rsa.

Your public key has been saved in .ssh/id_rsa.pub.

The key fingerprint is:

80:59:23:b9:f8:ce:7e:86:66:ad:23:82:b3:d9:a8:81 root@manager.zrs.com

The key's randomart image is:

+--[ RSA 2048]----+

|    ..o          |

|    .= .         |

|   .o..          |

|  . .  .         |

|   .    S        |

|.   .            |

|E  o o           |

|+=. B +          |

|*+.=o=           |

+-----------------+


[root@manager ~]# cat .ssh/id_rsa.pub >> .ssh/authorized_keys

[root@manager ~]# chmod go= .ssh/authorized_keys


[root@manager ~]# scp -p .ssh/id_rsa .ssh/authorized_keys root@master:/root/.ssh/

The authenticity of host 'master (172.16.1.3)' can't be established.

ECDSA key fingerprint is 65:f7:d6:d7:ae:3b:a2:dc:2b:bc:33:64:0e:47:11:b4.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'master' (ECDSA) to the list of known hosts.

root@master's password: 

id_rsa                                                100% 1675     1.6KB/s   00:00    

authorized_keys                                       100%  402     0.4KB/s   00:00    


[root@manager ~]# scp -p .ssh/id_rsa .ssh/authorized_keys root@slave1:/root/.ssh/

The authenticity of host 'slave1 (172.16.1.4)' can't be established.

ECDSA key fingerprint is eb:b4:c4:c4:aa:15:2c:f8:6b:e8:cc:59:75:7a:a5:89.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'slave1' (ECDSA) to the list of known hosts.

root@slave1's password: 

id_rsa                                                100% 1675     1.6KB/s   00:00    

authorized_keys                                       100%  402     0.4KB/s   00:00    


[root@manager ~]# scp -p .ssh/id_rsa .ssh/authorized_keys root@slave2:/root/.ssh/

The authenticity of host 'slave2 (172.16.1.5)' can't be established.

ECDSA key fingerprint is be:2f:9f:d7:f8:2e:09:b1:7d:29:c2:76:53:0f:d2:94.

Are you sure you want to continue connecting (yes/no)? yes 

Warning: Permanently added 'slave2,172.16.1.5' (ECDSA) to the list of known hosts.

root@slave2's password: 

id_rsa                                                100% 1675     1.6KB/s   00:00    

authorized_keys                                       100%  402     0.4KB/s   00:00    


安装MHA

除了源码包,MHA官方也提供了rpm格式的程序包,其下载地址为https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。这次安装是使用的rpm格式,在manager和node的所有节点均需安装MHA Node。


安装 MHA Manager


rpm安装方式:

[root@manager ~]# yum install perl-DBD-MySQLperl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager

[root@manager ~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

[root@manager ~]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm


tar包安装方式:

tar -zxf mha4mysql-manager-0.56.tar.gz

cd mha4mysql-manager-0.56

perl Makefile.PL

make

make install


安装 MHA Node


rpm安装方式:

~]# yum install perl-DBD-MySQL

~]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm


tar包安装方式:

tar -zxfmha4mysql-node-0.56.tar.gz

cd mha4mysql-node-0.56

perl Makefile.PL

make

make install


初始化 MHA

Manger节点需要为每个监控的master/slave集群提供一个专用的配置文件,而所有的master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf,其为可选配置。如果仅监控一组 master/slave集群,也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义,本次实验将使用/etc/masterha/app1.cnf


[server default]

user=mhamngr

password=mhapass

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=replpass

ping_interval=1


[server1]

hostname=172.16.1.3

candidate_master=1


[server2]

hostname=172.16.1.4

candidate_master=1


[server3]

hostname=172.16.1.5



检测各节点间ssh互信通信配置是否正常


[root@manager ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf


看到输出的信息中,最后一行显示如下,表示其通过检测。

[info] All SSH connection tests passed successfully.


检查管理的MySQL复制集群的连接配置参数是否正常


[root@manager ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf


看到输出的信息中,最后一行显示如下,表示其通过检测。

MySQL Replication Health is OK.


启动MHA

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &


查看master节点的状态

[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf

app1 (pid:23265) is running(0:PING_OK), master:172.16.1.3

[root@manager ~]# 


停止MHA

[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf

Stopped app1 successfully.



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

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 线程):

自定义扩展:

- secondary_check_script:通过多条网络路由检测 master 的可用性;

- master_ip_failover_script:更新 application 使用的 masterip;

- shutdown_script:强制关闭 master 节点;

- report_script:发送报告;

- init_conf_load_script:加载初始配置参数;

- master_ip_online_change_script:更新 master 节点 ip 地址;


测试故障转移

在master节点上面关闭mariadb服务

[root@master ~]# killall -9 mysqld mysqld_safe


查看日志发现,172.16.1.3这个节点down了,172.16.1.4提升为master。



使用zabbix完成masterha-manager重新启动


大致步骤


略过zabbix server和agent端的安装步骤,我在manager主机上同时安装了zabbix server和zabbix agent,监控刚才设置的nohup启动的manager管理进程,一旦发现这个后台命令执行结束了,立即通过zabbix里面设置的条件和触发器,来调用脚本,使得manager进程始终运行在manager上。


在agent上需要完成的配置:


1.zabbix用户拥有所需要的管理权限


编辑/etc/sudoers文件

注释如下行:因为系统默认是要能够通过tty登陆的用户,执行命令,zabbix没有可以登录系统的权限,所以要把这个注释

添加如下行:这样做不怎么安全,生产环境下,要用更为安全的方法


#Defaults requiretty 

zabbix ALL=(ALL)NOPASSWD:ALL


2.agent进程要允许执行远程命令

开启远程命令,即将/etc/zabbix/zabbix_agentd.conf配置文件中的该配置设置为1即可。

EnableRemoteCommands=1


3.开启服务

[root@manager ~]# systemctl start zabbix-agent.service


4.在客户端的界面上设置Hosts,items,Triggers,Actions(Action,Conditions,Operations),

需要注意的是Operations需要设置Commands调用脚本来启动MHA程序

[root@manager ~]# cat mannager.sh

nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &


5.可以测试zabbix是否根据设置的事务动作,完成脚本的调用,完成manager的后台启动


关闭nohup执行的进程用

[root@manager ~]# kill -9 +id     #这个id号需要先查询


手动get获取:

[root@manager ~]# zabbix_get -s 172.16.1.2 -k masterha.manager

2


再次get获取:

[root@manager ~]# zabbix_get -s 172.16.1.2 -k masterha.manager

0


当这里显示是0了,同时通过ps命令可以查看这个进程确实已经启动了,于是使用zabbix完成masterha-manager重新启动就成功了。


zabbix_get是在命令行下获取数值的zabbix命令:

-s   要查的ip地址,本地或者远程的都可以

-p   zabbix_agentd的端口

-k   key值




本文转自 Runs_ 51CTO博客,原文链接:http://blog.51cto.com/12667170/2062222,如需转载请自行联系原作者
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
存储 机器学习/深度学习 数据库
阿里云服务器X86/ARM/GPU/裸金属/超算五大架构技术特点、场景适配参考
在云计算技术飞速发展的当下,云计算已经渗透到各个行业,成为企业数字化转型的关键驱动力。选择合适的云服务器架构对于提升业务效率、降低成本至关重要。阿里云提供了多样化的云服务器架构选择,包括X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等。本文将深入解析这些架构的特点、优势及适用场景,以供大家了解和选择参考。
305 61
|
3月前
|
存储 机器学习/深度学习 应用服务中间件
阿里云服务器架构解析:从X86到高性能计算、异构计算等不同架构性能、适用场景及选择参考
当我们准备选购阿里云服务器时,阿里云提供了X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等多种架构,每种架构都有其独特的特点和适用场景。本文将详细解析这些架构的区别,探讨它们的主要特点和适用场景,并为用户提供选择云服务器架构的全面指南。
578 18
|
4月前
|
弹性计算 负载均衡 Java
【上云基础系列 02-01】通过SLB+1台ECS+ESS弹性伸缩,搭建一个精简版的上云标准弹性架构(含方案及教程)
通常,构建一个弹性架构(即使是一个最基础的入门版),至少需要2台ECS。但是,很多小微企业刚开始上云的时候,为了节省成本不愿意购买更多的服务器。通过 “ALB+ESS弹性伸缩+1台ECS+RDS”方案,在保障低成本的同时,也不牺牲业务架构的弹性设计,更避免了很多人因为节省成本选择了单体架构后频繁改造架构的困局。 方案中的几个设计非常值得小微企业借鉴:(1)通过ALB/RDS的按量付费,节省了初期流量不大时的费用;(2)通过ESS弹性伸缩,不需要提前购买服务器资源,但是当业务增长或减少时却保持了资源弹性自动扩缩容。
|
4月前
|
Kubernetes 监控 Serverless
基于阿里云Serverless Kubernetes(ASK)的无服务器架构设计与实践
无服务器架构(Serverless Architecture)在云原生技术中备受关注,开发者只需专注于业务逻辑,无需管理服务器。阿里云Serverless Kubernetes(ASK)是基于Kubernetes的托管服务,提供极致弹性和按需付费能力。本文深入探讨如何使用ASK设计和实现无服务器架构,涵盖事件驱动、自动扩展、无状态设计、监控与日志及成本优化等方面,并通过图片处理服务案例展示具体实践,帮助构建高效可靠的无服务器应用。
|
4月前
|
存储 人工智能 并行计算
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
|
5月前
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器ECS架构区别及选择参考:X86计算、ARM计算等架构介绍
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别,本文主要简单介绍下这些架构各自的主要性能及适用场景,以便大家了解不同类型的架构有何不同,主要特点及适用场景有哪些。
820 10
|
5月前
|
存储 人工智能 运维
面向AI的服务器计算软硬件架构实践和创新
阿里云在新一代通用计算服务器设计中,针对处理器核心数迅速增长(2024年超100核)、超多核心带来的业务和硬件挑战、网络IO与CPU性能增速不匹配、服务器物理机型复杂等问题,推出了磐久F系列通用计算服务器。该系列服务器采用单路设计减少爆炸半径,优化散热支持600瓦TDP,并实现CIPU节点比例灵活配比及部件模块化可插拔设计,提升运维效率和客户响应速度。此外,还介绍了面向AI的服务器架构挑战与软硬件结合创新,包括内存墙问题、板级工程能力挑战以及AI Infra 2.0服务器的开放架构特点。最后,探讨了大模型高效推理中的显存优化和量化压缩技术,旨在降低部署成本并提高系统效率。
|
6月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
7月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
166 3
|
2月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
201 12

推荐镜像

更多