基于CentOS7，MySQL5.7的高可用MHA架构搭建实战

置顶 已于 2023-08-04 17:14:19 修改
阅读量2.1k 收藏 21
点赞数 8
分类专栏： 大型分布式存储系统架构 文章标签： 数据库 mysql vim 算法 java
于 2020-09-15 20:44:28 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/chuanchengdabing/article/details/108501699
版权

基于CentOS7，MySQL5.7的高可用MHA架构搭建实战


MHA 架构搭建

一 、MHA架构

MHA（Master High Availability）是一套比较成熟的 MySQL 高可用方案，也是一款优秀的故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA还支持在线快速将Master切换到其他主机，通常只需0.5－2秒。目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器。

在这里插入图片描述
MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

  • MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。负责检测master是否宕机、控制故障转移、检查MySQL复制状况等。

  • MHA Node运行在每台MySQL服务器上，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点，负责保存和复制master的二进制日志、识别差异的中继日志事件并将其差异的事件应用于其他的slave、清除中继日志。

    MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。


MHA故障处理机制：

  • 把宕机master的binlog保存下来
  • 根据binlog位置点找到最新的slave
  • 用最新slave的relay log修复其它slave
  • 将保存下来的binlog在最新的slave上恢复
  • 将最新的slave提升为master
  • 将其它slave重新指向新提升的master，并开启主从复制

MHA优点：

  • 自动故障转移快
  • 主库崩溃不存在数据一致性问题
  • 性能优秀，支持半同步复制和异步复制
  • 一个Manager监控节点可以监控多个集群

二 、MHA架构搭建

2.1 架构介绍

在这里插入图片描述

2.2 准备工作

准备工作1：节点搭建，修改节点主机名称和ip地址

节点ip地址（修改网卡信息）主机名称 （修改 /etc/hostname）
192.168.80.110mhaManager
192.168.80.128master
192.168.80.55slave1
192.168.80.56slave2

准备工作2：

	主从搭建，一主两从（实现半同步或者同步复制都可以）

参考地址：半同步或者同步复制搭建流程

测试：在master上添加一条数据 ，在slave1和slave2上同步此条数据在这里插入图片描述


2.3 架构搭建

MHA搭建步骤1：

	保证MHAManager，Master，Slave1，Slave2四台机器ssh互通

	在四台服务器上分别执行下面命令，生成公钥和私钥，命令执行过程中一直换行回车采用默认值进行生成即可

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


	将四台机器的公钥（公钥所在位置：/root/.ssh/id_rsa.pub）复制到同一个文件中authorized_keys，
	authorized_keys文件中的内容如下：包含了四台节点的公钥信息

在这里插入图片描述

	将此文件authorized_keys在四台机器中进行复制，此文件的复制位置是： /root/.ssh/authorized_keys 


	测试无密登陆：从 从节点  登陆主节点

在这里插入图片描述

搭建步骤2：

	MHA下载安装

	修改yum源，下载wget工具

在这里插入图片描述

MHA版本下载注意

	MySQL5.7对应的MHA版本是0.5.8，所以在GitHub上找到对应的rpm包进行下载，MHA manager和node的安装包需要分别下载：
		https://github.com/yoshinorim
		
	下载后，将Manager和Node的安装包分别上传到对应的服务器。（可使用WinSCP等工具）
名称网盘下载地址在线下载命令
MHA manager链接： 提取码：5555wget https://github.com/yoshinorim/mha4mysql-manager/releases/download/v0.58/mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
node链接： 提取码：5555wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node-0.58-0.el7.centos.noarch.rpm
  • 三台MySQL服务器需要安装node
  • MHA Manager服务器需要安装manager和node

搭建步骤3：MHA node安装（三台MySQL服务器需要安装node）
注意：按照顺序

	注意1：MHA的Node依赖于perl-DBD-MySQL，所以要先安装perl-DBD-MySQL
	注意2：MHA的manager又依赖了perl-Config-Tiny、perl-Log-Dispatch、perl-Parallel-ForkManager
	注意3：由于perl-Log-Dispatch和perl-Parallel-ForkManager这两个被依赖包在yum仓库找不到（国内的yum源找不到），因此安装epel-release-latest-7.noarch.rpm（软件源）

在四台服务器上安装mha4mysql-node

	MHA的Node依赖于perl-DBD-MySQL，所以要先安装perl-DBD-MySQL
	yum install perl-DBD-MySQL -y

在这里插入图片描述

# 安装mha4mysql-node
	rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

在这里插入图片描述

搭建步骤4：MHA manager安装：

# 在MHA Manager服务器已经安装了 mha4mysql-node
# 再继续安装 mha4mysql-manager 
# MHA的manager又依赖了perl-Config-Tiny、perl-Log-Dispatch、perl-Parallel-ForkManager，也分别进行安装 

# 注意：由于perl-Log-Dispatch和perl-Parallel-ForkManager这两个被依赖包在yum仓库找不到（国内的yum源找不到），
	因此安装epel-release-latest-7.noarch.rpm（软件源）
		
	rpm -ivh epel-release-latest-7.noarch.rpm 				# 安装epel软件源

在这里插入图片描述

# MHA的manager又依赖了perl-Config-Tiny、perl-Log-Dispatch、perl-Parallel-ForkManager，也分别进行安装 
	yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager -y

在这里插入图片描述


# 安装mha4mysql-manager
	rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

在这里插入图片描述

提示：由于perl-Log-Dispatch和perl-Parallel-ForkManager这两个被依赖包在yum仓库找不到（国内的yum源找不到），
因此安装epel-release-latest-7.noarch.rpm（软件源）。在使用时，可能会出现下面异常：Cannot
retrieve metalink for repository: epel/x86_64。可以尝试使
用/etc/yum.repos.d/epel.repo，然后注释掉mirrorlist，取消注释baseurl。


搭建步骤5：MHA 配置文件：

	MHA 配置文件

	MHA Manager服务器需要为每个监控的 Master/Slave 集群提供一个专用的配置文件，而所有的
	Master/Slave 集群也可共享全局配置。

初始化配置目录

#目录说明
#/var/log (CentOS目录)
# /mha (MHA监控根目录)
# /app1 (MHA监控实例根目录)
# /manager.log (MHA监控实例日志文件)


配置监控全局配置文件：

	vim /etc/masterha_default.cnf

在这里插入图片描述

参数说明：

# 填写mha的账户   （此账户是在master主节点数据库中创建的账户，可以使用root账户，也可以单独在master上的mysql数据库中创建一个账户）
	user=xxx   	
	注意：此账户一定需要有远程访问权限

# 填写mha的密码
	password=xxx  

# 使用ssh命令的账户
	ssh_user=xxx    

# 主库和从库的mysql账户（master和slave的mysql密码需要保持一致）
	repl_user=xxx   
# 主库和从库的mysql密码（master和slave的mysql密码需要保持一致）
	repl_password=xxx

配置监控实例配置文件：

	mkdir -p /var/log/mha/app1
	touch /var/log/mha/app1/manager.log
	vim /etc/mha/app1.cnf

在这里插入图片描述


搭建步骤6：MHA 配置检测：

	执行ssh通信检测
	在MHA Manager服务器上执行：masterha_check_ssh --conf=/etc/mha/app1.cnf

在这里插入图片描述

搭建步骤7：检测MySQL主从复制：

	在MHA Manager服务器上执行：masterha_check_repl --conf=/etc/mha/app1.cnf
	出现“MySQL Replication Health is OK.”证明MySQL复制集群没有问题。

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

搭建步骤8：MHA Manager启动：

	在MHA Manager服务器上执行：
	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 &

在这里插入图片描述

	查看监控状态命令如下：masterha_check_status --conf=/etc/mha/app1.cnf

在这里插入图片描述


	查看监控日志命令如下：tail -f /var/log/mha/app1/manager.log

在这里插入图片描述

搭建步骤9：测试MHA故障转移（模拟主节点崩溃）

	在MHA Manager服务器执行打开日志命令：tail -200f /var/log/masterha/app1/app1.log
	关闭Master MySQL服务器服务，模拟主节点崩溃：systemctl stop mysqld
	查看MHA日志，可以看到哪台slave切换成了master：show master status;

在这里插入图片描述


看到日志中，出现Master failover to slave completed successful 即标识MHA搭建成功

2.3 将原主启动切换回主（扩展内容）

1. 启动旧的主库：
	systemctl start mysqld

在这里插入图片描述

2. 挂到新主做从库：
change  master to   master_host='192.168.80.55',  master_port=3306,
			master_user='root',  master_password ='root',  master_log_file='xxx',  
				master_log_pos=当前新主节点的日志位置;

start slave; // 开启同步

在这里插入图片描述

3. 编辑配置文件 /etc/mha/app1.cnf
vi   /etc/mha/app1.cnf

#添加节点

在这里插入图片描述

4. 使用MHA在线切换命令将原主切换回来

结束MHA Manager进程：

	masterha_stop --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/mha/app1.cnf

在这里插入图片描述

	执行切换命令：	
		masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=master
			 --new_master_port=3306 --orig_master_is_new_slave
					--running_updates_limit=10000

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

注意：

	master如果使用ip地址，会报错：
		[error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln1218] 192.168.80.128 is not alive!
	需要将ip地址设置成主机名即可

完整的执行脚本如下：

	[root@mhaManager ~]# masterha_master_switch   --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=master --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
	Wed Dec  9 04:15:24 2020 - [info] MHA::MasterRotate version 0.58.
	Wed Dec  9 04:15:24 2020 - [info] Starting online master switch..
	Wed Dec  9 04:15:24 2020 - [info] 
	Wed Dec  9 04:15:24 2020 - [info] * Phase 1: Configuration Check Phase..
	Wed Dec  9 04:15:24 2020 - [info] 
	Wed Dec  9 04:15:24 2020 - [info] Reading default configuration from /etc/masterha_default.cnf..
	Wed Dec  9 04:15:25 2020 - [info] Reading application default configuration from /etc/mha/app1.cnf..
	Wed Dec  9 04:15:25 2020 - [info] Reading server configuration from /etc/mha/app1.cnf..
	Wed Dec  9 04:15:26 2020 - [info] GTID failover mode = 0
	Wed Dec  9 04:15:26 2020 - [info] Current Alive Master: slave1(192.168.80.55:3306)
	Wed Dec  9 04:15:26 2020 - [info] Alive Slaves:
	Wed Dec  9 04:15:26 2020 - [info]   master(192.168.80.128:3306)  Version=5.7.28-log (oldest major version between slaves) log-bin:enabled
	Wed Dec  9 04:15:26 2020 - [info]     Replicating from 192.168.80.55(192.168.80.55:3306)
	Wed Dec  9 04:15:26 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
	Wed Dec  9 04:15:26 2020 - [info]   slave2(192.168.80.56:3306)  Version=5.7.28-log (oldest major version between slaves) log-bin:enabled
	Wed Dec  9 04:15:26 2020 - [info]     Replicating from 192.168.80.55(192.168.80.55:3306)
	Wed Dec  9 04:15:26 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
	
	It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on slave1(192.168.80.55:3306)? (YES/no): yes
	Wed Dec  9 04:15:29 2020 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
	Wed Dec  9 04:15:29 2020 - [info]  ok.
	Wed Dec  9 04:15:29 2020 - [info] Checking MHA is not monitoring or doing failover..
	Wed Dec  9 04:15:29 2020 - [info] Checking replication health on master..
	Wed Dec  9 04:15:29 2020 - [info]  ok.
	Wed Dec  9 04:15:29 2020 - [info] Checking replication health on slave2..
	Wed Dec  9 04:15:29 2020 - [info]  ok.
	Wed Dec  9 04:15:29 2020 - [info] master can be new master.
	Wed Dec  9 04:15:29 2020 - [info] 
	From:
	slave1(192.168.80.55:3306) (current master)
	 +--master(192.168.80.128:3306)
	 +--slave2(192.168.80.56:3306)
	
	To:
	master(192.168.80.128:3306) (new master)
	 +--slave2(192.168.80.56:3306)
	 +--slave1(192.168.80.55:3306)
	
	Starting master switch from slave1(192.168.80.55:3306) to master(192.168.80.128:3306)? (yes/NO): yes
	Wed Dec  9 04:17:17 2020 - [info] Checking whether master(192.168.80.128:3306) is ok for the new master..
	Wed Dec  9 04:17:17 2020 - [info]  ok.
	Wed Dec  9 04:17:17 2020 - [info] slave1(192.168.80.55:3306): SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host.
	Wed Dec  9 04:17:17 2020 - [info] slave1(192.168.80.55:3306): Resetting slave pointing to the dummy host.
	Wed Dec  9 04:17:17 2020 - [info] ** Phase 1: Configuration Check Phase completed.
	Wed Dec  9 04:17:17 2020 - [info] 
	Wed Dec  9 04:17:17 2020 - [info] * Phase 2: Rejecting updates Phase..
	Wed Dec  9 04:17:17 2020 - [info] 
	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
	Wed Dec  9 04:17:19 2020 - [info] Locking all tables on the orig master to reject updates from everybody (including root):
	Wed Dec  9 04:17:19 2020 - [info] Executing FLUSH TABLES WITH READ LOCK..
	Wed Dec  9 04:17:19 2020 - [info]  ok.
	Wed Dec  9 04:17:19 2020 - [info] Orig master binlog:pos is mysql-bin.000009:313.
	Wed Dec  9 04:17:19 2020 - [info]  Waiting to execute all relay logs on master(192.168.80.128:3306)..
	Wed Dec  9 04:17:19 2020 - [info]  master_pos_wait(mysql-bin.000009:313) completed on master(192.168.80.128:3306). Executed 0 events.
	Wed Dec  9 04:17:19 2020 - [info]   done.
	Wed Dec  9 04:17:19 2020 - [info] Getting new master's binlog name and position..
	Wed Dec  9 04:17:19 2020 - [info]  mysql-bin.000002:154
	Wed Dec  9 04:17:19 2020 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='master or 192.168.80.128', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=154, MASTER_USER='root', MASTER_PASSWORD='xxx';
	Wed Dec  9 04:17:19 2020 - [info] 
	Wed Dec  9 04:17:19 2020 - [info] * Switching slaves in parallel..
	Wed Dec  9 04:17:19 2020 - [info] 
	Wed Dec  9 04:17:19 2020 - [info] -- Slave switch on host slave2(192.168.80.56:3306) started, pid: 7789
	Wed Dec  9 04:17:19 2020 - [info] 
	Wed Dec  9 04:17:20 2020 - [info] Log messages from slave2 ...
	Wed Dec  9 04:17:20 2020 - [info] 
	Wed Dec  9 04:17:19 2020 - [info]  Waiting to execute all relay logs on slave2(192.168.80.56:3306)..
	Wed Dec  9 04:17:19 2020 - [info]  master_pos_wait(mysql-bin.000009:313) completed on slave2(192.168.80.56:3306). Executed 0 events.
	Wed Dec  9 04:17:19 2020 - [info]   done.
	Wed Dec  9 04:17:19 2020 - [info]  Resetting slave slave2(192.168.80.56:3306) and starting replication from the new master master(192.168.80.128:3306)..
	Wed Dec  9 04:17:19 2020 - [info]  Executed CHANGE MASTER.
	Wed Dec  9 04:17:19 2020 - [info]  Slave started.
	Wed Dec  9 04:17:20 2020 - [info] End of log messages from slave2 ...
	Wed Dec  9 04:17:20 2020 - [info] 
	Wed Dec  9 04:17:20 2020 - [info] -- Slave switch on host slave2(192.168.80.56:3306) succeeded.
	Wed Dec  9 04:17:20 2020 - [info] Unlocking all tables on the orig master:
	Wed Dec  9 04:17:20 2020 - [info] Executing UNLOCK TABLES..
	Wed Dec  9 04:17:20 2020 - [info]  ok.
	Wed Dec  9 04:17:20 2020 - [info] Starting orig master as a new slave..
	Wed Dec  9 04:17:20 2020 - [info]  Resetting slave slave1(192.168.80.55:3306) and starting replication from the new master master(192.168.80.128:3306)..
	Wed Dec  9 04:17:20 2020 - [info]  Executed CHANGE MASTER.
	Wed Dec  9 04:17:20 2020 - [info]  Slave started.
	Wed Dec  9 04:17:20 2020 - [info] All new slave servers switched successfully.
	Wed Dec  9 04:17:20 2020 - [info] 
	Wed Dec  9 04:17:20 2020 - [info] * Phase 5: New master cleanup phase..
	Wed Dec  9 04:17:20 2020 - [info] 
	Wed Dec  9 04:17:20 2020 - [info]  master: Resetting slave info succeeded.
	Wed Dec  9 04:17:20 2020 - [info] Switching master to master(192.168.80.128:3306) completed successfully.
5. 测试SQL脚本
	查看切换日志文件，即可了解128节点是否再次切换为主节点

在这里插入图片描述

常见错误1：
	MHA安装报错None of slaves can be master. Check failover configuration file or log-bin settings in my.cnf
	修改：在俩个从节点开启log_bin

在这里插入图片描述

在这里插入图片描述

常见错误2：
报错：
	[/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln122] Got error when getting node version. Error:
	[/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln123]bash: apply_diff_relay_logs: 未找到命令

原因：
	node节点没有安装，在master和slave上执行

解决：在master和slave节点上都需要安装node
	wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node-0.58-0.el7.centos.noarch.rpm
	rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm --force --nodeps
常见错误3：
报错：
	[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln359] Slave configurations is not valid.
	[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations.  at /usr/bin/masterha_check_repl line 48.
	[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
	[info] Got exit code 1 (Not master dead).

原因：
	主库和从库的my.cnf中配置的binlog-ignore-db和binlog-do-db要保持一致

2.4 主备切换

主备切换是指将备库变为主库，主库变为备库，有可靠性优先和可用性优先两种策略。

  • 主备延迟问题

      主备延迟是由主从数据同步延迟导致的，与数据同步有关的时间点主要包括以下三个：
  	* 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
  	* 之后将binlog传给备库 B，我们把备库 B 接收完 binlog 的时刻记为 T2;
  	* 备库 B 执行完成这个binlog复制，我们把这个时刻记为 T3。

    所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。

    在备库上执行show slave status命令，它可以返回结果信息，seconds_behind_master表示当前备库延迟了多少秒。

      同步延迟主要原因如下：
  	* 备库机器性能问题
  		机器性能差，甚至一台机器充当多个主库的备库。
  	* 分工问题
  		备库提供了读操作，或者执行一些后台分析处理的操作，消耗大量的CPU资源。
  	* 大事务操作
  		大事务耗费的时间比较长，导致主备复制时间长。比如一些大量数据的delete或大表DDL操作都可能会引发大事务。

  • 可靠性优先
    主备切换过程一般由专门的HA高可用组件完成，但是切换过程中会存在短时间不可用，因为在切换过程中某一时刻主库A和从库B都处于只读状态。如下图所示：
    在这里插入图片描述

      主库由A切换到B，切换的具体流程如下：
  	* 判断从库B的Seconds_Behind_Master值，当小于某个值才继续下一步
  	* 把主库A改为只读状态（readonly=true）
  	* 等待从库B的Seconds_Behind_Master值降为 0
  	* 把从库B改为可读写状态（readonly=false）
  	* 把业务请求切换至从库B

  • 可用性优先
    不等主从同步完成， 直接把业务请求切换至从库B ，并且让 从库B可读写 ，这样几乎不存在不可用时间，但可能会数据不一致。
    在这里插入图片描述

      如上图所示，在A切换到B过程中，执行两个INSERT操作，过程如下：
  	* 	 主库A执行完 INSERT c=4 ，得到 (4,4) ，然后开始执行 主从切换
  	*	 主从之间有5S的同步延迟，从库B会先执行 INSERT c=5 ，得到 (4,5)
  	* 	 从库B执行主库A传过来的binlog日志 INSERT c=4 ，得到 (5,4)
  	*	 主库A执行从库B传过来的binlog日志 INSERT c=5 ，得到 (5,5)
  	*	 此时主库A和从库B会有 两行 不一致的数据

通过上面介绍了解到，主备切换采用可用性优先策略，由于可能会导致数据不一致，所以大多数情况下，优先选择可靠性优先策略。在满足数据可靠性的前提下，MySQL的可用性依赖于同步延时的大小，同步延时越小，可用性就越高。

下节内容：ShardingSphere实战

穿城大饼
关注
  • 8
    点赞
  • 踩
  • 21
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
专栏目录
mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
08-06
MHA自动化主服务器故障转移,快速将从服务器晋级为主服务器(通常在10-30s),而不影响复制的一致性,不需要花钱买更多的新服务器,不会有性能损耗,容易安装,不必更改现有的部署环境,适用于任何存储引擎。
故障分析 | MHA 切换的一个“坑”
ActionTech的博客
08-19 496
作者：张洛丹 原爱可生 DBA 团队成员，现陆金所 DBA 团队成员，对技术执著有追求！ 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 背景 在一次变更中使用 MHA 进行主从切换，命令如下： masterha_master_switch --master_state=alive --conf=/etc/mha/mha3306.cnf --new_master_host=xx.xx.xx.xx --new_master_port=3306 --in.
我配置的Mha检查时出现的情况分析及解决如下
火麒马
06-13 5066
​
mha故障
辅导自学转行
12-05 1312
root@localhost ~]# masterha_check_repl --conf=/etc/app1.cnf Sun Apr 22 20:29:30 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Sun Apr 22 20:29:30 2018 - [info] Reading application default configuration from /et
解决[error][/usr/share/perl5/vendor_perl/MHA/ServerManage
m0_62554990的博客
08-29 736
【代码】解决[error][/usr/share/perl5/vendor_perl/MHA/ServerManage。
Mha报错Checking slave status failed on
Q先生
09-07 792
报错信息如下: error][/usr/share/perl5/vendor_perl/MHA/Server.pm, ln265] Checking slave status failed on 192.168.31.18(192.168.31.18:3306). err=Got error when executing SHOW SLAVE STATUS. Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT pri
mysql mha keepalived_MHA+keepalived 高可用MYSQL集群(续)
weixin_31458459的博客
01-19 693
一、恢复背景二、修复故障节点及MHA集群三、提升已修复的节点为master四、注意事项一、恢复背景1、设备清单2、：percona-xtrabackup-2.3.2(注：生产环境应定时备份；不应等到数据库DOWN后才备份，以免加剧集群的压力)备份数据库操作：[root@jev72 ~]#innobackupex --user=root --password=centos /data/。 。 。xt...
MHA-结合MySQL半同步复制高可用集群(Centos7)
weixin_30920513的博客
05-20 199
目录 一.理论概述 本案例部署思路 二.环境 三.部署 部署MHA 部署二进制包MySQL及部署主从复制 部署半同步复制 配置MHA MHA测试 部署lvs+keepalived(lv...
linux 之centos7搭建mysql5.7.29的详细过程
09-08
主要介绍了linux 之centos7搭建mysql5.7.29的详细过程,本文通过图文并茂的形式给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下
Centos7mysql5.7安装.docx
07-05
Centos7mysql5.7安装.docx
centos7安装mysql5.7
01-10
在本地虚拟机的场合，需要更换yum安装网络地址配置文件CentOS-Base.repo 从阿里云服务器下载一份CentOS-Base.repo文件存到本地
mysql 5.7 CentOS 7 离线安装包
09-24
mysql 5.7 CentOS 7 离线安装包
Centos7.x下MySQL5.7.30安装以及双主环境搭建指南
09-18
1. Centos7下MySQL5.7.30 安装步骤 2. MySQL 双主环境搭建步骤 3. md语法编写，建议使用 typora 打开
实战：采⽤Sharding-JDBC实现订单表的（两主四从） 分库分表 和 读写分离
chuanchengdabing的博客
09-23 2607
采用Sharding-JDBC实现c_order表分库分表+读写分离 1. 基于user_id对c_order表进行数据分片 2. 分别对master1和master2搭建 一主二从 架构 3. 基于master1和master2 主从集群 实现 读写分离 4. order建表SQL如下
阿里云OSS云存储平台
chuanchengdabing的博客
09-30 1606
阿里云OSS云存储平台 一、需求分析 使用SpringBoot和OSS实现图片的上传、下载和删除功能， 具体要求如下 可以使用postman 发送上传请求 /oss/upload ，实现图片上传到OSS对应的Bucket中 类型检查：必须为 jpg、png 或者 jpeg类型，其它图片类型返回错误提示信息 大小检查：必须小于5M，大于5M时返回错误提示信息 图片名称：生成的文件名，必须保持唯一 可以使用postman 发送下载请求 /oss/download，实现图片下载 可以根据图片名进行
实战：轻量级分布式文件系统FastDFS（GraphicsMagick图片压缩）
chuanchengdabing的博客
09-28 982
轻量级分布式文件系统FastDFS——实现用户头像上传/压缩屏幕适配 一、需求分析 1.1 业务场景： 用户上传的头像图片大小不一、手机和PC等设备显示尺寸也存在差异，因此需要能根据http请求指定的尺寸参数对图片进行动态压缩，以达到屏幕适配的作用。 1.2 功能需求： 搭建FastDFS图片服务器，通过http请求访问服务器中图片时，显示动态缩略图。 具体要求如下： 1.在Linux系统中安装FastDFS服务器 2.可以使用FastDFS自带的工具将文件上传到FastDFS 3.通过http访问某个
基于CentOS7，MySQL5.7的主从复制架构搭建实战
chuanchengdabing的博客
09-08 806
基于CentOS7，MySQL5.7的主从+读写架构搭建实战 一、环境说明 1. 软件版本 环境&软件 版本 虚拟机&VMware Workstation 15 Pro 服务器&CentOS CentOS-7-x86_64-DVD-1810.iso 数据库&Mysql 5.7.28 远程文件传输&WinSCP、Xftp 5 远程连接&Xshell 5 2. 架构介绍 机器名称 角色 权限 IP Master
MySQL如何避免全表扫描？
最新发布
常备不懈
04-21 1049
全表扫描通常在查询数据库时消耗大量资源，尤其是当表中的数据行数非常多时。避免全表扫描可以显著提高数据库查询的性能和效率。以下是一些有效的策略来避免全表扫描：
基于centos封装mysql5.7的docker镜像
03-30
1. 安装docker 在CentOS中安装docker，可以使用以下命令： ``` sudo yum install -y docker ``` 2. 下载mysql5.7 可以从mysql官网上下载mysql5.7的安装包，下载完成后将其解压到任意目录，例如 /opt/mysql。 3. 创建Dockerfile文件 在任意目录下创建 Dockerfile 文件，并编辑以下内容： ``` FROM centos:latest MAINTAINER Your Name <[email protected]> # 安装mysql依赖包 RUN yum -y install libaio # 复制mysql安装包到容器中 ADD /opt/mysql /opt/mysql # 配置mysql环境变量 ENV MYSQL_HOME /opt/mysql ENV PATH $MYSQL_HOME/bin:$PATH # 创建mysql用户 RUN groupadd mysql RUN useradd -g mysql mysql # 修改mysql安装包权限 RUN chown -R mysql:mysql $MYSQL_HOME RUN chmod -R 755 $MYSQL_HOME # 初始化mysql RUN $MYSQL_HOME/scripts/mysql_install_db --user=mysql # 设置启动脚本 ADD /opt/mysql/support-files/mysql.server /etc/init.d/mysqld RUN chmod +x /etc/init.d/mysqld # 设置容器启动时自动启动mysql RUN chkconfig mysqld on # 设置mysql默认编码为utf8 RUN echo "character-set-server=utf8" >> /etc/my.cnf # 暴露mysql默认端口 EXPOSE 3306 # 启动命令 CMD service mysqld start && tail -f /dev/null ``` 4. 构建docker镜像 在Dockerfile文件所在目录下，执行以下命令： ``` sudo docker build -t mysql5.7 . ``` 其中，mysql5.7是镜像名称，可以根据需要自行修改。 5. 运行docker容器 在运行docker容器之前，需要先创建一个数据卷，用于持久化mysql数据。可以执行以下命令创建数据卷： ``` sudo docker volume create mysql_data ``` 创建数据卷后，可以执行以下命令运行docker容器： ``` sudo docker run -d --name mysql -p 3306:3306 -v mysql_data:/var/lib/mysql mysql5.7 ``` 其中，mysql是容器名称，可以根据需要自行修改。-p参数用于映射容器内部的3306端口到主机的3306端口，-v参数用于挂载数据卷。 至此，基于centos封装mysql5.7的docker镜像就已经完成了。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

穿城大饼

你的鼓励将是我最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值