MySQL数据库高可用MHA、故障切换

最新推荐文章于 2024-04-25 15:19:34 发布
最新推荐文章于 2024-04-25 15:19:34 发布
阅读量449 收藏
点赞数
分类专栏： MySQL数据库 文章标签： mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_56667320/article/details/118935542
版权

文章目录

前言

MySQL服务器中，单台服务器无法承载服务量就配置多台MySQL服务器
多台MySQL服务器或者MySQL服务器无冗余的情况下，配置主从复制
MySQL服务器的读和写的压力不均衡使用MySQL的读写分离
MySQL的读写分离中Msater存在单点故障，就用到了MHA，也就是本篇会详细介绍的高可用

一、MHA概述

1、简介

  • 主要是为了解决msater只有一台，若master出现故障时就使用MHA解决单点故障问题
  • 一套优秀的MySQL高可用环境下故障切换和主从复制的软件
  • MySQL故障过程中，MHA能做到0-30秒内自动完成故障切换

2、MHA的组成(性能、组件)

  • MHA Manager (管理节点)
    • 可以借助于node组件，实现健康检查(ssh、主从复制)、控制故障切换
  • MHA Node 组件(数据节点)
    • 部署在所有MySQL服务器内；主要作用：
      • 定时汇报给主manager节点，mysql服务的状态
      • 监控本地mysql服务功能

主从复制架构:主从复制(一主多从) ; MHA架构(多主多从) ; MMM架构(双主多从)

3、特点

  • 自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失
    • 自动故障切换过程的本质
      • 故障切换（本质VIP漂移）
      • 自动（使用脚本触发自动）
  • 使用半同步复制，可以大大降低数据丢失的风险

4、总结

MHA为了解决的是故障切换，数据尽可能的保存，以及所有节点日志的一致性
在这里插入图片描述
当主宕机，提升从服务器为master服务器的机制

  1. 先取出bin-log和relay-log相差的日志值，如上图是相差100M的日志；即预选
  2. 择优；mster 1000M多个slave 980 900 920；即优选

二、搭建MySQL-MHA实验

1、实验环境

MHA-manager：192.168.35.30 ##管理节点，安装manager组件与node组件
MySQL服务器：只要用来调控与调用

角色ip
MHA-manager192.168.35.30
master192.168.35.40
slave1192.168.35.10
slave2192.168.35.20

定义节点服务器名称
hostnamectl set-hostname manager
su
hostnamectl set-hostname master
su
hostnamectl set-hostname slave1
su
hostnamectl set-hostname slave2
su

2、mysql服务器配置

2.1、配置主从复制

详见上一篇文章，更改点是需要注视掉从服务器配置文件/etc/my.cnf内的character_set_server=utf8
在这里插入图片描述

2.2、所有库配置软链接

ln -s /usr/local/mysql/bin/mysql /usr/sbin   //优化管理；mysql命令
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin   //节点恢复

2.3、所有数据库提权

grant replication slave on *.* to 'myslave'@'192.168.35.%' identified by '123'; 
grant all privileges on *.* to 'mha'@'192.168.35.%' identified by 'manager';
grant all privileges on *.* to 'mha'@'master' identified by 'manager';
grant all privileges on *.* to 'mha'@'slave1' identified by 'manager';
grant all privileges on *.* to 'mha'@'slave2' identified by 'manager';
set global read_only=1;		##不会对超级管理员super生效，普通用户
flush privileges;

测试：验证从服务器只读功能

msater端创建数据表ss
use zyt
create table ss(id int);

在这里插入图片描述
只读功能验证
在slave1服务器上

mysql -umyslave -p123 -h 192.168.35.40 -P 3306

在这里插入图片描述
这时slave1创建数据库gggg，报错提示只读，无法创建

3、配置MHA

3.1、安装epel源

在所有服务器上安装MHA依赖环境，首先安装epel源，只有安装了源 perl才会有

yum install epel-release --nogpgcheck -y		##安装epel源，并且不进行gph检查
yum install -y perl-DBD-MySQL \				##perl针对于mysql数据库
perl-Config-Tiny \			###从配置文件中提拿其中的值
perl-Log-Dispatch \			##log-日志
perl-Parallel-ForkManager \		##子进程的函数，多线程管理模式
perl-ExtUtils-CBuilder \			###扩展工具
perl-ExtUtils-MakeMaker \		###扩展工具
perl-CPAN		##cpan perl中的数据库

复制内容

yum install -y perl-DBD-MySQL \
perl-Config-Tiny \
perl-Log-Dispatch \
perl-Parallel-ForkManager \
perl-ExtUtils-CBuilder \
perl-ExtUtils-MakeMaker \
perl-CPAN

MHA 软件包对于每个操作系统版本不一样，这里Centos7.4必须选择0.57版本
在所有服务器上必须先安装node组件，最后在MHA-manager节点上安装manager组件
因为manager依赖node组件

3.2、所有服务器同步阿里云时间

[root@master bin]# ntpdate ntp.aliyun.com
20 Jul 19:34:27 ntpdate[60181]: adjust time server 203.107.6.88 offset 0.002699 sec
[root@master bin]# crontab -e
no crontab for root - using an empty one
crontab: installing new crontab
[root@master bin]# 
[root@master bin]# crontab -l
*/10 * * * * /usr/sbin/ntpdate ntp.aliyun.com

3.3、所有服务器安装node组件

当前目录上传node压缩包、上传manager压缩包

tar zxvf mha4mysql-node-0.57.tar.gz -C /root
cd mha4mysql-node-0.57
perl Makefile.PL
make && make install

3.4、在MHA节点上安装manager组件

必须先安装node才能安装manager组件

tar xf mha4mysql-manager-0.57.tar.gz -C /root 
cd mha4mysql-manager-0.57
perl Makefile.PL
make && make install

3.5、检测manager和node

  1. manager 安装后在/usr/local/bin目录下会生成几个工具，主要包括以下：
    masterha-check_ssh 检查MHA的SSH配置状况（免交互）
    masterha_check_repl 检查MySQL复制状况
    masterha_manager 启动manager的脚本
    masterha_check_status 检查当前MHA运行状态
    masterha_master_monitor 检查master是否宕机
    masterha_master_switch 控制故障转移(自动或者手动）
    masterha_conf_host 添加或删除配置的server信息
    masterha_stop 关闭manager
  2. node 安装后也会在/usr/local/bin目录下生成几个脚本，需要进行检查，主要包括以下
    save_binary_logs #保存和复制master的二进制日志
    apply_diff_relay_logs #识别差异的中继日志时间，并将其差异的事件应用于其他的slave；filter：过滤
    filter_mysqlbinlog #去除不必要的ROLLBACK回滚事件（MHA 已不适用这个工具）
    purge_relay_logs #清除中继日志（不会阻塞 SQL线程）
    在这里插入图片描述
    master宕机之后，slave1主备顶上，实现方式：vip虚拟ip漂移到slave1

4、配置无密码认证

4.1、在mannager上配置到所有数据库节点的无密码认证

ssh-keygen -t rsa
ssh-copy-id 192.168.35.10
ssh-copy-id 192.168.35.20
ssh-copy-id 192.168.35.30
ssh-copy-id 192.168.35.40
在这里插入图片描述

4.2、配置MHA-manager服务器

cp -ra /root/mha4mysql-manager-0.57/samples/scripts/ /usr/local/bin	##在MHA节点上复制相关脚本到/usr/local/bin目录
ll /usr/local/bin/scripts/		##拷贝后会有四个执行文件

-a：此选项通常在复制目录时使用，它保留链接、文件属性，并复制目录下的所有内容
-r: 递归

master_ip_failover #自动切换时 VIP管理的脚本
master_ip_online_change #在线切换时 VIP的管理
power_manager #故障发生后关闭主机的脚本
send_report #因故障切换后发送报警的脚本
在这里插入图片描述

4.3、使用脚本管理VIP

复制上述的master_ip_failover	到/usr/local/bin目录 这里使用脚本管理VIP
cp /usr/local/bin/scripts/master_ip_failover /usr/local/bin

在这里插入图片描述

vim /usr/local/bin/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.35.100';		##浮动IP
my $brdc = '192.168.35.255';	##广播地址
my $ifdev = 'ens33';		##基于master使用的网卡为ens33
my $key = '1';			##国际序列号；虚拟VIP的编号
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";	##使用ifoconfig命令将其启动，同时设置浮动地址
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";		##可以使用ifconfig命令将其down掉（关闭）
my $exit_code = 0;			##正常退出（返回状态码）
#my $ssh_start_vip = "/usr/sbin/ip addr add $vip/24 brd $brdc dev $ifdev label 	$ifdev:$key;/usr/sbin/arping -q -A -c 1 -I $ifdev $vip;iptables -F;";
#my $ssh_stop_vip = "/usr/sbin/ip addr del $vip/24 dev $ifdev label $ifdev:$key";	##另一只实现方案，注释掉，即使用的ip addr 简写ipa 检测所有的网卡
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" ) {

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" ) {

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";
exit 0;
}
else {
&usage();
exit 1;
}
}
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";
}

% s/^#// ###去除#开头的部分，PS:第一行添加#
在这里插入图片描述

4.4、创建MHA软件目录并拷贝配置文件

mkdir /etc/masterha
cp /root/mha4mysql-manager-0.57/samples/conf/app1.cnf /etc/masterha/
vim /etc/masterha/app1.cnf
[server default]
#日志文件
manager_log=/var/log/masterha/app1/manager.log
#工作目录
manager_workdir=/var/log/masterha/app1
#二进制文件
master_binlog_dir=/usr/local/mysql/data		##这里需要跟master配置文件内的datadir的路径保持一致；不一致无法保存同步二进制文件
#故障转移切换的工具
master_ip_failover_script=/usr/local/bin/master_ip_failover
#在线切换VIP工具管理
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
#以下是密码账号的管理配置
password=manager		##此处密码为之前创建监控用户的密码
user=mha		###设置监控用户
ping_interval=1		##设置监控主库，发送ping包的事件间隔，默认为3秒，尝试三次没有回应的时候自动进性failove		
remote_workdir=/tmp		##设置远端的MySQL在发生切换时binlog的保存位置
repl_password=123		##设置复制用户的密码；从和主授权的密码
repl_user=myslave		##设置复制用户的账户
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.35.10 -s 192.168.35.20		#设置检查从服务器的脚本
shutdown_script=""
ssh_user=root		##需要进行ssh检测，用户是root；前期做免交互的原因

[server1]
hostname=192.168.35.40
port=3306

[server2]
candidate_master=1	##设置候选msater，如果设置了此参数，发送主从切换后，会将此库提升为主库
hostname=192.168.35.10
check_repl_delay=0		##关闭复制的检查，默认情况下如果一个slave落后master 100M的relay-logs(中继日志)的话，MHA将不会选择该slave作为新的master，设置为0的话会忽略此规则
port=3306

[server3]
hostname=192.168.35.20
port=3306

4.5、测试无密码认证

如果正常会输出successfully

masterha_check_ssh -conf=/etc/masterha/app1.cnf

在这里插入图片描述

4.6、测试主从复制

可以尝试2次

masterha_check_repl -conf=/etc/masterha/app1.cnf

在这里插入图片描述

5、测试

5.1、后台启动MHA

启动时会进行日志记录（在后台开启）
[root@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 &
[2] 19926
[root@manager ~]# jobs
[1]-  运行中               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 &

在这里插入图片描述
参数详解：
解释：
ohup ##选项
masterha_manager ##开启
–conf=/etc/masterha/app1.cnf ##指定配置文件
–remove_dead_master_conf ##当master服务器失效时，发生主从切换后，会把旧的master的ip从主配置文件删
–ignore_last_failover ##忽略故障转移，忽略掉总是宕机不够可靠的服务器
在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failove之所以这样限制是为了避免ping-pong效应。该参数代表忽略桑次MHA出发切换产生的文件，默认情况 MHA发生切换后会在日志记录下，也就是上面设置的日志app1.failover.complete文件，
下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件:为了方便，这里设为为–ianore_last_failover
< /dev/null> ##生成的所有信息会导到nul1下或者/var/log/masterha/app1/manager.log日志文件中
2>&1& ##把2错误性的输山从定向为标准性输出，"&"开启后台运行

5.2、查看到当前的master节点

[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:19852) is running(0:PING_OK), master:192.168.35.40

在这里插入图片描述

5.3、模拟master宕机，查看master的变化

master配置虚拟网卡VIP192.168.35.100
在这里插入图片描述

systemctl  stop mysqld		##msater服务器停止mysql服务
masterha_check_status --conf=/etc/masterha/app1.cnf		##manager服务器查看master节点变为slave1:192.168.35.10

在这里插入图片描述
查询原slave1的状态，已切换成master
在这里插入图片描述
查询slave的状态，master的ip已切换成原slave1
在这里插入图片描述
此时slave1上可以查询到设置的vip，已漂移成功
在这里插入图片描述

查看当前日志信息，可以看到详细过程
tail -f /var/log/masterha/app1/manager.log

在这里插入图片描述
日志内容(即MHA故障转移内容)的大体内容如下：
以本质而言分为两部分
①：bin-log尽可能的save (抢救)并保存在/tmp目录，同时将master 的VIP (192.168.35.100) “飘移”到主-备节点，并起起来
②：新master的bin-log 会与master的bin-log，进行同步检测，尽量趋于一致，同时其他的slave服务器会变更master，指向新master (slave1 192.168.35.10 change master to new master)

5.4、查看主从服务，master变化之后是否可以同步数据

在这里插入图片描述

新的master插入数据
mysql> insert into class values(2);
Query OK, 1 row affected (0.01 sec)

mysql> select * from class;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)
slave2查看插入数据的表，显示已同步
mysql> select * from class;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

6、Master故障修复

  1. 修复db(原master)
    原的master现在变成slave，取消同步的，增加中继日志的内容
vim  /etc/my.cnf
	log_bin=master-bin
	#log_slave=updates=true
	relay-log=relay-log-bin
	relay-log-index=slave-relay-bin.index
systemctl  start mysqld

在这里插入图片描述

  1. 修复主从（在原master数据库中输入）
systemctl start mysqld			##开启服务，进入数据库，修复的master
change master to master_host='192.168.35.10',master_user='myslave',master_password='123',master_log_file='master-bin.000004',master_log_pos=154;
start slave;
set global read_only=1;
flush privileges;

在这里插入图片描述
slave2需要更新二进制日志起点

stop slave;
change master to master_host='192.168.35.10',master_user='myslave',master_password='123',master_log_file='master-bin.000004',master_log_pos=154;
flush privileges;
start slave;
show slave status\G;

在这里插入图片描述

  1. 修改MHA的配置文件（再把这个记录添加进去，因为它检测到失效时候会自动消失
    在这里插入图片描述
    ---->wq保存配置文件
    测试免密和主从
    masterha_check_repl -conf=/etc/master
    在这里插入图片描述
    在这里插入图片描述

三、总结

  • MHA主要是为了解决msater只有一台，若master出现故障时就使用MHA解决单点故障问题

  • 组件:

  • MHA Manager (管理节点)

    • 可以借助于node组件，实现健康检查(ssh、主从复制)、控制故障切换

  • MHA Node 组件(数据节点)：

    • 部署在所有MySQL服务器内；主要作用：
    • 定时汇报给主manager节点，mysql服务的状态
    • 监控本地mysql服务功能

  • 配置步骤
    实验环境：四台服务器，一台master，二台slave，一台MHA(在MHA节点上安装manager组件 )

     ①：首选需要三台服务器配置主从复制
 ②：所有服务器上的数据库提权，针对四个用户(myslave、mha、master、slave1、slave2)
 ③：所有服务器配置ssh免密认证
 ④：在mysql服务器上设置监控用户
 ⑤：修改manager的配置文件master_ip_failover和app1.cnf
 ⑥：在MHA上测试免密和主从服务
 ⑦：后台启动MHA
 ⑧：验证(模拟master宕机，查看master的变化)
可乐卷儿
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
教你恢复SQLSERVER的master系统库的方法
dageliuqing的博客
09-27 2983
接下来，对于第 5 步，必须告知遇到问题的 SQL Server 实例使用这些新文件，而不是失败的文件。SQL Server 的master数据库不能像其他用户或 系统数据库一样恢复， 因为没有活动的master数据库 SQL Server 无法执行。为此，请打开“SQL Server 配置管理器”，选择“SQL Server 服务”，然后选择相应的 SQL Server 实例，右键单击它并选择“启动参数”。master中的数据是相对静态的，因此在大多数情况 下，丢失几个小时的历史记录也没有什么问题。
MySQL数据库MHA高可用
MIsaka的博客
11-12 277
MHA MHA（MsterHigh Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的MySQL高可用环境下故障切换和主从复制软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA的组成 该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器.
mysql+MHA 主从复制 故障切换
mwx17630337353的博客
05-26 866
超详细的奶妈级mysql高可用教程 无脑复制 即可！！！！
Mysql MHA高可用集群及故障切换
m0_73695023的博客
05-15 288
MHA高可用集群真的有用实现免密登录！！
【总结】hbase master重启恢复失败问题修复
|] 大世界，小人物
04-24 900
查阅了一番资料，最终定位到是MasterProcWals pv日志过多，在重启HBase Master 的过程中，HBase Master进入活动状态需要读取并实例化所有正在运行的程序当前记录在/apps/hbase/data/MasterProcWALs/目录下对应的文件。于是想着先重启一把，在hbase master 选主成active状态的过程中，发现重启多次都很漫长，且最终因重启时间过长，被hbase-daemon.sh 强杀掉。但最近再次宕机，一直加大jvm内存也不现实。至此，成功解决该问题。
MySQL之MHA高可用集群及故障切换
ll945608651的博客
05-15 930
MHA（MasterHigh Availability）是一套优秀的mysql高可用环境下故障切换和主从复制的软件。MHA的出现就是为了解决mysql单点故障。Mysql故障切换过程中，MHA能做到0-30秒内自动完成故障性切换操作。MHA能在故障切换的过程中最大程度保证数据的一致性，已达到真正意义上的高可用。MySQL的高可用+故障切换核心部分MHA组件：Manager：主要功能：做MHA的启动、关闭、管理和检测MySQL的各种健康检查。
MySQL之高可用MHA
阿玮的博客
07-06 510
1 MHA介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，该工具仅适用于MySQL Replication 环境，目的在于维持master主库的高可用性。MHA 是自动的 master 故障转移和 slave 提升的软件包，基于标准的MySQL复制（异步/半同步）。 MHA由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。 MHA Manager可以单独部署在一台独立的机器上管理多个master-slave
MySql数据库MHA高可用详细配置文档
09-07
MySQL数据库的高可用性是确保业务连续性和数据安全的关键因素。MHA（Master High Availability）是一种用于MySQL集群的高可用性解决方案，它能够在主数据库发生故障时自动将从库提升为主，以最小化服务中断时间。...
MySQL高可用MHA安装文档与配置文件
01-30
MySQL高可用性解决方案是数据库运维中的重要组成部分，它旨在确保数据服务的连续性和一致性。...本压缩包中的“MySQL高可用MHA安装文档与配置文件”将提供详细的步骤指导，帮助你搭建和管理MHA环境。
数据库+mha+mha+数据库高可用
09-08
数据库高可用性是现代企业IT系统...总之，MHA是提高MySQL数据库高可用性的有力工具，通过合理的配置和维护，可以显著提升系统的稳定性和可靠性。在处理大规模数据服务时，了解并掌握MHA的使用对于IT专业人士至关重要。
mysql mha搭建以及故障切换.
07-07
mysql mha搭建以及故障切换.
MySQL下高可用故障转移方案MHA的超级部署教程
09-10
MySQL高可用故障转移方案MHA（Master High Availability）是一个由日本MySQL专家开发的Perl脚本集，用于确保数据库系统的稳定性。MHA的核心功能是在主从复制环境中监控主服务器（master），并在主服务器出现故障时...
mysql-MHA高可用
10-12
MySQL高可用性解决方案MHA（Master High ...综上所述，MHA是实现MySQL高可用性的重要工具，通过自动化故障切换和智能决策，提高了数据库服务的可靠性。正确配置和维护MHA系统，对于保持业务连续性至关重要。
MySQL 高可用配置及故障切换
2301_76875445的博客
06-27 688
MySQL 高可用配置及故障切换
MYSQL MHA实现故障转移和自动切换
Breeze_nebula的博客
09-05 1093
一旦主服务器故障，MHA会自动选择一个适当的从服务器作为新的主服务器，并更新其他从服务器的配置，使其连接到新的主服务器上。5. 数据一致性难以保证：由于主从复制是通过异步的方式进行数据同步，存在网络延迟、复制延迟等因素，从服务器上的数据与主服务器之间可能存在一定的差异。4. 自动切换复杂性：在传统的主从架构中，当主服务器发生故障或需要维护时，需要手动将一个从服务器提升为新的主服务器。数据一致性维护：MHA确保故障转移后新的主服务器与原主服务器的数据保持一致，通过同步二进制日志等机制实现数据的无缝切换。
【MHA】MySQL高可用MHA介绍4-故障监控与切换具体流程
最新发布
DBA之路的博客
04-25 1613
以下步骤可以通过 masterha_master_switch 命令完成（带 --master_state=alive 参数）。验证复制设置并识别当前主服务器。关闭失败的主服务器（可选）检查上次故障转移状态。
master数据库损坏如何恢复
weixin_34235135的博客
04-04 998
备份与恢复master数据库 注意：必须备份master数据库，如果master数据库以某种方式被损坏。可能无法启动SQl Server实例。这种情况下，必须重建master数据库，然后从备份中还原数据库。 1、完整备份master数据库 2、破坏master 文件 放入光盘 停止服务 更改数据库文件 master.mdf 为master1.mdf ...
SQL Server 2008 系统数据库master 修复 还原
tuzhen007的专栏
08-20 6254
一、系统数据库master中的系统表 被删除，
MySQL高可用架构MHA：快速搭建与故障切换解析
MySQL高可用架构MHA（Master High Availability）是一种被广泛采用的解决方案，旨在确保MySQL数据库在面临故障时仍能保持服务的连续性和数据一致性。MHA由日本DeNA公司的youshimaton（现就职于Facebook）开发，其...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值