Mha-Atlas-MySQL高可用方案实践

一，mysql-mha环境准备

1.1 实验环境：

1.2 软件包

1） mha管理节点安装包：

mha4mysql-manager-0.56-0.el6.noarch.rpm

mha4mysql-manager-0.56.tar.gz

2） mha node节点安装包：

mha4mysql-node-0.56-0.el6.noarch.rpm

mha4mysql-node-0.56.tar.gz

3） mysql中间件：

Atlas-2.2.1.el6.x86_64.rpm

4） mysql源码安装包

mysql-5.6.17-linux-glibc2.5-x86_64.tar

1.3 主机名映射

1.4 关闭selinux和iptables


二，简介

2.1 作者简介

 
姓名：松信嘉范 
MySQL/Linux专家 
2001年索尼公司入职 
2001年开始使用oracle 
2004年开始使用MySQL 
2006年9月-2010年8月MySQL从事顾问 
2010年-2012年DeNA 
2012年至今Facebook

2.2 软件简介

1、MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中，MHA能最大程度上保证数据库的一致性，以达到真正意义上的高可用。

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

2.3 工作流程

1、复制主库binlog日志出来 
2、找出relaylog日志最全的从库 
3、将最全的relaylog日志在所有从库中同步（第一次数据同步） 
4、将之前最全的那个从库提升为主库 
5、将复制出来的binlog日志放到新提升为主库的从库里面 
6、其他所有从库重新指向新提升主库，继续主从复制

2.4 MHA架构图

2.5 MHA工具介绍

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下： 

三，mysql环境准备

3.1 环境检查

3.2 安装mysql

3.2.1 安装包准备

链接：https://pan.baidu.com/s/1aSh6hKFDcA6VAsXicbTSSQ 
提取码：2ynt

3.2.2 安装（3台都装）

  1. yum -y install ncurses-devel
  3. yum -y install libaio
  5. tar xf mysql-5.6.17-linux-glibc2.5-x86_64.tar.gz -C /usr/local/
  7. ln -s /usr/local/mysql-5.6.17-linux-glibc2.5-x86_64 /usr/local/mysql
  9. useradd mysql -s /sbin/nologin -M
  11. /usr/local/mysql/scripts/mysql_install_db --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data/
  13. /bin/cp /usr/local/mysql/support-files/my-default.cnf /etc/my.cnf
  15. /bin/cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld
  17. ln -s /usr/local/mysql/bin/* /usr/local/bin/

3.2.3 加入开机自启动并启动mysql (3台都加)

3.2.4 配置密码 (3台都配)

  1. mysqladmin -uroot password ‘123123‘

四，配置基于GTID的主从复制

4.1 先决条件

主库和从库都要开启binlog 
主库和从库server-id不同 
要有主从复制用户

4.2 主库操作（MySQL-Master）

4.2.1 修改配置文件

  1. [[email protected]-Master ~]# vim /etc/my.cnf
  2. [[email protected]-Master ~]# cat /etc/my.cnf
  3. [client]
  4. socket = /usr/local/mysqld/data/mysql.sock
  5. [mysqld]
  6. lower_case_tabel_names = 1
  7. default-storage-engine = InnoDB
  8. port = 3306
  9. datadir = /usr/local/mysql/data
  10. character-set-server = utf8
  11. socket = /usr/local/mysql/data/mysql.sock
  13. log_bin = mysql-bin #开启binlog日志
  14. server_id = 1 #设置server_id
  15. innodb_buffer_pool_size = 200M
  16. slave-parallel-workers = 8
  17. thread_cache_size = 600
  18. back_log = 600
  19. slave_net_timeout = 60
  20. max_binlog_size = 512M
  21. key_buffer_size = 8M
  22. query_cache_size = 64M
  23. join_buffer_size = 2M
  24. sort_buffer_size = 2M
  25. query_cache_type = 1
  26. thread_stack = 192K

4.2.2 登陆MySQL删除不必要的用户并创建主从复制用户

(1)删除不必要的用户

  1. mysql>
  2. mysql> select user,host from mysql.user;
  3. +------+--------------+
  4. | user | host |
  5. +------+--------------+
  6. | root | 127.0.0.1 |
  7. | root | ::1 |
  8. | | localhost |
  9. | root | localhost |
  10. | | mysql-master |
  11. | root | mysql-master |
  12. +------+--------------+
  13. 6 rows in set (0.10 sec)
  15. mysql> drop user [email protected]‘127.0.0.1‘;
  16. Query OK, 0 rows affected (0.00 sec)
  18. mysql> drop user [email protected]‘::1‘;
  19. Query OK, 0 rows affected (0.00 sec)
  21. mysql> drop user ‘ ‘@‘localhost‘;
  22. Query OK, 0 rows affected (0.00 sec)
  24. mysql> drop user ‘ ‘@‘mysql-master‘;
  25. Query OK, 0 rows affected (0.00 sec)
  27. mysql> select user,host from mysql.user;
  28. +------+--------------+
  29. | user | host |
  30. +------+--------------+
  31. | root | localhost |
  32. | root | mysql-master |
  33. +------+--------------+
  34. 2 rows in set (0.00 sec)

(2)创建主从复制用户

4.3 从库操作(MySQL-SlaveA和MySQL-SlaveB)

4.3.1 修改配置文件

MySQL-SlaveA 
 

MySQL-SlaveB 
 

特别提示： 在以往如果是基于binlog日志的主从复制，则必须要记住主库的master状态信息。

但是在MySQL5.6版本里多了一个Gtid的功能，可以自动记录主从复制位置点的信息，并在日志中输出出来。

4.4 开启GTID

编辑mysql配置文件（主库从库都需要修改）

三台机器都需要加上上图标注的三行代码

修改完配置文件以后重启动数据库

  1. /etc/init.d/mysqld restart

再次查看GTID状态 

再次提示： 
主库从库都必须要开启GTID，否则在做主从复制的时候就会报错.

4.5 配置主从复制(MySQL-SlaveA,MySQL-SlaveB)

4.6 开启从库的主从复制功能（MySQL-SlaveA,MySQL-SlaveB）

  1. mysql>start slave; 开启主从复制

两个从库MySQL-SlaveA和MySQL-SlaveB都执行以上步骤。

MySQL主从复制，启动slave时，出现下面报错： 
mysql> start slave; 
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

解决办法：

4.7 什么是GTID

1、GTID（Global Transaction）全局事务标识符：是一个唯一的标识符，它创建并与源服务器（主）上提交的每个事务相关联。此标识符不仅对其发起的服务器是唯一的，而且在给定复制设置中的所有服务器上都是唯一的。所有交易和所有GTID之间都有1对1的映射。

2、GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。 
下面是一个GTID的具体形式：

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

4.8 GTID的新特性

（1）支持多线程复制：事实上是针对每个database开启相应的独立线程，即每个库有一个单独的（sql thread）

（2）支持启用GTID，在配置主从复制，传统的方式里，你需要找到binlog和POS点，然后change master to 指向。在mysql5.6里，无须再知道binlog和POS点，只需要知道master的IP/端口/账号密码即可，因为同步复制是自动的，MySQL通过内部机制GTID自动找点同步。

（3）基于Row复制只保存改变的列，大大节省磁盘空间，网络，内存等

（4）支持把Master和Slave的相关信息记录在Table中；原来是记录在文件里，现在则记录在表里，增强可用性

（5）支持延迟复制

4.9 开启方法

  1. #mysql配置文件：
  2. [mysqld]
  3. gtid_mode=ON
  4. enforce_gtid_consistency
  5. #查看
  6. show global variables like ‘%gtid%’；

4.10 从库设置（MySQL-SlaveA,MySQL-SlaveB）

编辑配置文件/etc/my.cnf

修改完毕后重启mysql服务：/etc/init.d/mysqld restart

五，部署MHA

5.1 环境准备（所有节点MySQL-Master,MySQL-SlaveA,MySQL-SlaveB）

mha4mysql-node-0.56-0.el6.noarch.rpm以下链接提取 
链接：https://pan.baidu.com/s/1S9FDyBjxEBXBF00aAFK4pw 
提取码：opja

  1. 光盘安装依赖包 yum -y install perl-DBD-MySQL
  3. 安装mha4mysql-node-0.56-0.el6.noarch.rpm
  4. rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

5.2 部署管理节点（mha-manager）

5.2.1 在MySQL-SlaveB上部署管理节点

  1. #使用阿里云源+epel源
  2. wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo
  3. wget -O /etc/yum.repos.d/epel-6.repo http://mirrors.aliyun.com/repo/epel-6.repo
  5. #安装manager依赖包（需要公网源）
  6. yum -y install perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
  8. #安装manager包
  9. [[email protected]-SlaveB rpm]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
  10. Preparing... ########################################### [100%]
  11. 1:mha4mysql-manager ########################################### [100%]

5.2.2 编辑配置文件

  1. #创建配置文件目录
  2. mkdir -p /etc/mha
  4. #创建日志目录
  5. mkdir -p /var/log/mha/mha1
  7. #创建配置文件（默认没有）
  8. [[email protected]-SlaveB ~]# cd /etc/mha/
  9. [[email protected]-SlaveB mha]# ls
  10. [[email protected]-SlaveB mha]# vim /etc/mha/mha1.cnf
  11. [[email protected]-SlaveB mha]# cat /etc/mha/mha1.cnf
  12. [server default]
  13. manager_log=/var/log/mha/mha1/manager #manager管理日志存放路径
  14. manager_workdir=/var/log/mha/mha1 #manager管理日志的目录路径
  15. master_binlog_dir=/usr/local/mysql/data #binlog日志的存放路径
  16. user=mha #管理账户
  17. password=123123 #管理账户密码
  18. ping_interval=2 #存活检查的间隔时间
  19. repl_user=rep #主从复制的授权账户
  20. repl_password=123123 #主从复制的授权账户密码
  21. ssh_user=root #用于ssh连接的账户
  22. [server1]
  23. hostname=192.168.200.159
  24. port=3306
  25. [server2]
  26. #candidate_master=1 #此条暂时注释掉（后面解释）
  27. #check_repl_delay=0 #此条暂时注释掉（后面解释）
  28. hostname=192.168.200.161
  29. port=3306
  30. [server3]
  31. hostname=192.168.200.160
  32. port=3306
  33. #**特别提示：**
  34. #以上配置文件内容里每行的最后不要留有空格，因此，不能复制的呦

特别说明： 
参数：candidate_master=1 
解释：设置为候选master，如果设置该参数以后，发生主从切换以后会将此从库提升为主库，即使这个主库不是集群中事件最新的slave 
参数：check_repl_delay=0 
解释：默认情况下如果一个slave落后master 100M的relay logs 的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

5.3 配置ssh信任（所有节点mysql-db01,mysql-db02,mysql-db03）

  1. #创建密钥对
  2. [[email protected]-SlaveB ~]# ssh-keygen -t dsa -P "" -f ~/.ssh/id_dsa >/dev/null 2>&1
  3. #发送MySQL-SlaveB公钥，包括自己
  4. [[email protected]-SlaveB ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.159
  5. [[email protected]-SlaveB ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.161
  6. [[email protected]-SlaveB ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.160
  8. #发送MySQL-SlaveA公钥，包括自己
  9. [[email protected]-SlaveA ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.159
  10. [[email protected]-SlaveA ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.161
  11. [[email protected]-SlaveA ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.160
  13. #发送MySQL-Master公钥，包括自己
  14. [[email protected]-Master ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.159
  15. [[email protected]-Master ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.160
  16. [[email protected]-Master ~]# ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected].168.200.161

5.4 启动测试

5.4.1 ssh检查检测

  1. [[email protected]-SlaveB ~]# masterha_check_ssh --conf=/etc/mha/mha1.cnf #ssh检查命令

5.4.2 主从复制检测

[[email protected] ~]# masterha_check_repl --conf=/etc/mha/mha1.cnf

（1）错误的主从复制检测

因此在MySQL-SlaveA和MySQL-SlaveB上添加主从复制的用户即可。 
grant replication slave on . to [email protected]‘192.168.200.%‘ identified by ‘123123‘;

5.5 启动MHA

  1. [[email protected]-slaveB ~]# nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/mha1/manager.log 2>&1 &
  2. [1] 3408
  3. [[email protected]-slaveB ~]# ps -ef | grep perl | grep -v grep
  4. root 3408 1272 1 03:03 pts/0 00:00:00 perl /usr/bin/masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover

5.6 进行mha自动切换master的测试

初始状态： 

（1）登陆mysql-db02(192.168.0.53)查看信息状态 

（2）停掉mysql-db01(192.168.0.51)上的MySQL服务

  1. [[email protected]-Master ~]# /etc/init.d/mysqld stop
  2. Shutting down MySQL..... SUCCESS!

（3）查看slaveB上的MySQL从库同步状态

（4）查看mysql-db02上的MySQL，主库同步状态。

（5）查看mysql-db03上的mha进程状态

（6）查看mha配置文件信息

说明： 
当作为主库的mysql-db01上的MySQL宕机以后，mha通过检测发现mysql-db01宕机，那么会将binlog日志最全的从库立刻提升为主库，而其他的从库会指向新的主库进行再次同步。

查询mha日志路径 /var/log/mha/mha1/manager

5.7 进行mha的故障还原测试

由于mysql-Master的MySQL服务宕机，因此mha将mysql-SlaveA提升为了主库。因此，我们需要将宕机的mysql-Master的MySQL服务启动，然后作为主库mysql-SlaveA的从库。

初始状态： 

（1）将故障宕机的mysql-Master的MySQL服务启动并授权进行从同步

  1. /etc/init.d/mysqld start #启动Master的MySQL服务
  3. #进入mysql授权进行从同步
  4. mysql> CHANGE MASTER TO MASTER_HOST=‘192.168.200.161‘, MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER=‘rep‘, MASTER_PASSWORD=‘123123‘;

（2）将mha配置文件里缺失的部分补全

（3）启动mha进程

注：如果发现从库没有mha账户需要将主库的mha账户删除后从新授权一个，这样从库就自动复制过来了。一般情况下不会这样，我可能出现bug了！！！

（4）停掉mysql-slaveA上的MySQL服务

（5）查看mysql-slaveB上的主从同步状态：

（6）启动mysql-slaveA上的MySQL服务

  1. [[email protected]-SlaveA ~]# /etc/init.d/mysqld start
  2. Starting MySQL.. SUCCESS!
  3. [[email protected]-SlaveA ~]# mysql -uroot -p123123
  4. mysql> CHANGE MASTER TO MASTER_HOST=‘192.168.200.159‘, MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER=‘rep‘, MASTER_PASSWORD=‘123123‘;
  5. mysql> start slave;
  6. mysql> show slave status\G

（7）再次补全mha配置文件后，启动mha进程


注：这次上述没有自动复制mha账户的问题没有发生，可能真的遇到了bug！！！

六，MHA参数验证实践

测试

综上实验，当slaveB新加了参数验证，主库再次宕机的话，新的主库变成了自己。

原文地址：https://www.cnblogs.com/mendermi/p/10087992.html

时间： 2024-11-08 06:32:17

Mha-Atlas-MySQL高可用方案实践的相关文章

MySQL高可用方案MHA自动Failover与手动Failover的实践及原理

集群信息 角色                             IP地址                 ServerID      类型 Master                         192.168.244.10   1                 写入 Candicate master          192.168.244.20   2                 读 Slave                           192.168.244.

Mha-Atlas-MySQL高可用方案实践。

Mha-Atlas-MySQL高可用方案实践(一) Mha-Atlas-MySQL高可用方案实践 一,mysql-mha环境准备 1.1 实验环境: 1.2 软件包 用到得所有包 链接:https://pan.baidu.com/s/19tiKXNEW4C6oWi9OFmcDYA 提取码:be07 1) mha管理节点安装包: mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-manager-0.56.tar.gz 2) mha node数据节点

[转载] MySQL高可用方案选型参考

原文: http://imysql.com/2015/09/14/solutions-of-mysql-ha.shtml?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣. 高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方案,大多是基于以下几种基础来部署的: 基于主从复制:

五大常见的MySQL高可用方案【转】

1. 概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断. 用作备份.只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致. 当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数据不一致而影响业务. 关于对高可用的分级在这里我们不做详细的讨论,这里只讨论常用高可用方案的优缺点以及高可用方案的选型. 2. 高可用方

MySQL高可用方案选型参考

本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣. 高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方案,大多是基于以下几种基础来部署的: 基于主从复制: 基于Galera协议: 基于NDB引擎: 基于中间件/proxy: 基于共享存储: 基于主机高可用: 在这些可选项中,最常见的就是基于主从复制的方案,其次是基于Galera的方案,我们重点说说这两种方案.其余几种方案在生产上用的并不多,我们只简单

keepalived结合MHA实现mysql高可用

本例结合本博另一篇文章 MHA-大杀器实现MYSQL单主宕机时,VIP漂移实现高可用,环境请参考上一篇文章 本例使用keepalived-1.1.20.tar.gz版本 [[email protected] keepalived-1.1.20]# ./configure --sysconf=/etc/ #此项表示设置keepalived的根目录 如果编译报错"configure: error: Popt libraries is required" 则yum -y install po

MySQL高可用方案探究

来自 http://bbs.chinaunix.net/thread-3769165-1-1.html 最近花了点时间研究了一下mysql的高可用,总结成文档,希望对初学这有帮助. Lvs+Keepalived+Mysql单点写入主主同步高可用方案 http://blog.chinaunix.net/uid-20639775-id-3337448.html Lvs+Keepalived+Mysql单点写入读负载均衡主主同步高可用方案 http://blog.chinaunix.net/uid-2

Heartbeat+DRBD+MySQL高可用方案

Heartbeat+DRBD+MySQL高可用方案 =============================================================================== 概述: =============================================================================== 方案介绍  1.方案介绍及优缺点 ★方案介绍 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数

[转]MYSQL高可用方案探究(总结)

前言 http://blog.chinaunix.net/uid-20639775-id-3337432.htmlLvs+Keepalived+Mysql单点写入主主同步高可用方案 http://blog.chinaunix.net/uid-20639775-id-3337448.htmlLvs+Keepalived+Mysql单点写入读负载均衡主主同步高可用方案http://blog.chinaunix.net/uid-20639775-id-3337471.htmlHeartbeat高可用M

Heartbeat+DRBD+MySQL高可用方案【转】

转自Heartbeat+DRBD+MySQL高可用方案 - yayun - 博客园 http://www.cnblogs.com/gomysql/p/3674030.html 1.方案简介 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD这个工具来保证.默认情况下只有一台mysql在工作,当主mysql服务器出现问题后,系统将自动切换到备机上继续提供服务,当主数据库修复完毕,又将服务切回继续由主mysql提供服务. 2.方案优缺点 优点:安全性高.稳