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/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文件复制给余下的所有节点即可。

[[email protected] ~]# 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 [email protected]

The key's randomart image is:

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

|    ..o          |

|    .= .         |

|   .o..          |

|  . .  .         |

|   .    S        |

|.   .            |

|E  o o           |

|+=. B +          |

|*+.=o=           |

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

[[email protected] ~]# cat .ssh/id_rsa.pub >> .ssh/authorized_keys

[[email protected] ~]# chmod go= .ssh/authorized_keys

[[email protected] ~]# scp -p .ssh/id_rsa .ssh/authorized_keys [email protected]:/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.

[email protected]'s password:

id_rsa                                                100% 1675     1.6KB/s   00:00

authorized_keys                                       100%  402     0.4KB/s   00:00

[[email protected] ~]# scp -p .ssh/id_rsa .ssh/authorized_keys [email protected]:/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.

[email protected]'s password:

id_rsa                                                100% 1675     1.6KB/s   00:00

authorized_keys                                       100%  402     0.4KB/s   00:00

[[email protected] ~]# scp -p .ssh/id_rsa .ssh/authorized_keys [email protected]:/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.

[email protected]'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安装方式:

[[email protected] ~]# yum install perl-DBD-MySQLperl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager

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

[[email protected] ~]# 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互信通信配置是否正常

[[email protected] ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

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

[info] All SSH connection tests passed successfully.

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

[[email protected] ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf

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

MySQL Replication Health is OK.

启动MHA

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

查看master节点的状态

[[email protected] ~]# masterha_check_status --conf=/etc/masterha/app1.cnf

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

[[email protected] ~]#

停止MHA

[[email protected] ~]# 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服务

[[email protected] ~]# 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.开启服务

[[email protected] ~]# systemctl start zabbix-agent.service

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

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

[[email protected] ~]# cat mannager.sh

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

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

关闭nohup执行的进程用

[[email protected] ~]# kill -9 +id     #这个id号需要先查询

手动抓取一次:

[[email protected] ~]# zabbix_get -s 172.16.1.2 -k masterha.manager

2

再次手动抓起一次:

[[email protected] ~]# 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值

原文地址:http://blog.51cto.com/12667170/2062221

时间: 2025-01-07 00:09:23

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

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

MHA:Master HA(主从结构的高可用方案)只是实现了对主节点高可用,它是建构在mysql主从复制结构之上的,也就是说需要事先把mysq配置成传统的复制集群. MHA在监控到master节点故障时,会提升其中拥有最新数据的slave节点称为新的master,在此期间,MHA会通过其它从节点获取额外信息来避免一致性方面的问题.MHA还提供了master节点在线切换的功能,即按需切换master/salve节点. MHA服务有两种角色,MHA Manager(管理节点)和MHA Node(数据

MySQL双主+keepalived实现高可用

mysql+keepalived实现高可用+主主复制模式 为了解决mysql的单点故障问题,衍生出很多mysql的高可用方案: keepalived+双主.MHA.PXC.MMM.Hearbeat+DRBD等,比较常用的一般是keepalived+双主,MHA和PXC 在此搭建实验环境,实现keepalived+mysql双主模式. 实验思路: 两台MySQL互为主从关系(双主),通过keepalived配置虚拟vip,实现当其中的一台MySQL数据库宕机后,应用能自动切换到另外一台MySQL数

通过KeepAlived搭建MySQL双主模式的高可用集群系统

企业级MySQL集群具备高可用.可扩展.易管理.低成本的特点.下面将介绍企业环境中经常应用的一个解决方案,即MySQL的双主互备架构,主要设计思路是通过MySQL Replication技术将两台MySQL Server互相将对方作为自己的Master,自己又同时作为对方的Slave来进行复制.这样就实现了高可用构架中的数据同步功能,同时,将采用KeepAlived来实现Mysql的自动failover.在这个构架中,虽然两台MySQL Server互为主从,但同一时刻只有一个MySQL Ser

Mysql+Keepalived双主热备高可用操作步骤详细解析

mysql+keepalived双主热备高可用的介绍: 我们通常说的双机热备是指两台机器都在运行,但并不是两台机器都同时在提供服务.当提供服务的一台出现故障的时候,另外一台会马上自动接管并且提供服务,而且切换的时间非常短.MySQL双主复制,即互为Master-Slave(只有一个Master提供写操作),可以实现数据库服务器的热备,但是一个Master宕机后不能实现动态切换.使用Keepalived,可以通过虚拟IP,实现双主对外的统一接口以及自动检查.失败切换机制,从而实现MySQL数据库的

[转帖]【MySQL+keepalived】用keepalived实现MySQL主主模式的高可用

[MySQL+keepalived]用keepalived实现MySQL主主模式的高可用 https://www.jianshu.com/p/8694d07595bc 一.实验说明 MySQL主主模式,是两台MySQL数据库互为主从. 此实验是用keepalived实现MySQL主主模式的高可用,基于已经安装好了主主架构的MySQL,然后配置keepalived,验证高可用性! 二.实验环境 操作系统:CentOS 7.5 serverA:192.168.1.104 serverB: 192.1

Mysql+keeoalived双主热备高可用操作记录

我们通常说的双机热备是指两台机器都在运行,但并不是两台机器都同时在提供服务.当提供服务的一台出现故障的时候,另外一台会马上自动接管并且提供服务,而且切换的时间非常短.之前梳理了Mysql主从同步,下面说下Mysql+keeoalived双主热备高可用方案的实施. 1)Keepalived的工作原理是VRRP(Virtual Router Redundancy Protocol)虚拟路由冗余协议.在VRRP中有两组重要的概念:VRRP路由器和虚拟路由器,主控路由器和备份路由器. 2)VRRP路由器

DNS服务解析,如何用bind构建主从架构的DNS服务器。

DNS(Domain Name System,域名系统) 在互联网上实现FQDN与IP地址的解析,这样避免了人们在访问站点时,记忆长串难懂的ip地址,只需要记忆人们容易理解的域名就行了. FQDN (Fully Qualified Domain Name,完全合格域名) FQDN------------------IP Address 正向解析 IP Address------------FQND 反向解析 简述工作原理: 我们大家都知道,全球一共有13台根节点服务器,当我们的DNS服务器收到一

Mysql+Keepalived双主热备高可用操作记录

环境: ubuntu18.04.2 mysql5.7.21 1 #1)安装keepalived并将其配置成系统服务.master1和master2两台机器上同样进行如下操作: 2 apt-get install libssl-dev 3 apt-get install openssl 4 apt-get install libpopt-dev 5 [[email protected] ~]# cd /usr/local/src/ 6 [[email protected] src]# wget h

Memcached主主复制+Keepalived高可用架构(内含所有源码包)

初步了解memcached主主复制: Memcached主主复制是指在任意一台memcached服务器修改数据都会被同步到另外一台,但是memcached API客户端是无法判断连接到哪一台memcached服务器的,所以需要设置VIP地址,提供给memcached API客户端进行连接.可以使用keepalived产生的VIP地址连接主memcached服务器,并且提供高可用架构.Memcached的复制功能支持多个memcached之间进行相互复制(双向复制,主备都是可读可写的),可以解决m