MySQL之高可用MHA部署

先说一下大概原理

虚拟机A  ip为10.0.3.92           作为master

虚拟机B  ip为10.0.3.102　　  作为slave1

虚拟机C  ip为10.0.3.103　　  作为slave2

虚拟机D  ip为10.0.3.104　　  作为manager

首先配置一主两从环境，A为主，BC为从

然后配置所有虚拟机两两之间ssh免密登录（ssh怎么免密登录，自己百度，或者搜索我博客里的文章吧，也有记录怎么配置ssh免密登录的）

D中新建配置文件

D中检测ssh配置以及主从配置是否成功，这两个非常关键

如果上面都没有问题，那么我们试着把master服务器停掉之后，manager会把主库自动切换到B

下面来说一下具体部署步骤

重要的事情先说，那就是，防火墙和selinux必须关闭，如果不想关闭，那你就慢慢折腾该通过哪个端口之类的吧

下一个MHA压缩包，里面有我们需要用到的文件

http://www.yougemysqldba.com/discuz/viewthread.php?tid=491&extra=page%3D1

我下载的是第二个rhel56.zip，因为我的是6.5的系统

虚拟机A

首先安装mysql,mysql-server (我的系统是centos6.5，听说centos7上部署MHA还需要做其他额外的工作)，然后自然而然是开启服务并修改密码

配置/etc/my.cnf，添加在mysqld里面，内容如下

server-id=1
log-bin=master-log　　
relay-log=relay-log
skip_name_resolve
innodb_file_per_table

解压我们下载的那个压缩包，在虚拟机A上，我们只需要安装mha4mysql-node-0.54-0.el6.noarch.rpm，怎么安装？百度啊，安装时提示缺少依赖关系依赖包？百度啊

进入mysql，执行以下命令

新建一个repluser用户，专门用来同步

mysql> show master status;
+-------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| master-log.000004 | 106 | | |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

这样子的话说明master端配置好了

虚拟机B以及虚拟机C：

当然这两台虚拟机也需要安装node那个rpm文件包

配置文件/etc/my.cnf,当然也是放在mysqld下面了

symbolic-links=0
default-character-set=utf8
character-set-server=utf8
collation-server=utf8_bin
default-storage-engine=INNODB
max_allowed-packet=32M
sql_mode=NO_AUTO_VALUE_ON_ZERO
server-id=2  　　#虚拟机C只需要把这里改为3 
relay-log=relay-log
log-bin=master-log
read_only=1
relay_log_purge=0
skip_name_resolve
innodb_file_per_table

前面多出的几行是设置中文编码

进入数据库

change master 设置

change master to master_host=‘10.0.3.92‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘replpass‘,MASTER_LOG_FILE=‘master-log.000004‘,MASTER_LOG_POS=106;

现在start slave查看slave状态，主要查看下面两个参数是否为yes，如果是就表示正常

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

虚拟机D：

安装下载的压缩包里面的所有rpm文件

配置

[[email protected] ~]# cat /etc/masterha_default.cnf
[server default]
user=root　　　　　　#听说这个是数据库的用户名，需要在四台虚拟机上都创建这个用户，并且授权为可远程登录，反正我是直接用的root用户，并且密码统一为123456
password=123456　　#这个是上面用户对应的密码
manager_workdir=/data/masterha/app1
manager_log=/data/masterha/app1/manager.log
remote_workdir=/data/masterha/app1
ssh_user=root         #ssh登录的用户名，配置ssh时也是配置该用户
repl_user=repluser　　　　#配置主从时设置的用户
repl_password=replpass　　　#主从用户密码
ping_interval=1
[server1]
hostname=10.0.3.92
[server2]
hostname=10.0.3.102
[server3]
hostname=10.0.3.103
[[email protected] ~]#

[[email protected] ~]# masterha_
masterha_check_repl        masterha_check_status 　　masterha_manager 　　 masterha_master_switch 　　 masterha_stop
masterha_check_ssh         masterha_conf_host 　　 masterha_master_monitor　　 masterha_secondary_check

[[email protected] ~]# masterha_check_ssh --conf=/etc/masterha_default.cnf 　　检测ssh配置
Thu Nov 9 01:12:32 2017 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Thu Nov 9 01:12:32 2017 - [info] Reading application default configurations from /etc/masterha_default.cnf..
Thu Nov 9 01:12:32 2017 - [info] Reading server configurations from /etc/masterha_default.cnf..
Thu Nov 9 01:12:32 2017 - [info] Starting SSH connection tests..
Thu Nov 9 01:12:33 2017 - [debug]
Thu Nov 9 01:12:32 2017 - [debug] Connecting via SSH from [email protected](10.0.3.92:22) to [email protected](10.0.3.102:22)..
Thu Nov 9 01:12:32 2017 - [debug] ok.
Thu Nov 9 01:12:32 2017 - [debug] Connecting via SSH from [email protected](10.0.3.92:22) to [email protected](10.0.3.103:22)..
Thu Nov 9 01:12:33 2017 - [debug] ok.
Thu Nov 9 01:12:34 2017 - [debug]
Thu Nov 9 01:12:33 2017 - [debug] Connecting via SSH from [email protected](10.0.3.102:22) to [email protected](10.0.3.92:22)..
Thu Nov 9 01:12:33 2017 - [debug] ok.
Thu Nov 9 01:12:33 2017 - [debug] Connecting via SSH from [email protected](10.0.3.102:22) to [email protected](10.0.3.103:22)..
Thu Nov 9 01:12:33 2017 - [debug] ok.
Thu Nov 9 01:12:34 2017 - [debug]
Thu Nov 9 01:12:33 2017 - [debug] Connecting via SSH from [email protected](10.0.3.103:22) to [email protected](10.0.3.92:22)..
Thu Nov 9 01:12:34 2017 - [debug] ok.
Thu Nov 9 01:12:34 2017 - [debug] Connecting via SSH from [email protected](10.0.3.103:22) to [email protected](10.0.3.102:22)..
Thu Nov 9 01:12:34 2017 - [debug] ok.
Thu Nov 9 01:12:34 2017 - [info] All SSH connection tests passed successfully.
[[email protected] ~]#

[[email protected] ~]# masterha_check_repl --conf=/etc/masterha_default.cnf       #检测主从复制，正常情况下mysql replication health is ok,这里因为我是在实验完成后停掉master服务器了，才导致的not ok。刚开始的时候我这里一直是not ok，然后我就各种查错，最后发现是防火墙不知道什么时候又开启了。。。这里我建议在D上尝试连接另外三台虚拟机的数据库，分别用root登录以及主从复制用户登录，如果不报错，检测主从复制这里应该就没有问题了
Thu Nov 9 01:12:59 2017 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Thu Nov 9 01:12:59 2017 - [info] Reading application default configurations from /etc/masterha_default.cnf..
Thu Nov 9 01:12:59 2017 - [info] Reading server configurations from /etc/masterha_default.cnf..
Thu Nov 9 01:12:59 2017 - [info] MHA::MasterMonitor version 0.55.
Thu Nov 9 01:13:00 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln604] There are 2 non-slave servers! MHA manages at most one non-slave server. Check configurations.
Thu Nov 9 01:13:00 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln386] Error happend on checking configurations. at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 300
Thu Nov 9 01:13:00 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln482] Error happened on monitoring servers.
Thu Nov 9 01:13:00 2017 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!

现在我们试着把master服务器停掉，然后我们看一下虚拟机C的状态

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.3.102　　　　#可以看到这里自动把master从10.0.3.92 切换到10.0.3.102了
Master_User: repluser
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-log.000010
Read_Master_Log_Pos: 600
Relay_Log_File: relay-log.000005
Relay_Log_Pos: 252
Relay_Master_Log_File: master-log.000010
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: 600
Relay_Log_Space: 1286
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:
1 row in set (0.00 sec)

ERROR:
No query specified

mysql>

大概就是这么简单，但是第一次配置时还是很容易出现这样或那样的问题的，慢慢琢磨吧

什么，我写得乱七八糟的，你看不懂？

好吧，给一个参考链接给你http://www.178linux.com/87554

时间： 2024-08-30 07:04:23

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

MySQL的高可用(MHA)

MySQL的高可用(MHA) MHA简介 MHA:Master High Availability,对主节点进行监控,可实现自动故障转移至其他从节点:通过提升某一从节点为新的主节点,基于主从复制实现,还需要客户端配合实现,目前MHA主要支持一主二从,即一台充当master,一台充当备用master,另外一台充当从数据库,出于机器成本的考虑,淘宝进行了改造,目前淘宝TMHA已经一主一从. MHA架构 MHA的工作原理 MHA是由一台manager服务器远程监控主服务器,当主服务器挂了提升一台从服务

MySQL高可用MHA部署 （一主二从）

MHA介绍: MHA是一套MySQL故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性.MHA部署简单,也需要额外的服务器开销,运行MHA时对数据服务器性能几乎没有影响,也不需要对现有架构做调整. 同时MHA还支持主库在线切换,能够安全地将现在的主库切到新的主库,只会对写操作有0.5~2s的阻塞,对读没有影响. MHA有以下功能,对有高可用,数据一致性,主库不停机维

mysql高可用MHA部署全过程

部署计划 mysql_master 192.168.2.74 centos6.9 mysql5.5/mha-node mysql_salve1 192.168.2.75 centos6.9 mysql5.5/mha-node mysql_salve2 192.168.2.76 centos6.9 mysql5.5/mha-node/mha-man 本次部署采用3台服务器,mha-manager不单独使用一台服务器安装,生产上可以单独出来,本次使用采用centos6.9系统(使用 http://y

Heartbeat+Drbd+Mysql主从高可用实现

在上一篇中已经实现了MySQL服务的高可用,MySQL的数据目录放在drbd的共享目录中,并且只有获取到heartbeat资源的VIP才能挂载共享目录,从而启动MySQL服务,但是两端的数据使用drbd同步,保证发生故障时,服务和资源能够从一个节点切换到另外一个节点,下面是一个简略的架构图: 对于MySQL服务,一般在生产环境中都要做主从结构,从而保证数据的完整性,所以这次要在这个架构的前提下,在两个heartbeat节点下再部署一台MySQL从库,而主库是heartbeat集群中的一台(主库的

mysql实现高可用架构之MHA

一.简介 MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供了 automating master failover 功能.MHA 在监控到 master 节点故障时,会提升其中拥有最新数据的 slave 节点成为新的master 节点,在此期间,MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题.MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点. MHA 是由日本人 yoshinorim

Mysql 的高可用之 MHA

                                                                    Mysql 的高可用之 MHA MHA作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点).

MHA高可用架构部署配置实例

MHA高可用架构部署配置实例 一.前言 1.1What's MHA?--原理简介 ? MHA--Master High Availability,目前在MySQL高可用方面是一个相对成熟的解决方案,是一套优秀的MySQL故障切换和主从提升的高可用软件. ? 这里我们提到了两个个关键点:"高可用","故障切换".我们逐一简单介绍一下这两者的含义. 1.1.1何为高可用? ? 高可用就是可用性强,在一定条件下(某个服务器出错或宕机)可以保证服务器可以正常运行,在一定程度

技术实战：基于 MHA 方式实现 MySQL 的高可用(转)

转自:http://os.51cto.com/art/201307/401702_all.htm MHA故障转移可以很好的帮我们解决从库数据的一致性问题,同时最大化挽回故障发生后的数据.本文分享了基于 MHA 方式实现 Mysql 的高可用的技术实战,希望对您有所帮助. AD:51CTO网+ 首届中国APP创新评选大赛火热招募中…… 数据的重要性对于人们来说重要程度不说自明,在信息时代,数据有着比人们更大的力量,我们也知道最近的斯诺登事件,军事专家对于他掌握的数据给出的评价是,相当于美军十个重装

Corosync部署MySQL+DRBD高可用服务

介绍篇 高可用集群主要是有两个或者多个节点进行工作,ha基本组成部分包括四个部分:1.位于最底层的信息和基础架构层(Messaging Layer),主要用于节点之间传递心跳信息,故也称为心跳层.节点之间传递心跳信息可以通过广播,组播,单播等方式.2.第二层为成员关系(Membership)层,这层最重要的作用是主节点通过cluster consensus menbership service(CCM或者CCS)这种服务由第一层提供的信息,来生产一个完整的成员关系.这层主要实现承上启下的作用,承