基于MHA的MySQL高可用架构，VIP漂移

最新推荐文章于 2024-03-29 19:08:30 发布
最新推荐文章于 2024-03-29 19:08:30 发布
阅读量1.6k 收藏 7
点赞数 1
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/asufeiya/article/details/102865808
版权

建议:在做MHA之前 不要和之前的实验混淆 做好gtid复制就好
在这里插入图片描述
在这里插入图片描述在这里插入图片描述

1.在主库开启日志（1.binlog二进制日志0.1：特点是只记录了有变化的数据，select语句不记入。比.sql文件同步更有效率，最后是模拟信号传输，和01最为接近，更容易被保存下来，比如系统崩溃了，01更好保存哦；
2.授权，允许哪些设备同步哪些数据，） 从库（会有两个进程，1.I/O进程读取binlog,然后回来，典型的0和1，
2.SQL进程翻译：导入MYSQL中，MYSQL中是SQL语句，把0和和1翻译成SQL语句，但是SQL进程无法读取IO进程，因此就出现了中继日志，SQL从中继日志读取）

1.MHA介绍

MHA是一套相对成熟的MySQL高可用方案，能做到在0~30s内自动完成数据库的故障切换操作，在master服务器不宕机的情况下，基本能保证数据的一致性,以达到真正意义上的高可用。

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。
在这里插入图片描述

MHA工作原理总结为以下几条：

从宕机崩溃的master保存二进制日志事件（binlog events）；
识别含有最新更新的slave；
应用差异的中继日志（relay log）到其他slave；
应用从master保存的二进制日志事件（binlog events）；
提升一个slave为新master；
使用其他的slave连接新的master进行复制。

2.MHA的要求

（1）需要奇数个节点
（2）当一个master节点挂掉之后投票选出一个新的master，偶数个节点会出现票数相同的状况，但奇数个就不会
（3）所有数据节点的数据一致，每一台数据节点都有可能作为master
（4）每个节点都要安装master和slave插件；
当master节点挂了之后，一般选出数据最近的slave节点作为新的master节点
数据最近指的是数据的差异性小

3.搭建实验环境

主机名 	IP 	角色
server1 	172.25.63.1 	master
server2 	172.25.63.2 	slave（备master）
server3 	172.25.63.3 	slave
server4 	172.25.63.4 	MHA

准备新的虚拟机
在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述
安装解压数据库
在这里插入图片描述在这里插入图片描述在这里插入图片描述

[root@server1 mysql]# vim /etc/my.cnf
加入一下内容：
 29 server-id=1   //复制集群中的各节点的id均必须唯一
 30 gtid_mode=ON
 31 enforce_gtid_consistency=ON
 32 log_bin=binlog     开启binlog日志
 33 log_slave_updates=ON     允许从库更新

在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述server2
在这里插入图片描述在这里插入图片描述在这里插入图片描述server3
在这里插入图片描述在这里插入图片描述主从复制
在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述可以测试是否主从复制

mysql高可用之MHA

(在有报错的时候，先测试主从数据是否同步)

关闭server3上的proxy

killall mysql-proxy   （如果在之前的基础上的话需要做，但是此处重新安装虚拟机了，因此不许亚做）

#修改server3的配置：
vim /etc/my.cnf

server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
log_bin=binlog

不需要做半同步复制（这些不用做）
#在server1和server2上都安装半同步插件
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';	
##每个节点都安装master和slave插件是因为高可用需要每个节点都可以做master或者slave

#重启io线程使server1和server2同步

#server1和server2都激活半同步插件
mysql> SET GLOBAL rpl_semi_sync_master_enabled =1;

#server2上先不用设置这个
mysql> SET GLOBAL rpl_semi_sync_master_timeout =10000000000000000000;	##半同步超时时间，生产环境应该设置为无穷大，这里这个值是我试出来的最大值，再大就会报错，上课时可以让学生自己试最大值

mysql> show variables like '%rpl%';	##查看
##################################不需要

##配置server3
#先删除数据目录中的内容 rm -fr /var/lib/mysql/*

#启动mysqld
systemctl start mysqld

#初始化
mysql_secure_installation

#server3上配置mysql的GTID主从复制
mysql> change master to master_host='172.25.136.1', master_user='repl', master_password='Wsp+123ld', master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)

mysql> start slave;

#####这里如果出现server3无法同步的情况，怎么解决(1236错误)
先查看gtid执行了多少
mysql> show global variables like '%gtid%';
+----------------------------------+------------------------------------------+
| Variable_name                    | Value                                    |
+----------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery      | ON                                       |
| enforce_gtid_consistency         | ON                                       |
| gtid_executed                    | 1a49d884-4b83-11e9-913f-5254008ec469:1-4 |
| gtid_executed_compression_period | 1000                                     |
| gtid_mode                        | ON                                       |
| gtid_owned                       |                                          |
| gtid_purged                      | 1a49d884-4b83-11e9-913f-5254008ec469:1-4 |
| session_track_gtids              | OFF                                      |
+----------------------------------+------------------------------------------+

gtid_executed表示已经执行了多少，gtid_purged表示执行完清除了二进制日志清除了多少
因为日志已经清除，所以slave节点无法同步数据


先在server1上备份所有数据

mysqldump --all-databases --single-transaction --triggers --routines --events --host=127.0.0.1 --port=3306 --user=root --password=Wsp+123ld > wsp.sql

然后在server3上进行导入

[root@server3 ~]# mysql -p < wsp.sql

会有报错
[root@server3 ~]# mysql -p < wsp.sql 
Enter password: 
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

登录数据库，清除原来数据

mysql> stop slave;

mysql> reset master;

再导入，正常

进入数据库，重新配置复制

mysql> CHANGE MASTER TO MASTER_HOST = '172.25.0.1', MASTER_USER = 'repl', MASTER_PASSWORD = 'Wsp+123ld', MASTER_AUTO_POSITION = 1;

mysql> start slave;

主从复制正常



#安装并启用半同步插件  ##其实不需要这步
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

mysql> SET GLOBAL rpl_semi_sync_slave_enabled =1;

#为了不每次启动数据库都激活插件，写入配置文件（server1 2 3都写,，写在配置文件最后）

vim /etc/my.cnf

rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=10000000000000000000

rpl_semi_sync_slave_enabled=1


#配置高可用(再开一台server4来做master，因为高可用一般都是奇数个节点，因为如果master挂了，其他从节点需要投票选举一个新的master，偶数节点可能出现投票数相同)

从250上下载MHA-7目录
在server4上安装：

在这里插入图片描述

yum install -y mha4mysql-manager-0.58-0.el7.centos.noarch.rpm perl-* mha4mysql-node-0.58-0.el7.centos.noarch.rpm

在这里插入图片描述
生成ssh密钥，管理节点是不需要输入密码，将生成的公钥和私钥传给数据节点

#配置免密访问（server4需要连接server1 2 3都免密码）
在server4上：
[root@server4 ~]# ssh-keygen	##先生成密钥

[root@server4 ~]# ssh-copy-id server1

[root@server4 ~]# ssh-copy-id server2	#发送密钥

[root@server4 ~]# ssh-copy-id server3

在这里插入图片描述在这里插入图片描述

在这里插入图片描述在这里插入图片描述

ssh-keygen  产生公钥与私钥对.
ssh-copy-id 将本机的公钥复制到远程机器的authorized_keys文件中，
ssh-copy-id也能让你有到远程机器的home, ~./ssh , 和 ~/.ssh/authorized_keys的权利

第一步:在本地机器上使用ssh-keygen产生公钥私钥对

    $ ssh-keygen

第二步:用ssh-copy-id将公钥复制到远程机器中

$  ssh-copy-id -i .ssh/id_rsa.pub  用户名字@192.168.x.xxx

注意: ssh-copy-id 将key写到远程机器的 ~/ .ssh/authorized_key.文件中
第三步: 登录到远程机器不用输入密码

    $  ssh 用户名字@192.168.x.xxx

    Last login: Sun Nov 16 17:22:33 2008 from 192.168.1.2

#其他3个节点都安装mha4mysql-node-0.58-0.el7.centos.noarch.rpm即可

yum install -y mha4mysql-node-0.58-0.el7.centos.noarch.rpm

在这里插入图片描述在这里插入图片描述在这里插入图片描述

#在server4上配置mha工作目录及配置文件
#参考https://www.cnblogs.com/gomysql/p/3675429.html

mkdir /etc/masterha

vim /etc/masterha/app1.cnf

[server default]
manager_workdir=/etc/masterha
manager_log=/var/log/masterha.log  # manager 日志文件
master_binlog_dir=/etc/masterha
#master_ip_failover_script= /usr/local/bin/master_ip_failover
#master_ip_online_change_script= /usr/local/bin/master_ip_online_change
password=Wsp+123ld  #MySQL管理帐号和密码
user=root
ping_interval=1
remote_workdir=/tmp
repl_password=Wsp+123ld
repl_user=repl  # 复制帐号和密码
#report_script=/usr/local/send_report
#secondary_check_script= /usr/local/bin/masterha_secondary_check -s server03 -s server02
#shutdown_script=""
ssh_user=root # 系统ssh用户

[server1]
hostname=172.25.136.1
port=3306

[server2]
hostname=172.25.136.2
port=3306
candidate_master=1  
check_repl_delay=0

[server3]
hostname=172.25.136.3
port=3306
no_master=1	##no_master表示这个节点不能作为master

在这里插入图片描述在这里插入图片描述在这里插入图片描述
管理节点ssh检查管理节点ssh检查

##检测ssh连接
[root@server4 masterha]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

在这里插入图片描述

发现报错，server1 2 3互相之间不免密
拷贝server4上的密钥给server1 2 3

[root@server4 ~]# scp -r .ssh server1:
[root@server4 ~]# scp -r .ssh server2:
[root@server4 ~]# scp -r .ssh server3:

在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述

再检测ssh，成功
masterha_check_ssh --conf=/etc/masterha/app1.cnf

在这里插入图片描述

接下来检测复制功能
[root@server4 ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf

发现有报错
Fri Mar 22 10:03:45 2019 - [error][/usr/share/perl5/vendor_perl/MHA/Server.pm, ln180] Got MySQL error when connecting 172.25.0.2(172.25.0.2:3306) :1130:Host 'server4' is not allowed to connect to this MySQL server, but this is not a MySQL crash. Check MySQL server settings.

这是因为server4默认是用root远程连接数据库，但是在配置数据库是已经禁用了root的远程连接

在这里插入图片描述在这里插入图片描述

在主库上授权用户
mysql> grant all on *.* to root@'%' identified by 'Wsp+123ld';

在这里插入图片描述

再检测发现可能卡住了，因为之前半同步的配置写在了配置文件里，数据不同步就会卡住，在所有节点配置文件里删除半同步配置，只保留之前的
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
log_bin=binlog
##所有节点的配置文件必须一样！！！！（前面的内容其实都不需要做 只要保持三个server的my.cnf的内容与这里的一致就可以 三台做好gtid的复制就ok ）
##而且三个节点必须有数据（数据必须同步）

再检测，成功

在这里插入图片描述

再在两个slave节点设置只读（不写在配置文件里，因为slave随时可能切换为master）
mysql> set global read_only=1;

#测试manager能否开启   nohup:后台作业    
nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha.log 2>&1 &

在这里插入图片描述

一.1测试手动failover切换

先关闭manager，不关的话切不了，manager就是自动切换的工具

[root@server4 masterha]# masterha_stop --conf=/etc/masterha/app1.cnf

在这里插入图片描述

server1:systemctl stop mysqld

在这里插入图片描述

#手动切换
masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=172.25.0.1 --dead_master_ip=172.25.0.1 --dead_master_port=3306 --new_master_host=172.25.0.2 --new_master_port=3306
'手动切换之前，需要保证主从同步正常，repl复制用户能够远程连接'

中间都选yes

切换成功后，可以在server3上看到它的master已经变成了server2
而server2已经时master了

在这里插入图片描述在这里插入图片描述在这里插入图片描述

再手动开启server1，作为slave加入集群

[root@server1 ~]# systemctl start mysqld

mysql> CHANGE MASTER TO MASTER_HOST = '172.25.0.2', MASTER_USER = 'repl', MASTER_PASSWORD = 'Wsp+123ld', MASTER_AUTO_POSITION = 1;

mysql> start slave;

mysql> show slave status\G
至次完成了一次手动切换

在这里插入图片描述在这里插入图片描述

这时会在/etc/masterha目录下生成一个app1.failover.complete文件，是来记录failover情况的，再进行failover时必须先把这个文件删除，不然不会failover

#一.2.手动在线切换，刚才是master挂掉后切换

masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=172.25.0.1 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000

又切换回172.25.0.1为master

在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述

二.测试半自动failover

首先清理app1.failover.complete

开启mha manager
[root@server4 masterha]# nohup masterha_manager --conf=/etc/masterha/app1.cnf &>/dev/null &     
ps aux可以看到masterha_manager进程    但是如果你关闭mysql服务，server4上监控进程停止
mha manager自带守护进程

在这里插入图片描述

在server1上查看
[root@server1 ~]# ps ax | grep mysql
 2320 ?        Sl     0:00 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
 2366 pts/0    S+     0:00 grep --color=auto mysql

看到mysql的进程

kill -9 2320

再查看，发现mysql进程又开启了
[root@server1 ~]# ps ax | grep mysql
 2400 ?        Sl     0:00 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
 2431 pts/0    S+     0:00 grep --color=auto mysql

在server1上手动关闭mysqld

[root@server1 ~]# systemctl stop mysqld

自带守护进程
在这里插入图片描述在这里插入图片描述等待几秒再次查看又成功yes
在这里插入图片描述在这里插入图片描述再次关掉服务
在这里插入图片描述查看日志
在这里插入图片描述自动切换成功

在server4上查看

[root@server4 masterha]# cat /var/log/masterha.log

发现已经切换，同时manager进程退出，所以全自动需要脚本！！！！！！！！！！！！！！！

在这里插入图片描述在这里插入图片描述

先把server1加回集群

mysql> CHANGE MASTER TO MASTER_HOST = '172.25.0.2', MASTER_USER = 'repl', MASTER_PASSWORD = 'Wsp+123ld', MASTER_AUTO_POSITION = 1;

mysql> start slave;

在这里插入图片描述在这里插入图片描述在这里插入图片描述

三.1配置脚本和vip漂移

因为用户访问入口只能有一个，所以需要配置vip

编辑master_ip_failover 和 master_ip_online_change 两个脚本
修改内容：

my $ssh_start_vip = "/sbin/ip addr add $vip dev eth0";
my $ssh_stop_vip = "/sbin/ip addr del $vip dev eth0";

在这里插入图片描述在这里插入图片描述注意：vip的修改也要修改 172.25.63.100 要和下面给添加的vip一致，不然就错了
在这里插入图片描述在这里插入图片描述
配置自动添加和删除vip

cp master_ip_failover master_ip_online_change /usr/local/bin
cd /usr/local/
cd bin/
chmod +x master_ip_failover master_ip_online_change

在这里插入图片描述

###注意在server4的配置文件种 这两行的注释要打开
master_ip_failover_script= /usr/local/bin/master_ip_failover
master_ip_online_change_script= /usr/local/bin/master_ip_online_change

在这里插入图片描述在这里插入图片描述
#目前server2是master，所以先给server2添加vip
在这里插入图片描述

[root@server2 ~]# ip addr add 172.25.0.100/24 dev eth0

在这里插入图片描述 server4 手动切换master到server1（先手动再自动）
测试vip漂移

[root@server4 bin]# masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=172.25.0.1 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000

可以看到切换vip

***************************************************************
Disabling the VIP - 172.25.0.100/24 on old master: 172.25.0.2
***************************************************************


***************************************************************
Enabling the VIP - 172.25.0.100/24 on new master: 172.25.0.1 
***************************************************************

在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述而此时server2上的vip自动删除，故完成了vip漂移。
在这里插入图片描述

三.2使用脚本实现自动切换master

#测试全自动切换

在server4上先删除app1.failover.complete

开启manager，创建监控master的进程

nohup masterha_manager --conf=/etc/masterha/app1.cnf &>/dev/null &

然后在master（server1）上关闭mysql，模拟故障

再在server4上查看日志

cat /var/log/masterha.log
可以看到切换成功，vip也成功漂移

开启manager，创建监控master的进程
在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述故发现vip又漂移到了server2上，完成了自动实现vip漂移

注意：每一次切换都会生成一个master.failover.complete文件（简称故障文件），要将这个文件删除，否则会出错
创建一个监控master的进程，这个进程会实时监控master节点的状态，一旦master节点出现故障（宕机）
server4（管理节点）就会自动执行/usr/local/bin下的两个脚本，在正常运行的节点中选择一个最新的来作为新的master节点
同时当前的进程更会挂掉，因为他监控的master已经不再当前集群

做完实验关闭服务
在这里插入图片描述在这里插入图片描述

啾咪嘻啾咪
关注
  • 1
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第98讲：MHA高可用集群VIP地址配置与漂移实践
江晓龙的博客
02-18 991
当主库发生故障，从库切换成主库后，程序是无感知的，程序并不知道谁成为了主库，程序还是会连接曾经的主库，就会导致平台访问异常，因此我们需要准备一个VIP漂移地址，当主库故障后，VIP就漂移到新的主库上，保证平台的高可用。第一次配置VIP地址，需要现在主库对应的网卡上配置好VIP地址，否则当故障出现时，VIP地址不能漂移到新的主库，并且还会报错，因为脚本要先删掉主库中的VIP，然后在新的主库上添加，如果一开始就不存在，肯定会报错。目前mysql-3成为了主库，VIP也漂移到了mysql-3的服务器中。
mysql mha keepalive vip安装配置.docx
12-24
mysql mha keepalive vip安装配置.docx
Mysql数据库——MHA高可用配置及故障切换
最新发布
一坨小橙子的博客
03-29 1255
MHA概述、数据同步方式、搭建MHA高可用
MHA keepalived mysql
jnrjian的博客
01-04 471
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
mysql + mha + keepalive + vip_MYSQL + MHA +keepalive + VIP安装配置(二)--MHA的配置
weixin_42116058的博客
02-07 102
一、总概1、MHA介绍MHA(Master High Availability)是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).MHA有两部分组成:MHA Manager(管理节点)和MHA Node(数据节点).MHA Manager可以单独部署在一台独立机器上管理多个master-slave集群,也可以部署在一台slave上.MHA Mana...
MYSQL高可用架构之MHA实战三 mha+keepalive
wszhm123的博客
09-09 921
MYSQL高可用架构之MHA实战三 mha+keepalive
MySQL MHA高可用架构搭建手册
02-21
MySQL MHA高可用架构搭建手册
MySQL高可用架构MHA
01-09
MHA工作原理 部署MHA 1.配置四台主机ssh登录不用密码 ssh-keygen -t rsa ssh-copy-id 192.168.100.10（20.30.102） 2.上传安装包，解压编译安装 配置yum仓库 vim /etc/yum.repos.d/mhapath.repo ##进入yum仓库，...
实战基于MHA方式实现MySQL高可用
07-23
资源名称：实战基于MHA方式实现MySQL高可用资源截图： 资源太大，传百度网盘了，链接在附件中，有需要的同学自取。
MySQL高可用架构MHA软件包及脚本
12-21
MySQL高可用架构MHA的el5、el6、el7三个版本软件包及vip漂移、邮件通知脚本。
企业级mysql基于MHA的高可用集群部署
11-07
企业级mysql基于MHA的高可用集群部署
MySQL MHA KEEPALIVE最佳部署指南
01-19
MySQL MHA KEEPALIVE最佳部署指南
mysql mha keepalive_MYSQL + MHA +keepalive + VIP安装配置
weixin_34664586的博客
01-19 231
一、总概1、MHA介绍MHA(Master High Availability)是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).MHA有两部分组成:MHA Manager(管理节点)和MHA Node(数据节点).MHA Manager可以单独部署在一台独立机器上管理多个master-slave集群,也可以部署在一台slave上.MHA Mana...
MySQL——MHA原理介绍及VIP配置
hdfeng的博客
04-18 4938
文章目录MHA环境准备MHA原理MHA的组成MHA软件构成MHA安装及状态检查perl包安装及node、manager包安装MHA配置文件状态检查MHA故障处理MHA应用透明的VIP功能 MHA环境准备 准备三台装有mysql的节点，软链接的路径根据自己mysql程序安装的位置而定，链接完以后直接就能使用该命令了！ 主库： hdfeng01 node 从库： hdfeng02 node hdfe...
mysql产生漂移_第十七章 MySQL的VIP漂移和Atlas
weixin_32819955的博客
01-28 452
一、数据库VIP漂移1.VIP漂移的两种方式1.通过keepalived的方式2.使用MHA自带的脚本2.配置MHA脚本[root@db03 ~]# vim /service/mha/app1.cnf[server default]master_ip_failover_script=/service/mha/master_ip_failover3.编写脚本1)上传脚本#解压manager节点的ta...
Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复
vc33569的专栏
08-26 1269
MHA VIP漂移配置 常见生产故障解决
mysql mha+keepalived
wll的专栏
03-25 966
1、 三台机器配置互信关系 ssh-keygen -t dsa ssh-keygen -t rsa 2、 配置hosts文件 Vi /etc/hosts 10.10.6.86   dg 10.10.6.87   dg2 10.10.6.90   dgt 3、搭建主从从 dg--->dg2--->dgt 主(node)   从(node)    从(mange)
mysql地址漂移_keepalived应用：漂移IP的实现
weixin_42365334的博客
02-01 812
state BACKUP：在keepalived中2种模式，分别是master->backup模式和backup->backup模式。这两种模式有很大区别。在master->backup模式下，一旦主库宕机，虚拟ip会自动漂移到从库，当主库修复后，keepalived启动后，还会把虚拟ip抢占过来，即使设置了非抢占模式(nopreempt)抢占ip的动作也会发生。在backup-...
mysql高可用架构 -> MHA配置VIP漂移-05
weixin_30426957的博客
10-30 152
VIP漂移的两种方式 1）通过keepalived的方式，管理虚拟IP的漂移 2）通过MHA自带脚本方式，管理虚拟IP的漂移 MHA脚本方式 虚拟ip漂移的脚本下载地址 ->wgethttp://download.driverzeng.com/master_ip_failover 如果是wget下载的脚本，需要转换格式: [root@db03 mha]# dos2uni...
mysql高可用架构mha
08-30
MHA（Master High Availability）是一种用于MySQL数据库的高可用架构解决...总结来说，MHA是一种基于MySQL主从复制的高可用架构解决方案，能够自动监控和管理MySQL主节点和备节点，实现故障转移和故障恢复的自动化。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值