安科网

Mysql GTID Mha配置方法

MySQLl

MySQLl

2019-04-15

关注 关注

Gtid + Mha +Binlog server配置：

1：测试环境

OS：CentOS 6.5
Mysql：5.6.28
Mha：0.56

192.168.1.21 mysql1 M1
192.168.1.22 mysql2 S1
192.168.1.23 mysql3 S2 Mha manage、Binlog server

2：配置/etc/my.cnf相关参数,在3各节点中分别配置

binlog-format=ROW 
log-slave-updates=true 
gtid-mode=on 
enforce-gtid-consistency=true 
master-info-repository=TABLE 
relay-log-info-repository=TABLE 
sync-master-info=1 
slave-parallel-workers=2 
binlog-checksum=CRC32 
master-verify-checksum=1 
slave-sql-verify-checksum=1 
binlog-rows-query-log_events=1

设置root密码，创建复制用户：

mysql> use mysql;
mysql> GRANT ALL PRIVILEGES ON *.* TO root@"%" IDENTIFIED BY "oracle123";
mysql> update user set Password = password('oracle123') where User='root';
mysql> flush privileges;

mysql> GRANT replication slave ON *.* TO 'repl'@'%' identified by 'oracle';    

mysql> flush privileges;

3：在mysql2、mysql3配置Gtid复制

CHANGE MASTER TO 
MASTER_HOST = '192.168.1.21',
MASTER_PORT = 3306,
MASTER_USER = 'repl',
MASTER_PASSWORD = 'oracle',
MASTER_AUTO_POSITION = 1;

start slave;

mysql> show slave status\G
*************************** 1. row ***************************
        Slave_IO_State: Waiting for master to send event
         Master_Host: 192.168.1.21
         Master_User: repl
         Master_Port: 3306
        Connect_Retry: 60
       Master_Log_File: mysql-bin.000003
     Read_Master_Log_Pos: 524
        Relay_Log_File: mysql-relay-bin.000002
        Relay_Log_Pos: 734
    Relay_Master_Log_File: mysql-bin.000003
       Slave_IO_Running: Yes
      Slave_SQL_Running: Yes
       Replicate_Do_DB: 
      ......
 Master_SSL_Crlpath: 
      Retrieved_Gtid_Set: 9ee7c7af-cbf3-11e5-bf75-000c2923e459:1-2
      Executed_Gtid_Set: 9ee7c7af-cbf3-11e5-bf75-000c2923e459:1-2
        Auto_Position: 1
1 row in set (0.00 sec)

4：安装Mha

rpm -Uvh epel-release-6-8.noarch.rpm

配置SSH等效：

在所有节点都执行

ssh-keygen -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub root@mysql1
ssh-copy-id -i /root/.ssh/id_rsa.pub root@mysql2
ssh-copy-id -i /root/.ssh/id_rsa.pub root@mysql3

测试ssh登录，在3各节点分别测试：

ssh myqsl1
ssh myqsl2
ssh myqsl3

binlog server配置：在mysql3

mkdir -p /mysql/backup/binlog
/usr/local/mysql/bin/mysqlbinlog -R --raw --host=192.168.1.20 --user='root' --password='oracle123' --stop-never mysql-
bin.000003 &

最后那个binlog文件时给定从那个binlog文件开始。另外需要注意，当mysql1上的mysql进程退出后，binlog server也会退出。

需要安装一些包做支持，使用yum网络源；如安装遇到问题可以尝试yum update更新yum源或yum clean all清除缓存

在每个节点安装 mha4mysql-node

yum -y install perl-DBD-MySQL ncftp
rpm -Uvh mha4mysql-node-0.56-0.el6.noarch.rpm

在mysql3上安装mha-manager

yum install perl
yum install cpan
yum install perl-Config-Tiny
yum install perl-Time-HiRes 
yum install perl-Log-Dispatch
yum install perl-Parallel-ForkManager

如果安装perl-Log-Dispatch，perl-Parallel-ForkManager安装包报错：

需要先安装epel(可以参考https://fedoraproject.org/wiki/EPEL）

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

5：配置Mha,在mysql3

mkdir -p /etc/masterha/app1
vi /etc/masterha/app1.cnf
[server default]
user=root  
password=oracle123
manager_workdir=/etc/masterha/app1
manager_log=/etc/masterha/app1/manager.log
remote_workdir=/etc/masterha/app1
ssh_user=root
repl_user=repluser
repl_password=oracle
ping_interval=3
master_ip_failover_script=/etc/masterha/app1/master_ip_failover

[server1]
hostname=192.168.1.21
#ssh_port=9999
master_binlog_dir=/mysql/logs
check_repl_delay=0       #防止master故障时候，切换时slave有延迟，可在那里切不过来
candidate_master=1

[server2]
hostname=192.168.1.22
#ssh_port=9999
master_binlog_dir=/mysql/logs
candidate_master=1

[server3]
hostname=192.168.1.23
#ssh_port=9999
master_binlog_dir=/mysql/logs
no_master=1
ignore_fail=1           #如果这个节点挂了，mha将不可用，加上这个参数slave挂了一样可以用

[binlog1]                   #binlog server需要mysqlbinlog命令
hostname=192.168.1.23
master_binlog_dir=/mysql/backup/binlog    #读取binlog存放位置
ignore_fail=1
no_master=1

vi /etc/masterha/app1/master_ip_failover
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
use Getopt::Long;
my (
$command, $ssh_user, $orig_master_host, $orig_master_ip,
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port
);
my $vip = '192.168.1.20';#Virtual IP
my $gateway = '192.168.1.1';#Gateway IP
my $interface = 'eth0';
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig $interface:$key $vip;/sbin/arping -I $interface -c 3 -s $vip $gateway >/dev/null 2>&1";
my $ssh_stop_vip = "/sbin/ifconfig $interface:$key down";
GetOptions(
'command=s' => \$command,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,
'orig_master_port=i' => \$orig_master_port,
'new_master_host=s' => \$new_master_host,
'new_master_ip=s' => \$new_master_ip,
'new_master_port=i' => \$new_master_port,
);
exit &main();
sub main {
print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";
if ( $command eq "stop" || $command eq "stopssh" ) {
# $orig_master_host, $orig_master_ip, $orig_master_port are passed.
# If you manage master ip address at global catalog database,
# invalidate orig_master_ip here.
my $exit_code = 1;
eval {
print "Disabling the VIP on old master: $orig_master_host \n";
&stop_vip();
$exit_code = 0;
};
if ($@) {
warn "Got Error: $@\n";
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "start" ) {
# all arguments are passed.
# If you manage master ip address at global catalog database,
# activate new_master_ip here.
# You can also grant write access (create user, set read_only=0, etc) here.
my $exit_code = 10;
eval {
print "Enabling the VIP - $vip on the new master - $new_master_host \n";
&start_vip();
$exit_code = 0;
};
if ($@) {
warn $@;
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "status" ) {
print "Checking the Status of the script.. OK \n";
`ssh $ssh_user\@$orig_master_host \" $ssh_start_vip \"`;
exit 0;
}
else {
&usage();
exit 1;
}
}
# A simple system call that enable the VIP on the new master
sub start_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# A simple system call that disable the VIP on the old_master
sub stop_vip() {
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}
sub usage {
print
"Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --


orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

chmod 777 /etc/masterha/app1/

配置文件测试：

# masterha_check_ssh --conf=/etc/masterha/app1.cnf
Thu May 26 23:25:35 2016 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu May 26 23:25:35 2016 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Thu May 26 23:25:35 2016 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Thu May 26 23:25:35 2016 - [info] Starting SSH connection tests..
Thu May 26 23:25:35 2016 - [debug] 
Thu May 26 23:25:35 2016 - [debug] Connecting via SSH from [email protected](192.168.1.21:22) to [email protected](192.168.1.22:22)..
Thu May 26 23:25:35 2016 - [debug]  ok.
Thu May 26 23:25:35 2016 - [debug] Connecting via SSH from [email protected](192.168.1.21:22) to [email protected](192.168.1.23:22)..
Thu May 26 23:25:35 2016 - [debug]  ok.
Thu May 26 23:25:36 2016 - [debug] 
Thu May 26 23:25:35 2016 - [debug] Connecting via SSH from [email protected](192.168.1.22:22) to [email protected](192.168.1.21:22)..
Thu May 26 23:25:35 2016 - [debug]  ok.
Thu May 26 23:25:35 2016 - [debug] Connecting via SSH from [email protected](192.168.1.22:22) to [email protected](192.168.1.23:22)..
Thu May 26 23:25:36 2016 - [debug]  ok.
Thu May 26 23:25:36 2016 - [debug] 
Thu May 26 23:25:36 2016 - [debug] Connecting via SSH from [email protected](192.168.1.23:22) to [email protected](192.168.1.21:22)..
Thu May 26 23:25:36 2016 - [debug]  ok.
Thu May 26 23:25:36 2016 - [debug] Connecting via SSH from [email protected](192.168.1.23:22) to [email protected](192.168.1.22:22)..
Thu May 26 23:25:36 2016 - [debug]  ok.
Thu May 26 23:25:36 2016 - [info] All SSH connection tests passed successfully.

#masterha_check_repl --conf=/etc/masterha/app1.cnf
Thu May 26 22:52:30 2016 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu May 26 22:52:30 2016 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Thu May 26 22:52:30 2016 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Thu May 26 22:52:30 2016 - [info] MHA::MasterMonitor version 0.56.
Thu May 26 22:52:31 2016 - [info] GTID failover mode = 1
Thu May 26 22:52:31 2016 - [info] Dead Servers:
Thu May 26 22:52:31 2016 - [info] Alive Servers:
Thu May 26 22:52:31 2016 - [info]  192.168.1.21(192.168.1.21:3306)
Thu May 26 22:52:31 2016 - [info]  192.168.1.22(192.168.1.22:3306)
Thu May 26 22:52:31 2016 - [info]  192.168.1.23(192.168.1.23:3306)
Thu May 26 22:52:31 2016 - [info] Alive Slaves:
Thu May 26 22:52:31 2016 - [info]  192.168.1.22(192.168.1.22:3306) Version=5.6.28-log (oldest major version between slaves) log-bin:enabled
Thu May 26 22:52:31 2016 - [info]   GTID ON
Thu May 26 22:52:31 2016 - [info]   Replicating from 192.168.1.21(192.168.1.21:3306)
Thu May 26 22:52:31 2016 - [info]   Primary candidate for the new Master (candidate_master is set)
Thu May 26 22:52:31 2016 - [info]  192.168.1.23(192.168.1.23:3306) Version=5.6.28-log (oldest major version between slaves) log-bin:enabled
Thu May 26 22:52:31 2016 - [info]   GTID ON
Thu May 26 22:52:31 2016 - [info]   Replicating from 192.168.1.21(192.168.1.21:3306)
Thu May 26 22:52:31 2016 - [info]   Not candidate for the new Master (no_master is set)
Thu May 26 22:52:31 2016 - [info] Current Alive Master: 192.168.1.21(192.168.1.21:3306)
Thu May 26 22:52:31 2016 - [info] Checking slave configurations..
Thu May 26 22:52:31 2016 - [info] read_only=1 is not set on slave 192.168.1.22(192.168.1.22:3306).
Thu May 26 22:52:31 2016 - [info] read_only=1 is not set on slave 192.168.1.23(192.168.1.23:3306).
Thu May 26 22:52:31 2016 - [info] Checking replication filtering settings..
Thu May 26 22:52:31 2016 - [info] binlog_do_db= , binlog_ignore_db= 
Thu May 26 22:52:31 2016 - [info] Replication filtering check ok.
Thu May 26 22:52:31 2016 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Thu May 26 22:52:31 2016 - [info] HealthCheck: SSH to 192.168.1.23 is reachable.
Thu May 26 22:52:31 2016 - [info] Binlog server 192.168.1.23 is reachable.
Thu May 26 22:52:31 2016 - [info] Checking recovery script configurations on 192.168.1.23(192.168.1.23:3306)..
Thu May 26 22:52:31 2016 - [info]  Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/mysql/backup/binlog --output_file=/etc/masterha/app1/save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000004 
Thu May 26 22:52:31 2016 - [info]  Connecting to [email protected](192.168.1.23:22).. 
 Creating /etc/masterha/app1 if not exists..  ok.
 Checking output directory is accessible or not..
  ok.
Binlog found at /mysql/backup/binlog, up to mysql-bin.000004
Thu May 26 22:52:31 2016 - [info] Binlog setting check done.
Thu May 26 22:52:31 2016 - [info] Checking SSH publickey authentication settings on the current master..
Thu May 26 22:52:31 2016 - [info] HealthCheck: SSH to 192.168.1.21 is reachable.
Thu May 26 22:52:31 2016 - [info] 
192.168.1.21(192.168.1.21:3306) (current master)
 +--192.168.1.22(192.168.1.22:3306)
 +--192.168.1.23(192.168.1.23:3306)

Thu May 26 22:52:31 2016 - [info] Checking replication health on 192.168.1.22..
Thu May 26 22:52:31 2016 - [info] ok.
Thu May 26 22:52:31 2016 - [info] Checking replication health on 192.168.1.23..
Thu May 26 22:52:31 2016 - [info] ok.
Thu May 26 22:52:31 2016 - [info] Checking master_ip_failover_script status:
Thu May 26 22:52:31 2016 - [info]  /etc/masterha/app1/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.1.21 --orig_master_ip=192.168.1.21 --orig_master_port=3306 

IN SCRIPT TEST====/sbin/ifconfig eth1:1 down==/sbin/ifconfig eth1:1 192.168.1.20;/sbin/arping -I eth1 -c 3 -s 192.168.1.20 192.168.1.1 >/dev/null 2>&1===

Checking the Status of the script.. OK 
Thu May 26 22:52:34 2016 - [info] OK.
Thu May 26 22:52:34 2016 - [warning] shutdown_script is not defined.
Thu May 26 22:52:34 2016 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

MHA启动及关闭

nohup masterha_manager --conf=/etc/masterha/app1.cnf > /etc/masterha/app1/manager.log < /dev/null 2>&1 &

检查是否启动：

masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:11447) is running(0:PING_OK), master:192.168.1.21

停止Mha：

masterha_stop --conf=/etc/masterha/app1.cnf
Stopped app1 successfully.
[3]+ Exit 1         nohup masterha_manager --conf=/etc/masterha/app1.cnf > /etc/masterha/app1/manager.log < /dev/null 2>&1

测试：

说明，每次测试完成后，需要清理/etc/masterha/app1下的日志，然后启动Mha manager.

1：关闭mysql1上的mysql，查看从库从那里同步，以及mha日志输出

2：恢复mysql1为mysql2的slave，change master语句可以在/etc/masterha/app1/manager.log里找到。

在配置GTID复制时候遇到 1032错误，用以下方法解决

mysql> show global variables like '%gtid%';
+---------------------------------+------------------------------------------------------------------------------------+
| Variable_name          | Value                                       |
+---------------------------------+------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery   | OFF                                        |
| enforce_gtid_consistency    | ON                                         |
| gtid_executed          | 88b05570-2599-11e6-880a-000c29c18cf5:1-3,
9ee7c7af-cbf3-11e5-bf75-000c2923e459:1-4 |
| gtid_mode            | ON                                         |
| gtid_owned           |                                          |
| gtid_purged           |                                          |
| simplified_binlog_gtid_recovery | OFF                                        |
+---------------------------------+------------------------------------------------------------------------------------+

stop slave;
set gtid_next='9ee7c7af-cbf3-11e5-bf75-000c2923e459:4';
begin;
commit;
set gtid_next='automatic';
start slave;
show slave status\G;

mha mysql master

MySQLl

MySQLl

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

MySQL高可用之MHA

MHA Node运行在每台 MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新 数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过

herohope 2020-07-19

Mysql通过MHA实现高可用

MHA是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点

KFLING 2020-06-13

8.MHA高可用集群搭建

MHA通过masterha_manger脚本启动MHA的功能.自动判断所有从库的日志量.将最接近主库数据的从库作为新主.按照配置文件先后顺序的进行选新主.前提条件：1.最少三台MySQL服务器，1主2从。mysql> grant all privi

wiseMale 2020-05-11

MHA主库宕机，binlog保存

[ binlog]# mysqlbinlog -R --host=172.16.1.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &. -rw-rw---- 1

elitechen 2020-07-28

MHA搭建

先查看系统本身是否存在MySQL或者mariadb，若存在将其卸载：。rpm -qa | grep mysql && yum -y remove mysql. log-bin=mysql-bin，同理修改其他两个节点的配置

inhumming 2020-06-10

MHA+Altas 读写分离的结合

Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天

李高峰 2020-05-25

MySQL-高可用架构MHA

第1章 主从复制架构演变。多活:MGR ——5.7 新特性 MySQL Group replication --->Innodb Cluster. 第2章 MHA部署流程。这里我把管理节点安装在了db03上；在实际生产中，如果没有足够的服务器，也可以

这些年来 2020-05-25

MySQL MHA架构

MHA目前在MySQL高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在MySQL故障切换过程中，MHA 能做到快速自动切换操作，而且还能最大限度保持数据的一致性，该架构采用 perl 语言编写，可完成秒级别的主库故障切换。MHA Manag

ithzhang 2020-04-19

MHA之虚拟IP

在MySQL高可用之MHA部署这篇博文中，已经将MHA的基础架构部署完成，但是并没有解决一个虚拟IP的问题，因为当master宕机后，新的master顶上来，这时前端APP要连接的数据库IP已经发生了变化，为了解决这个问题，必然要引入虚拟IP，谈起虚拟IP

会哭的雨 2020-02-24

MySQL高可用集群之MHA

MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切

xiaojiang0 2020-02-22

mysql实现高可用架构之MHA

MHA是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating. MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的。slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节

康慧欣 2020-02-18

MySQL架构——MHA部署

目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作

阿亮 2019-12-25

MySQL数据库——MHA高可用集群架构（实战！！！）

在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

xiaobaif 2019-12-25

MHA高可用集群

本案例要求通过MHA 监控MySQL 数据库在故障时进行自动切换，不影响业务。

sofast 2019-12-25

MySQL数据库---MHA高可用群集架构

日本DeNA公司youshimaton 开发。一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失。使用MySQL 5.5的半同步复制，可以大大降

xiaoxiangyu 2019-12-23

MHA高可用群集基本部署（纯实战）

MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发。MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进

ShiShuo 2019-12-23

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

在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

贤冰 2019-12-19

MySQL高可用架构之MHA

MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切

herohope 2019-12-14

MySQL 有关MHA搭建与切换的几个错误log

Thu Nov 21 15:33:15 2018 - [info] MHA::MasterMonitor version 0.56.Thu Nov 21 15:33:16 2018 - [info] Got exit code 1 .Tue Nov 19

achiverhai 2019-12-06

基于 MHA 的MySQL高可用-CentOS7（理论）

MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探 测集群中

mycosmos 2019-11-04
MySQLl

MySQLl

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号