MySQL高可用之MHA—部署MHA

前提

由于MHA不会自动创建主从环境,所以要手动去部署主从环境,也可以在现有主从环境部署MHA。所有slave不要设置为只读,同时也要打开binlog。如果master故障后要切换到指定的slave上,该指定的slave打开binlog,设置可读写,其它不用设置打开binlog或设置只读也可。具体以自身架构为准。

部署MySQL主从可参考:配置MySQL主从复制

架构

系统环境

#cat /etc/redhat-release

CentOSrelease 6.6 (Final)

#uname -rm

2.6.32-504.el6.x86_64x86_64

创建MHA用户

在主从环境的主上执行

mysql>grant  all privileges on *.* to ‘mha‘@‘192.168.56.%‘ identified by ‘123456‘;

创建软连接

如果MySQL服务不是yum安装,要在所有MySQLServer上,无论主从都要执行如下两个命令。

# ln-s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog

# ln-s /application/mysql/bin/mysql /usr/bin/mysql

配置SSH公钥认证

几台服务器进行相同操作,仅分发到的服务不同而已,这里仅列出一台。

###

添加统一用户

在生产环境下使用root用户不安全,也不规范。并且环境统一也比较方便管理,因此可以创建统一的普通用户来进行。

#####

创建密钥对

[[email protected] ~]#ssh-keygen -t dsa

将公钥分发到各个主机上

[[email protected] ~]#ssh-copy-id -i .ssh/id_dsa.pub [email protected]

[[email protected] ~]#ssh-copy-id -i .ssh/id_dsa.pub [email protected]

[[email protected] ~]#ssh-copy-id -i .ssh/id_dsa.pub [email protected]

验证

[[email protected] ~]# ssh   [email protected]

Last login: Thu May 1921:05:07 2016 from mysql-master

[[email protected] ~]# exit

[[email protected] ~]# ssh  [email protected]

Last login: Wed May 1812:43:20 2016 from 172.16.1.1

[[email protected] ~]# exit

[[email protected] ~]# ssh  [email protected]

Last login: Wed May 1817:56:40 2016 from 172.16.1.1

[[email protected] ~]# exit

配置hosts

[[email protected] ~]# vim   /etc/hosts

192.168.56.11  mha-manager

192.168.56.12  mysql-master

192.168.56.13  mysql-slave01

192.168.56.14  mysql-slave02

[email protected] ~]# scp   /etc/hosts   [email protected]:/etc/

hosts                                                  100%  271     0.3KB/s  00:00

[[email protected] ~]# scp   /etc/hosts   [email protected]:/etc/

hosts                                                  100%  271     0.3KB/s  00:00

[[email protected] ~]# scp   /etc/hosts [email protected]:/etc/

hosts                                                  100%  271     0.3KB/s  00:00

部署MHANode

在所有运行MySQL服务的服务器上运行MHA Node,无论是master还是slave。由于MHA Manager需要MHA Node,因此在运行MHA Manager的服务器上也需要安装MHA Node。当然也可以在任意一个slave上运行MHA Manager。因为部署步骤相同,所以就列出一个安装步骤(在mha-manager服务器上)

创建目录

[[email protected] ~]# mkdir   /softs

安装MHA Node

[[email protected] ~]# rpm-ivh  http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

[[email protected] ~]# yum install -y perl-DBD-MySQL perl-DBI cpan

[[email protected] ~]# cd/softs/

[[email protected] softs]# git    clone https://github.com/kevin-hao/mha-node.git

[[email protected] softs]# cd   mha-node/

[[email protected] mha-node]#perl Makefile.PL

[[email protected]mha-node]#make && make install

[[email protected] mha-node]#cd

其它MySQL服务器上的部署步骤一样,再次省略。

部署MHAManager

MHA Manager仅运行在作为manager的服务器上。当然也可以部署在其中任意一台slave上。

安装MHA Manager

[[email protected] ~]# yum   install -y perl perl-Config-Tiny perl-Email-Date-Forma perl-Log-Dispatch perl-MIME-Liteperl-MIME-Types perl-Mail-Sender perl-Mail-Sendmail perl-MailTools perl-Parallel-ForkManagerperl-Params-Validate perl-Time-HiRes perl-TimeDate

[[email protected] ~]# cd  /softs/

[[email protected] softs]# git   clone https://github.com/kevin-hao/mha-manager.git

[[email protected] softs]# cd  mha-manager/

[[email protected] mha-manager]#perl Makefile.PL

[[email protected] mha-manager]#make && make install

[[email protected] mha-manager]#cd

规范mha目录

[[email protected] ~]# mkdir -p /application/mha/conf

[[email protected] ~]# cp   /softs/mha-manager/samples/conf/* /application/mha/conf/

配置app1.cnf

[[email protected] ~]#mkdir  -p /application/mha/workstatus/app1

[[email protected] ~]# cd   /application/mha/conf/

[[email protected] conf]# cp   app1.cnf app1.cnf.ori

[[email protected] conf]# vim   app1.cnf

[server default]

port=3306

user=mha

password=123456

repl_user=repuser

repl_password=123456

remote_workdir=/var/log/mha/app1

master_binlog_dir=/data/mysql_log/

manager_workdir=/application/mha/workstatus/app1

manager_log=/application/mha/logs/app1.log

[server1]

hostname=mysql-master

[server2]

hostname=mysql-slave01

candidate_master=1

[server3]

hostname=mysql-slave02

candidate_master=1

配置全局配置文件

[[email protected] conf]# cp   masterha_default.cnf masterha_default.cnf.ori

[[email protected] conf]# vim  masterha_default.cnf

[server default]

log-level=debug

check_repl_delay=1

check_repl_filter=1

ping_interval=5

ping_type=CONNECT

[[email protected] conf]# cd

检查配置

操作在mha-manager上进行

检查ssh连接性

[[email protected] ~]#masterha_check_ssh --conf=/application/mha/conf/app1.cnf

Wed May 25 23:12:39 2016 -[warning] Global configuration file /etc/masterha_default.cnf not found.Skipping.

Wed May 25 23:12:39 2016 -[info] Reading application default configuration from/application/mha/conf/app1.cnf..

Wed May 25 23:12:39 2016 -[info] Reading server configuration from /application/mha/conf/app1.cnf..

Wed May 25 23:12:39 2016 -[info] Starting SSH connection tests..

Wed May 25 23:12:40 2016 -[debug]

Wed May 25 23:12:39 2016 -[debug]  Connecting via SSH [email protected](192.168.56.12:22) to [email protected](192.168.56.13:22)..

Wed May 25 23:12:40 2016 -[debug]   ok.

Wed May 25 23:12:40 2016 -[debug]  Connecting via SSH [email protected](192.168.56.12:22) to [email protected]slave02(192.168.56.14:22)..

Wed May 25 23:12:40 2016 -[debug]   ok.

Wed May 25 23:12:41 2016 -[debug]

Wed May 25 23:12:40 2016 -[debug]  Connecting via SSH [email protected](192.168.56.13:22) to [email protected](192.168.56.12:22)..

Wed May 25 23:12:40 2016 -[debug]   ok.

Wed May 25 23:12:40 2016 -[debug]  Connecting via SSH [email protected](192.168.56.13:22) to [email protected](192.168.56.14:22)..

Wed May 25 23:12:41 2016 -[debug]   ok.

Wed May 25 23:12:41 2016 -[debug]

Wed May 25 23:12:40 2016 -[debug]  Connecting via SSH [email protected](192.168.56.14:22) to [email protected](192.168.56.12:22)..

Wed May 25 23:12:41 2016 -[debug]   ok.

Wed May 25 23:12:41 2016 -[debug]  Connecting via SSH [email protected](192.168.56.14:22) to [email protected](192.168.56.13:22)..

Wed May 25 23:12:41 2016 -[debug]   ok.

Wed May 25 23:12:41 2016 -[info] All SSH connection tests passed successfully.

检查主从复制状态

[[email protected] ~]# masterha_check_repl--conf=/application/mha/conf/app1.cnf

***********中间省略*************

Wed May 25 23:13:19 2016 -[info]

mysql-master(192.168.56.12:3306)(current master)

+--mysql-slave01(192.168.56.13:3306)

+--mysql-slave02(192.168.56.14:3306)

Wed May 25 23:13:19 2016 -[info] Checking replication health on mysql-slave01..

Wed May 25 23:13:19 2016 -[info]  ok.

Wed May 25 23:13:19 2016 -[info] Checking replication health on mysql-slave02..

Wed May 25 23:13:19 2016 -[info]  ok.

Wed May 25 23:13:19 2016 -[warning] master_ip_failover_script is not defined.

Wed May 25 23:13:19 2016 -[warning] shutdown_script is not defined.

Wed May 25 23:13:19 2016 -[info] Got exit code 0 (Not master dead).

MySQL Replication Health isOK.   <=====表明当前app1的主从环境正常

启动manager

[[email protected] ~]# mkdir/application/mha/logs

[[email protected] ~]#masterha_manager --conf=/application/mha/conf/app1.cnf >/dev/null2>&1 &

检查manager状态

[[email protected] ~]#masterha_check_status --conf=/application/mha/conf/app1.cnf

app1 (pid:27335) isrunning(0:PING_OK), master:mysql-master

master故障切换测试

在master上停止mysqld进程,然后查看log可以看出进行了切换。

[[email protected] ~]#/etc/init.d/mysqld stop

[[email protected] ~]# tail-F /application/mha/logs/app1.log

----- Failover Report -----

app1: MySQL Master failovermysql-master(192.168.56.12:3306) to mysql-slave01(192.168.56.13:3306) succeeded

Mastermysql-master(192.168.56.12:3306) is down!

Check MHA Manager logs atmha-manager:/application/mha/logs/app1.log for details.

Started automated(non-interactive)failover.

The latest slavemysql-slave01(192.168.56.13:3306) has all relay logs for recovery.

Selectedmysql-slave01(192.168.56.13:3306) as a new master.

mysql-slave01(192.168.56.13:3306):OK: Applying all logs succeeded.

mysql-slave02(192.168.56.14:3306):This host has the latest relay log events.

Generating relay diff filesfrom the latest slave succeeded.

mysql-slave02(192.168.56.14:3306):OK: Applying all logs succeeded. Slave started, replicating frommysql-slave01(192.168.56.13:3306)

mysql-slave01(192.168.56.13:3306):Resetting slave info succeeded.

Master failover tomysql-slave01(192.168.56.13:3306) completed successfully.

在mysql-slave02上查看

[[email protected] ~]#mysql -uroot -p123456 -e "show slave status\G"

Warning: Using a password onthe command line interface can be insecure.

***************************1. row ***************************

Slave_IO_State: Waiting formaster to send event

Master_Host: 192.168.56.13   //master改变了

Master_User: repuser

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 120

Relay_Log_File:mysql-relay-bin.000002

Relay_Log_Pos: 283

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 120

Relay_Log_Space: 456

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert:No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 2

Master_UUID:bdb7e690-20cb-11e6-a8b6-000c291242c7

Master_Info_File:/data/mysql_data/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has readall relay log; waiting for the slave I/O thread to update it

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0

由于个人技术所限有不足之处还请各位指出。可以通过以下两个群找到笔者。

北京linux运维求职招聘群:153677549

Linux运维开发群:298324302

时间: 2024-12-24 21:37:04

MySQL高可用之MHA—部署MHA的相关文章

MySQL高可用集群之MHA

MySQL高可用集群之MHA 一.MHA简介 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. MHA里有两

优酷土豆资深工程师:MySQL高可用之MaxScale与MHA

本文根据DBAplus社群第67期线上分享整理而成 本次分享主要包括以下内容: 1.MySQL高可用方案 2.为什么选择MHA 3.读写分离方案的寻找以及为什么选择Maxscale 一.MySQL  Failover的方案 常见的Failover方案 MMM MMM缺点: Monitor节点是单点,可以结合Keepalived实现高可用目前MySQL Failover 的方案 Keepalived会有脑裂的风险 在读写繁忙的业务中可能丢数据 MHA + ssh -o 测试心跳 + masterM

MySQL 高可用集群架构 MHA

MHA(Master HighAvailability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. MHA里有两个角色一个是MHA Node(数据节点)另一个是

MYSQL高可用集群架构-MHA架构

简介 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:MHA Manager(管理节点

MySQL高可用集群架构——MHA架构

MHA 简介: (1)简介 目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. (2)该软件由两部分组成: MHA Manager(管理节点)和MHA Node(数据节

基于PXC的MySQL高可用环境简单部署

PXC简介 Percona XtraDB Cluster(简称PXC集群)提供了MySQL高可用的一种实现方法. 1.集群是有节点组成的,推荐配置至少3个节点,但是也可以运行在2个节点上. 2.每个节点都是普通的mysql/percona服务器,可以将现有的数据库服务器组成集群,反之,也可以将集群拆分成单独的服务器. 3.每个节点都包含完整的数据副本. PXC集群主要由两部分组成:Percona Server with XtraDB和Write Set Replication patches(使

mysql高可用研究之主从+MHA架构

最近在研究mysql的高可用架构,自己想总结下常用的高可用方案都有哪些.有哪些优缺点以及应用的场景?搞得是头昏脑涨,天昏地暗,看了诸多资料,每次都觉得公说公有理婆说婆有理.其实嘛,大家都没有说错,只不过适合自己的才是最正确的选择.今天就从比较常用的主从+MHA说起. 学习一种新的架构还是软件,最好还是先从了解它的原理开始,这样才能在做实验时测试出它的优势和弱势. ###################################################################

MySQL 高可用MMM安装部署以及故障转移详细资料汇总

1,      mmm简介 MMM(Master-Masterreplication manager for MySQL)是一套支持双主故障切换和双主日常管理的脚本程序.MMM使用Perl语言开发,主要用来监控和管理MySQL Master-Master(双主)复制,虽然叫做双主复制,但是业务上同一时刻只允许对一个主进行写入,另一台备选主上提供部分读服务,以加速在主主切换时刻备选主的预热,可以说MMM这套脚本程序一方面实现了故障切换的功能,另一方面其内部附加的工具脚本也可以实现多个slave的r

mysql高可用研究(二) 主从+MHA+Atlas

关于Atlas的详细介绍请访问:https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md 为什么要使用Atlas?应用程序直连数据库不好吗?还要在前面加上一层代理,会不会降低应用的读写性能?会不会增加维护管理的成本?我想这是每个使用atlas之前的疑问. 1.为什么要使用Atlas? 我们使用atlas,主要使用它的读写分离和从库负载均衡功能.因为咱们这读业务远远多于写,故采用读写分离的架构再合适不过了.之前实现读写分离,一般都是通过应

MySQL高可用方案一(MHA)

http://www.mysqlsystems.com/2012/03/figure-out-process-of-autofailover-on-mha.html http://jackyrong.iteye.com/blog/1141863