MHA 高可用集群搭建（二）

MHA 高可用集群搭建
安装scp远程控制
http://www.cnblogs.com/kevingrace/p/5662839.html

yum install openssh-clients

mysql5.7
运行环境：centos6.5
1 主机部署

manager：192.168.133.141
test1： 192.168.133.138
test2:192.168.133.139 （为master1的备用）
test3： 192.168.133.140

test1为主，test2和test3为备，当test1 down的情况下，主自动移动到test2上。
为了节约经费，将manger可以设置到test3中（此处不设置）。
在三台虚拟机上配置账号：
1管理账号：mha_repo 密码123456
2主从同步账号：backup 密码：backup
生成环境下采用脚本的形式来管理虚拟ip，而不是用keepalive完成，容易发生脑裂。

首先用ssh-keygen实现四台主机之间相互免密钥登录
安装MHAmha4mysql-node，mha4mysql-manager 软件包
建立test1，test2，test3 之间主从复制
管理机manager上配置MHA文件
masterha_check_ssh工具验证ssh信任登录是否成功
masterha_check_repl工具验证mysql复制是否成功，这一步坑比较多，前面的必须配置好主从
启动MHA manager,并监控日志文件
测试test1(156)宕机后，是否会自动切换

第一步：首先用ssh-keygen实现四台主机之间相互免密钥登录
先在一台中创建公钥和私钥，然后创建authorized_keys,设定/root/.ssh的权限是700，
scp公钥到其他服务器上，然后拷贝公钥到authorized_keys.

平时两两交互的做法（熟悉下免密匙登录两台）
举例说明：
1 在这台服务器上[test1]
ssh-keygen -t rsa
scp id_rsa.pub root@192.168.133.139:/root/.ssh/
scp id_rsa.pub root@192.168.133.139:/root/.ssh/
scp id_rsa.pub root@192.168.133.140:/root/.ssh/

在另一台服务器上的操作：
cd /root/.ssh
touch authorized_keys
cat id_rsa.pub >>authorized_keys
chmod 600 authorized_keys
chmod 700 /root/.ssh/

第一部分：免密匙登录
在三台主机上操作
在每台服务器上操作ssh-keygen -t rsa 创建公钥和私钥，
然后 ssh-copy-id 每台服务器ip
没有 authorized就创建

ssh-keygen -t rsa
ssh-copy-id 192.168.133.151
ssh-copy-id 192.168.133.152
ssh-copy-id 192.168.133.153

******************************************************************************************
（（（（（（（（（（（（（（（（（（（（（（（（（（（（（（（（99（（（（（（（
）））））））））））））））））））））））））））））））））））））））））
************************************************************************************

第二步：建立test1，test2，test3之间主从复制
test1主
test2是test1的从，也是主备
test3是test1的从

注意：创建在三台服务器上用于主从的账号和mha的监控账号
两台从库只读模式，在命令行执行，不要在配置文件中添加，因为两台从库随时成主
还需要设置从库relay log 的清理模式

test1
vi /etc/my.cnf（其他是省略，主要的）
server_id = 1
log-bin=mysql-bin
log-slave-updates
expire_logs_days = 10

test2
vi /etc/my.cnf
server_id = 2
log-bin=mysql-bin
log-slave-updates
expire_logs_days = 10

test3
vi /etc/my.cnf
server_id = 3
log-bin=mysql-bin
log-slave-updates
expire_logs_days = 10
read_only=1

主从同步master开启重要选项：server-id和log-bin
egrep "log-bin|server-id" /etc/my.cnf

在test1、test2上创建主从同步的账号。test2是备用，这个也需要建立授权用户
在test2和test3上都要授权repl用户和密码。这里的repl会在repl_user用到。

[test1和test2]
mysql -uroot -p123456
grant replication slave on *.* to 'repl'@'192.168.133.%' identified by '123456';
flush privileges;
show master status G;

[master2和slave2]
change master to
master_host='192.168.133.151'
master_user='repl',
master_password='repl',
master_port=3306
master_log_file='mysql-bin.000003',
master_log_pos=603;

start slave;
show slave status G;

主从不能同步的解决办法
1 网络不通
2 密码不对：mysql重新授权远程用户登录，重设密码
3 pos不对：偏移量show master status
4 ID问题：sever-id 必须id不同
5 防火墙策略，SELinux
先stop slave，
设置完成后再重新start slave

搭建主从的注意事项：
配置主从同步是注意要数据库服务器一致，假如主上的数据多，则要备份

在主test1上备份完整数据
mysqldump -uroot -p123456 --master-data=2 --single-transaction -R --triggers -A > all.sql
--master-data=2代表备份时刻记录master的Binlog位置和Position，
--single-transaction意思是获取一致性快照，
-R意思是备份存储过程和函数，
--triggres的意思是备份触发器，
-A代表备份所有的库。
更多信息请自行mysqldump --help查看。

在主上创建复制用户
grant replication slave on *.* to 'repl'@'192.168.2.%' identified by '123456';
flush privileges;

查看主库备份时的binlog名称和位置，MASTER_LOG_FILE和MASTER_LOG_POS
head -n 30 all.sql | grep 'CHANGE MASTER TO'

把备份复制到另外两条服务器
scp all.sql ip:/root/all.sql

分别在两台服务器上导入备份，执行复制相关命令
mysql -uroot -p123456 < ./all.sql
stop slave;
CHANGE MASTER TO MASTER_HOST='192.168.2.128',MASTER_USER='repl', MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=245;
start slave;
show slave statusG
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.2.128
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 472
Relay_Log_File: localhost-relay-bin.000002
Relay_Log_Pos: 480
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

同理，使两台slave status一致。

在master2上配置
mysql -uroot -p123456 -e 'set global read_only=1' （设置在两个从库中只能读，不能写）
mysql -uroot -p123456 -e 'set global relay_log_purge=0'(手动清理,设置relay log 的清除方式)
在slave2上配置
mysql -uroot -p123456 -e 'set global read_only=1'
mysql -uroot -p123456 -e 'set global relay_log_purge=0'(手动清理)

B.安装MHAmha4mysql-node，mha4mysql-manager 软件包

1所有节点上安装mha node所要的perl模块
[test1，test2,test3]
rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

2 在所有节点上安装mha node
yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker
yum install -y perl-CPAN
必须安装上面两个包，如果不安装的话，会在perl Makefile.PL的时候报错
wget https://download.mariadb.com/MHA/mha4mysql-node-0.56.tar.gz
tar zxf mha4mysql-node-0.56.tar.gz
cd mha4mysql-node-0.56
perl Makefile.PL
make && make install

3 安装MHA Manger（manger上安装）

安装MHA Manger依赖的perl模块
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch
perl-Parallel-ForkManager perl-Time-HiRes -y
wget https://downloads.mariadb.com/MHA/mha4mysql-manager-0.56.tar.gz
tar zxf mha4mysql-manager-0.56.tar.gz
cd mha4mysql-manager-0.56
perl Makefile.PL
make && make install

***********************************************************************************************
***********************************************************************************************
安装完MHA Manager后，在/usr/local/bin目录下生成以下脚本
ll /usr/local/bin/
masterha_check_repl 检查MySQL复制状况
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_status 检测当前MHA运行状态
masterha_conf_host 添加或删除配置的server信息
masterha_manager 启动MHA
masterha_stop 停止MHA
masterha_master_monitor 检测master是否宕机
masterha_master_switch 控制故障转移（自动或者手动）
masterha_secondary_check 多种线路检测master是否存活

***************************************************************************************************
***************************************************************************************************
在../mha4mysql-manager-0.56/samples/scripts下还有以下脚本，需要将其复制到/usr/local/bin

cd samples/scripts/
master_ip_failover //自动切换时VIP管理脚本,不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常，我们停止keepalived就行，这样vip就会自动漂移
master_ip_online_change //在线切换时VIP脚本,不是必须，同样可以可以自行编写简单的shell完成
power_manager //故障发生后关闭master脚本,不是必须
send_report //故障切换发送报警脚本，不是必须，可自行编写简单的shell完成

cp ./* /usr/local/bin/

*****************************************************************************************
*******************************************************************************************
创建mha管理用的复制账号
每台数据库节点(test1、test2、test3)上都要创建账号mha_rep，(可以是root）
在这里以其中master1为例。
mysql -uroot -p123456
grant all privileges on *.* to 'mha_rep'@'192.168.133.%' identified by '123456';
flush privileges;
>select host,user from user; 从user表中查找host和user

创建mha的工作目录，创建相关文件(管理节点manager)

mkdir -p /etc/masterha
cp samples/conf/app1.cnf /etc/masterha/

修改manager端也就是test1的mha配置文件
cat /etc/masterha/app1.cnf
[server default]
user=mha_rep #MHA管理mysql的用户名，该账号是在test1，test2，test3中都要创建的
password=123456 #MHA管理mysql的密码
manager_workdir=/var/log/masterha/app1 #MHA的工作目录
manager_log=/var/log/masterha/app1/manager.log #MHA的日志路径
master_binlog_dir=/usr/local/mysql/data 该路径是mysql的data路径
ssh_user=root #免秘钥登陆的用户名
repl_user=repl #主从复制账号，用来在主从之间同步数据
repl_password=123456
ping_interval=1 #ping间隔时间，用来检查master是否正常
remote_workdir=/tmp
report_script=/usr/local/bin/send_report //设置发生切换后发送的报警的脚本
secondary_check_script= /usr/local/bin/masterha_secondary_check -s test2 -s test1 --user=backup --master_host=test1 --master_ip=192.168.2.138 --master_port=3306
一旦MHA到test1的监控之间出现问题，MHA Manager将会尝试从test2登录到test1
shutdown_script=""
#设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用）
master_ip_failover_script= /usr/local/bin/master_ip_failover
#设置自动failover时候的切换脚本
master_ip_online_change_script= /usr/local/bin/master_ip_online_change
#设置手动切换时候的切换脚本
[server1]
hostname=192.168.253.241
port=3306
master_binlog_dir=/data/mysql/data/ 设置master保存binlog的位置，以便MHA可以找到master的日志
[server2]
hostname=192.168.253.242
port=3306
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
master_binlog_dir=/data/mysql/data/
[server3]
hostname=192.168.253.243
port=3306
#no_master=1 #设置na_master=1，使服务器不能成为master
master_binlog_dir=/data/mysql/data/

设置relay log的清除方式（在master2,slave2节点上）
mysql -uroot -p -e 'set global relay_log_purge=0'

###################################################################################
MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，
所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。
在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。
但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，
因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。
在ext3的文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。
为了避免复制延时，需要暂时为中继日志创建硬链接，
因为在linux系统中通过硬链接删除大文件速度会很快。
（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式）

MHA节点中包含了pure_relay_logs命令工具，它可以为中继日志创建硬链接，
执行SET GLOBAL relay_log_purge=1,等待几秒钟以便SQL线程切换到新的中继日志，
再执行SET GLOBAL relay_log_purge=0。
###################################################################################
以上manger配置完毕

**********************************************************************************
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
***********************************************************************************

设置定期清理relay脚本（两台slave服务器）
cd /root/
cat purge_relay_log.sh
#!/bin/bash
user=root
passwd=123456
port=3306
后面三个路径更改
log_dir='/data/masterha/log'
work_dir='/data'
purge='/usr/local/bin/purge_relay_logs'

if [ ! -d $log_dir ]
then
mkdir $log_dir -p
fi

$purge --user=$user --password=$passwd
--disable_relay_log_purge
--port=$port --workdir=$work_dir >> $log_dir/purge_relay_logs.log 2>&1
#######################################
crontab -l
0 4 * * * /bin/bash /root/purge_relay_log.sh

purge_relay_logs脚本删除中继日志不会阻塞SQL线程，手动执行看看情况。
/usr/local/bin/purge_relay_logs --user=root --password=123456 --port=3306 -disable_relay_log_purge --workdir=/data/

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

每次测试和实际环境下都要测试下

检查ssh是否畅通
masterha_check_ssh --conf=/etc/masterha/app1.cnf
检查整个复制环境状况
masterha_check_repl --conf=/etc/masterha/app1.cnf
肯定会报错。
MySQL Replication Health is NOT OK
原因是通过root用户远程连接节点的mysql不通

Failover两种方式：一种是虚拟IP地址，一种是全局配置文件。
MHA并没有限定使用哪一种方式，而是让用户自己选择，
虚拟IP地址的方式会牵扯到其它的软件,比如keepalive软件，
而且还要修改脚本master_ip_failover。
vi master_ip_failover 其中有个vip，设置vip

报错信息：
Can't exec "mysqlbinlog": No such file or directory at
/usr/local/share/perl5/MHA/BinlogManager.pm line 99.
mysqlbinlog version not found!

Testing mysql connection and privileges..sh: mysql: command not found

解决方法如下，添加软连接（所有节点）
type mysqlbinlog
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql
先暂时注释master_ip_failover_script= /usr/local/bin/master_ip_failover

masterha_check_repl --conf=/etc/masterha/app1.cnf
通过master_check_status脚本查看Manager的状态：
masterha_check_status --conf=/etc/masterha/app1.cnf
开启MHA Manager监控
nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &

[1] 30867

启动参数介绍：
--remove_dead_master_conf该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。
--manger_log 日志存放位置
--ignore_last_failover
在缺省情况下，如果MHA检测到连续发生宕机，
且两次宕机间隔不足8小时的话，则不会进行Failover，
之所以这样限制是为了避免ping-pong效应。
该参数代表忽略上次MHA触发切换产生的文件，
默认情况下，MHA发生切换后会在日志目录，
也就是上面我设置的/data产生app1.failover.complete文件，
下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，
除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failove

关闭MHA Manage监控
masterha_stop --conf=/etc/masterha/app1.cnf

添加vip
{test1}
/usr/local/bin/master_ip_failover
在test1下，
#/sbin/ifconfig eth0:1 192.168.133.100/24 这个配置虚拟ip的，不要和服务器一样。

测试mha是否正常工作
将主库master1停止，观察vip是否漂移到对应从库，该从库是否提升到master
另一台从库是否将主库ip提升为主库的从

检查ssh是否畅通
masterha_check_ssh --conf=/etc/masterha/app1.cnf
检查mysql主从复制是否成功
masterha_check_repl --conf=/etc/masterha/app1.cnf

四、mha实验模拟
在每次做mha实验的时候，我们都最好先执行如下命令做检测
masterha_check_ssh --conf=/etc/masterha/app1.cnf
masterha_check_repl --conf=/etc/masterha/app1.cnf

#确定两条命令的返回结果都是无异常的，然后启动mha服务

2、在manager端启动mha服务并时刻监控日志文件的输出变化
nohup masterha_manager --conf=/etc/masterha/app1.cnf > /tmp/mha_manager.log 2>&1 &
ps -ef |grep masterha |grep -v 'grep'
root 2840 2470 2 10:53 pts/0 00:00:00 perl /usr/local/bin/masterha_manager --co

测试master宕机后，时候会自动切换
测试前查看slave01,slave02的主从同步情况
mysql -uroot -p123456 -e 'show slave statusG' |egrep 'Slave_IO_Running:|Slave_SQL_Running:'
mysql -uroot -p123456 -e 'show slave statusG' |egrep 'Slave_IO_Running:|Slave_SQL_Running:'

停止master的mysql服务
service mysqld stop

我们查看slave02的主从同步信息
mysql -uroot -p123456 -e 'show slave statusG' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running
Master_Host: 192.168.253.242 #表明已经转移新的ip
Slave_IO_Running: Yes #表示主从ok

4、恢复master服务
rm -rf /usr/local/mha/mha.failover.complete
service mysqld start
在manager的日子文件中找到主从同步的sql语句
grep MASTER_HOST /usr/local/mha/manager.log
#在master上启动主从同步，密码为backup
mysql> change master to
master_host='192.168.253.242',
master_user='backup',
master_password='backup',
master_port=3306,
master_log_file='mysql-bin.000004',
master_log_pos=700;

在master和slave02上执行，检查主从同步是否都正常，这里以master为例，slave02同理
mysql -uroot -p123456 -e 'show slave statusG' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'

再次启动MHA的manager服务，并停止slave01
nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &

关闭slave01的mysql服务
service mysqld stop
tail -f /usr/local/mha/manager.log

在slave02上查看主从同步情况
mysql -uroot -p123456 -e 'show slave statusG' |egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'

恢复slave01服务
rm -rf /usr/local/mha/mha.failover.complete
service mysqld start
在manager的日子文件中找到主从同步的sql语句
grep MASTER_HOST /usr/local/mha/manager.log

在slave01上启动主从同步，密码为backup
mysql> change master to
-> master_host='192.168.253.241',
master_user='backup',
master_password='backup',
master_port=3306,
master_log_file='mysql-bin.000005',
master_log_pos=120;
Query OK, 0 rows affected, 2 warnings (0.61 sec)

mysql> start slave;

在slave01和slave02上执行，检查主从同步是否都正常，这里以slave01为例，slave02同理
mysql -uroot -p123456 -e
'show slave statusG'
|egrep 'Master_Host|Slave_IO_Running:|Slave_SQL_Running:'

再次启动MHA的manager服务
nohup masterha_manager --conf=/usr/local/mha/mha.cnf > /tmp/mha_manager.log 2>&1 &

通过vip实现mysql的高可用

repl报错请参考
http://www.cnblogs.com/polestar/p/5371080.html#3936049