锐客网

  1. 首页 > it技术 > >

DBA-70-day12

5. 主从复制延时
5.1 什么是延时？ 主库做的事，从库好久才做。
5.2 如何监控？ 5.2.1 传输过程监控
主库：
show master status ;
从库：
show slave status \G
例子：
[root@db01 ~]# mysql -S /tmp/mysql3307.sock -e "show master status; "
+------------------+----------+--------------+------------------+-------------------+
| File| Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |154 ||||
+------------------+----------+--------------+------------------+-------------------+
[root@db01 ~]# mysql -S /tmp/mysql3308.sock -e "show slave status\G"|grep "Read_Master_Log_Pos"
Read_Master_Log_Pos: 154
[root@db01 ~]#
1000以上告警，10000以上紧急
5.2.2 回放是否及时
[root@db01 ~]# mysql -S /tmp/mysql3307.sock -e "show master status; "
+------------------+----------+--------------+------------------+-------------------+
| File| Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |154 ||||
+------------------+----------+--------------+------------------+-------------------+
[root@db01 ~]# mysql -S /tmp/mysql3308.sock -e "show slave status\G"|grep " Exec_Master_Log_Pos"
Exec_Master_Log_Pos: 154
10000以上告警，100000以上紧急
5.3 主从延时的原因 5.3.1 外部因素
网络
主从配置（cpu\mem\io）
参数配置
等。
从库太多
5.3.2 主库方面
# dump线程是串行工作的模式。
5.6以前的版本，只能一个一个事务投递binlog。
5.6+版本以后，出现了group commit;
# binlog落地不及时。
采用ssd专门存储binlog
5.3.3 从库问题
# IO落地relaylog
一般建议采用SSD
# SQL线程
默认情况只有一个SQL线程，只能串行工作。
主库可以并发事务。
高并发场景下，会造成较高延时。
出现大事务的时候，都会造成较高延时。
解决方案：
1. 5.6版本，多SQL线程回放功能。但是只能根据不同库（database）进行回放。
2. 5.7+版本中，加入MTS机制。能够按照group commit 的逻辑时钟，进行并行回放。
# 人的问题
高并发场景下，会造成较高延时。
出现大事务的时候，都会造成较高延时。
锁问题严重。
==============================
第九章主从复制（Source-Replica）-下-高级进阶 1. 延时从库
1.1介绍 是我们认为配置的一种特殊从库.人为配置从库和主库延时N小时.
1.2 为什么要有延时从 什么是数据库损坏？
物理损坏
主从复制非常擅长解决物理损坏.
逻辑损坏
普通主从复制没办法解决逻辑损坏
1.3 配置延时从库 SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql> start slave;
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
1.4 延时从库应用 ***** 1.4.1 故障恢复思路
1主1从,从库延时5分钟,主库误删除1个库
1. 5分钟之内 侦测到误删除操作
2. 停从库SQL线程
3. 截取relaylog
起点 :停止SQL线程时,relay最后应用位置
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 320
终点:误删除之前的position(GTID)
4. 恢复截取的日志到从库
5. 从库身份解除,替代主库工作
1.4.2 故障模拟及恢复
1.主库数据操作
create database relay charset utf8;
use relay
create table t1 (id int);
insert into t1 values(1);
drop database relay;
2. 停止从库SQL线程
stop slave sql_thread;
3. 找relaylog的截取起点和终点
起点:
Relay_Log_File: db01-relay-bin.000002
Relay_Log_Pos: 485
终点:
mysql> show relaylog events in 'db01-relay-bin.000002';
| db01-relay-bin.000002 | 1145 | Query|7 |1074 | drop database relay
mysqlbinlog --start-position=485 --stop-position=1145/data/3308/data/db01-relay-bin.000002>/tmp/relay.sql
从库恢复relaylog
source /tmp/relay.sql
5.从库身份解除
db01 [relay]>stop slave;
db01 [relay]>reset slave all
2. 半同步 ***
解决主从数据一致性问题。
2.1 半同步复制工作原理的变化 1. 主库执行新的事务,commit时,更新 show masterstatus\G ,触发一个信号给
2. binlog dump 接收到主库的 show master status\G信息,通知从库日志更新了
3. 从库IO线程请求新的二进制日志事件
4. 主库会通过dump线程传送新的日志事件,给从库IO线程
5. 从库IO线程接收到binlog日志,当日志写入到磁盘上的relaylog文件时,给主库ACK_receiver线程
6. ACK_receiver线程触发一个事件,告诉主库commit可以成功了
7. 如果ACK达到了我们预设值的超时时间,半同步复制会切换为原始的异步复制.
2.2 配置半同步复制 加载插件
主:
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
从:
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
查看是否加载成功:
show plugins;
【DBA-70-day12】启动:
主:
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
重启从库上的IO线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
查看是否在运行
主:
show status like 'Rpl_semi_sync_master_status';
从:
show status like 'Rpl_semi_sync_slave_status';
3 . 过滤复制
3.1 说明 主库：
show master status;
Binlog_Do_DB
Binlog_Ignore_DB
从库：
show slave status\G
Replicate_Do_DB:
Replicate_Ignore_DB:


Replicate_Do_Table:
Replicate_Ignore_Table:


Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Replicate_Do_DB:
Replicate_Ignore_DB:
3.2 实现过程 [root@db01 ~]# vim /data/3308/my.cnf
replicate_do_db=ppt
replicate_do_db=word
[root@db01 ~]# systemctl restart mysqld3308
主库：
Master [(none)]>create database word;
Query OK, 1 row affected (0.00 sec)
Master [(none)]>create database ppt;
Query OK, 1 row affected (0.00 sec)
Master [(none)]>create database excel;
Query OK, 1 row affected (0.01 sec)
或者使用以下方法：
mysql> helpCHANGE REPLICATION FILTER
4. GTID复制
4.1 GTID引入 4.2 GTID介绍 GTID(Global Transaction ID)是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。
它的官方定义如下：
GTID =server_uuid : transaction_id
7E11FA47-31CA-19E1-9E56-C43AA21293967:29
什么是sever_uuid，和Server-id 区别？
核心特性: 全局唯一,具备幂等性
4.3 GTID核心参数 重要参数： gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
gtid-mode=on--启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true--强制GTID的一致性
log-slave-updates=1--slave更新是否记入日志
4.4 GTID复制配置过程： 4.4.1 清理环境
pkill mysqld
\rm -rf /data/3306/data/*
\rm -rf /data/binlog/*
\mv /etc/my.cnf /tmp
mkdir -p /data/3306/data /data/binlog/
chown -R mysql.mysql /data/*
4.4.2 准备配置文件
主库db01：
cat > /etc/my.cnf < [mysqld]
basedir=/data/app/mysql/
datadir=/data/3306/data
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOF
slave1(db02)：
cat > /etc/my.cnf < [mysqld]
basedir=/data/app/mysql
datadir=/data/3306/data
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOF
slave2(db03)：
cat > /etc/my.cnf < [mysqld]
basedir=/data/app/mysql
datadir=/data/3306/data
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF
4.4.3 初始化数据
mysqld --initialize-insecure --user=mysql --basedir=/data/app/mysql--datadir=/data/3306/data
4.4.4 启动数据库
/etc/init.d/mysqld start
4.4.5 构建主从：
master:51
slave:52,53
51:
mysql -e "grant replication slaveon *.* to repl@'10.0.0.%' identified by '123'; "
52\53:
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
5. 主从复制架构演变
5.1 原生态复制结构演变 1主1从、1主N从
多级主从
5.2 扩展架构 读写分离
高可用
分布式架构
=================================
第十章MySQL高可用及读写分离技术 0. MHA高可用架构介绍及搭建过程
0.1 规划: 主库:
51 node
从库:
52node
53nodemanager
0.2 准备环境 略。1主2从GTID
0.3 配置关键程序软连接 ln -s /data/app/mysql/bin/mysqlbinlog/usr/bin/mysqlbinlog
ln -s /data/app/mysql/bin/mysql/usr/bin/mysql
0.4 配置各节点互信(各节点之间无密码SSH) # db01：
rm -rf /root/.ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp-r/root/.ssh10.0.0.52:/root
scp-r/root/.ssh10.0.0.53:/root
各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
0.5 安装软件 0.5.1 下载mha软件
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
0.5.2 所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node*.rpm
0.5.3 在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
0.5.4Manager软件安装（db03）
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager*.rpm
0.6配置文件准备(db03) 0.6.1 创建配置文件目录
mkdir -p /etc/mha
0.6.2 创建日志目录
mkdir -p /var/log/mha/app1
0.6.3 编辑mha配置文件
vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog/
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root


[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
0.7 状态检查 ### 互信检查
masterha_check_ssh--conf=/etc/mha/app1.cnf
### 主从状态检查
masterha_check_repl --conf=/etc/mha/app1.cnf
0.8 开启MHA(db03)： nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
0.9 查看MHA状态 [root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
1. 什么是高可用?
企业高可用标准：全年无故障时间
无故障时间故障时间
99.9%0.1%= 525.6minKA+双主 ：人为干预
99.99%0.01%= 52.56minMHA：半自动化
99.999%0.001%= 5.256minPXC 、 MGR 、MGC
99.9999%0.0001%= 0.5256 min自动化、云化、平台化
2. MHA的软件结构
一堆perl写的脚本。
2.1 manager 组件 masterha_manger启动MHA
masterha_check_ssh检查MHA的SSH配置状况
masterha_check_repl检查MySQL复制状况
masterha_master_monitor检测master是否宕机
masterha_check_status检测当前MHA运行状态
masterha_master_switch控制故障转移（自动或者手动）
masterha_conf_host添加或删除配置的server信息
2.2 node 组件 save_binary_logs保存和复制master的二进制日志
apply_diff_relay_logs识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs清除中继日志（不会阻塞SQL线程）
3. 站在产品经理角度，评估高可用软件设计
3.1 监控 3.2 选主 3.3 数据补偿 3.4 故障转移 3.5 应用透明 3.6 自动提醒 3.7 自愈 4. MHA FailOver 原理
4.1 监控 ： 通过 masterha_master_monitor ，每隔ping_interval秒探测一次Master 心跳。
监测不到心跳，一共给4次机会。
4.2 选主 4.2.1 日志量（latestslave）
各个从库的日志量。
无GTID：
[root@db02 ~]#mysql -e "show slave status\G" |grep "Master_Log"
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 194
有GTID：
[root@db02 ~]#mysql -e "show slave status\G" |grep "Executed_Gtid_Set"
Executed_Gtid_Set: 1c35b73a-7321-11ea-8974-000c29248f69:1-6
4.2.2候选主 candidate master
candidate_master=1强制某个节点为备选主。如果日志量超过100M差异，放弃掉他。
check_repl_delay=0不检查日志量的差异。
4.2.3 如果没有权重，从库日志量一样
根据配置文件的先后顺序选择新主。
4.2.4 默认
从库日志量和主库延时100M以上。
4.3 日志补偿 4.3.1 if主库ssh 能连接
各个从节点，通过save_binary_logs 立即保存缺失部分的binlog到/var/tmp/xxxxx
怎么判断缺失日志？
有GTID？
[root@db01 ~]# mysql -e "show master status; "
[root@db02 ~]# mysql -e "show slave status\G" |grep "Retrieved_Gtid_Set"
4.3.2 eles 主库 ssh 不能连接
从节点调用apply_diff_relay_logs，计算两个从节点的relay-log日志差异。
4.4 故障转移 1. 取消所有节点的从库状态
2. 构建新的主从关系
4.5 自动将故障节点，从配置文件剔除 --remove_dead_master_conf
4.6 自杀 manager自动退出。
4.7 应用透明: vip 4.8 数据补偿补充方案：binlog_server 4.9 切换提醒：send_report 5. 模拟故障并恢复
5.0 工作状态查看
[root@db03 app1]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:17501) is running(0:PING_OK), master:10.0.0.51
5.1 宕主库测试 [root@db01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL............ SUCCESS!
[root@db01 ~]#
5.2 看日志 [root@db03 app1]# vim /var/log/mha/app1/manager
5.3 恢复 5.3.1 修复故障节点
[root@db01 ~]# /etc/init.d/mysqld start
Starting MySQL.. SUCCESS!
如果生产怎么办？
按实际情况。
5.3.2 恢复主从
change master to
master_host='10.0.0.52',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
5.3.3 修复配置文件
方法一：
vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306
方法二：
masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --hostname=10.0.0.51 --block=server10 --params="port=3306"
masterha_conf_host --command=delete --conf=/etc/mha/app1.cnf --block=server1
5.3.4 预检测脚本
[root@db03 ~]# masterha_check_ssh--conf=/etc/mha/app1.cnf
[root@db03 ~]# masterha_check_repl--conf=/etc/mha/app1.cnf
5.3.5 启动MHA
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:24316) is running(0:PING_OK), master:10.0.0.52
[root@db03 ~]#
6. 应用透明---VIP
vip :10.0.0.55/24
6.1 vip 故障转移脚本 上传mha_script.tar文件到/usr/local/bin 解压
6.2 修改权限 [root@db03 bin]# chmod +x /usr/local/bin/*
6.3 修改内容 [root@db03 bin]# cp master_ip_failover master_ip_failover.bak
my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
my $ssh_Bcast_arp= "/sbin/arping -I eth0 -c 3 -A 10.0.0.55";
6.4 修改Manager 配置文件 vim /etc/mha/app1.cnf
master_ip_failover_script=/usr/local/bin/master_ip_failover
6.5 重启MHA [root@db03 bin]# masterha_stop--conf=/etc/mha/app1.cnf
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
6.6 手工在主库添加VIP [root@db02 ~]# ifconfig ens33:1 10.0.0.55/24
7. 故障提醒功能
7.1 准备脚本 [root@db03 bin]# cp send_report send_report.bak1
my $smtp='smtp.qq.com'; # smtp服务器
my $mail_from='22654481@qq.com'; # 发件箱
my $mail_user='22654481'; # 用户名 QQ号
my $mail_pass='gemghsvgkeyzcagh'; # 授权码
my $mail_to=['22654481@qq.com']; # 收件箱
#my $mail_to=['to1@qq.com','to2@qq.com'];
7.2 修改配置文件 vim /etc/mha/app1.cnf
# 添加一行：
report_script=/usr/local/bin/send_report
7.3 重启MHA [root@db03 bin]# masterha_stop--conf=/etc/mha/app1.cnf
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
7.4 模拟主库宕机 7.4.1 确认主库
[root@db03 bin]# masterha_check_status--conf=/etc/mha/app1.cnf
app1 (pid:27096) is running(0:PING_OK), master:10.0.0.52
7.4.2 宕主库
[root@db02 ~]# /etc/init.d/mysqld stop
Shutting down MySQL............ SUCCESS!
7.4.3 观察 vip 漂移
7.4.4 观察 邮件
7.5修复MHA 架构1主2从 略
8. 日志补偿的冗余方案--binlog_server
8.1 创建必要目录(db03) mkdir -p /data/binlog_server/
chown -R mysql.mysql /data/*
cd/data/binlog_server/
[root@db03 ~]# mysql -e "show slave status \G"|grep "Master_Log"
Master_Log_File: mysql-bin.000008
Read_Master_Log_Pos: 194
Relay_Master_Log_File: mysql-bin.000008
Exec_Master_Log_Pos: 194
[root@db03 ~]#
mysqlbinlog-R --host=10.0.0.51 --user=mha --password=mha --raw--stop-never mysql-bin.000008 &
注意：
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
8.2 配置文件设置 vim /etc/mha/app1.cnf
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/binlog_server/
8.3 重启MHA [root@db03 bin]# masterha_stop--conf=/etc/mha/app1.cnf
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
9. MHA的维护操作 - 在线切换功能
9.1 只切换角色 masterha_master_switch--conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.52 --orig_master_is_new_slave --running_updates_limit=10000
注意：
master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes
1. 此种方法 切换，要注意将原主库，FTWRL，否则会造成主从不一致。
2. 手工切换vip
3. 重新拉去新主库的binlog
9.2 master_ip_online_change_script功能实现
功能: 在线切换时，自动锁原主库，VIP自动切换
9.2.1 准备切换脚本
vim /usr/local/bin/master_ip_online_change
my $vip = "10.0.0.55/24";
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key $vip down";
my $ssh_Bcast_arp= "/sbin/arping -I ens33 -c 3 -A 10.0.0.55";
9.2.2 修改MHA配置文件
vim /etc/mha/app1.cnf
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
9.2.3 停 MHA
[root@db03 bin]# masterha_stop--conf=/etc/mha/app1.cnf
9.2.4 检查repl
[root@db03 bin]# masterha_check_repl--conf=/etc/mha/app1.cnf
9.2.4 在线切换
masterha_master_switch--conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.51 --orig_master_is_new_slave --running_updates_limit=10000
9.2.5 重构binlogserver
[root@db03 bin]# ps -ef |grep mysqlbinlog
root28144162720 17:50 pts/100:00:00 mysqlbinlog -R --host=10.0.0.52 --user=mha --password=x x --raw --stop-never mysql-bin.000005
root28529162720 18:03 pts/100:00:00 grep --color=auto mysqlbinlog
[root@db03 bin]# kill -9 28144
[root@db03 bin]# cd /data/binlog_server/
[root@db03 binlog_server]# ll
total 4
-rw-r----- 1 root root 194 Apr1 17:50 mysql-bin.000005
[root@db03 binlog_server]# rm -rf *
[root@db03 binlog_server]# mysqlbinlog-R --host=10.0.0.51 --user=mha --password=mha --raw--stop-never mysql-bin.000009 &
[1] 28534
9.2.6 启动MHA
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[root@db03 binlog_server]# masterha_check_status--conf=/etc/mha/app1.cnf
app1 (pid:28535) is running(0:PING_OK), master:10.0.0.51
MHA 高可用环境搭建
6.1 规划: 主库: 51 node
从库:
52node
53nodemanager
6.2 准备环境（略。1主2从GTID） 6.3 配置关键程序软连接 ln -s /data/app/mysql/bin/mysqlbinlog/usr/bin/mysqlbinlog
ln -s /data/app/mysql/bin/mysql/usr/bin/mysql
6.4 配置各节点互信(各节点之间无密码SSH) # db01：
rm -rf /root/.ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp-r/root/.ssh10.0.0.52:/root
scp-r/root/.ssh10.0.0.53:/root
各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
6.5 安装软件 6.5.1 下载mha软件
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
6.5.2 所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
6.5.3 在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
6.5.4Manager软件安装（db03）
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
6.6配置文件准备(db03) 6.6.1 创建配置文件目录
mkdir -p /etc/mha
6.6.2 创建日志目录
mkdir -p /var/log/mha/app1
6.6.3 编辑mha配置文件
vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/3306/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root


[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
6.7 状态检查 ### 互信检查
masterha_check_ssh--conf=/etc/mha/app1.cnf
### 主从状态检查
masterha_check_repl --conf=/etc/mha/app1.cnf
6.8 开启MHA(db03)： nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null> /var/log/mha/app1/manager.log 2>&1 &
6.9 查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf

    推荐阅读


    上一篇：115|115 Oo老队长 4days#裂变实验室训练营#

    下一篇：Day09_Day10_作业