快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

使用MHA实现MySQL主从复制高可用

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

目录

首先,MHA简介

第二,实验性架构设计

1.基本环境

2.建筑设计

三,MHA安装和配置

1.配置主从复制

2.安装相关模块,例如Perl

3.配置不使用密码身份验证的SSH登录

4.安装MHA节点

5.安装MHA Manager

6.配置MHA

7.创建相关脚本

第四,检查MHA配置

1.检查SSH配置

2.检查整个复制环境的状态

3.检查MHA管理器的状态

4.查看启动日志

五,功能测试

1.初始绑定VIP

2.测试自动切换

3.测试手动切换

4.测试在线切换

5.修复损坏的Master \\ n

参考:


\ 就MySQL高可用性而言,MHA(主高可用性)当前是一个相对成熟的解决方案。它由日本DeNA的youshimaton(现为Facebook雇用)开发。在MySQL高可用性环境中作为故障转移和主从升级的高可用性软件非常出色。在MySQL故障转移过程中,MHA可以在030秒内自动完成数据库故障转移操作,而在故障转移过程中,MHA可以最大程度地确保数据的一致性,以实现真正的高可用性。

\ 该软件包括两部分:MHA管理器(管理节点)和MHA节点(数据节点)。 MHA Manager可以部署在独立的计算机上以管理多个主从集群,也可以部署在从属节点上。 MHA节点在每台MySQL服务器上运行,MHA Manager会定期检测群集中的主节点,当主节点发生故障时,它可以自动将最新的数据从节点升级到新的主节点,然后将所有其他从节点重定向到新的主节点。整个故障转移过程对应用程序是完全透明的。

\ 在MHA自动故障转移期间,MHA尝试从已关闭的主服务器中保存二进制日志,以确保不会最大程度地丢失数据,但这并不总是可行的。例如,如果主服务器硬件发生故障或无法通过ssh访问,则MHA无法保存二进制日志,而只能进行故障转移并丢失最新数据。使用MySQL 5.5的半同步复制可以大大降低数据丢失的风险。MHA可以与半同步复制结合使用。如果只有一个从属服务器收到了最新的二进制日志,则MHA可以将最新的二进制日志应用于所有其他从属数据库服务器,从而确保所有节点的数据一致性。

\ 目前,MHA主要支持主从架构。要构建MHA,复制群集中必须至少有三台数据库服务器,一个主服务器和两个从服务器,即一个充当主服务器,一个充当备用主服务器,另一个充当从属服务器。由于至少需要三台服务器,因此淘宝网也在机器成本考虑的基础上对其进行了改造。目前,淘宝TMHA已支持一台主机和一台从机。 (摘自:” MySQL简介(第二版)”)从代码的角度来看,MHA是一组Perl脚本,因此不难改变MHA以利用Ali系统的技术实力来支持一个主机和一个从机。

图1显示了MHA架构:

图1

\ MHA的工作原理总结如下:

  1. 从崩溃的主服务器保存二进制日志事件(binlog事件);
  2. 标识具有最新更新的从站;
  3. 将差异的中继日志应用于其他从站;
  4. 应用从主数据库保存的二进制日志事件(binlog事件);
  5. 提升奴隶为新主人;
  6. 使用其他从属服务器连接到新的主服务器进行复制。

官方介绍:https://code.google.com/archive/p/mysql-master-ha/

  • 操作系统版本:CentOS Linux版本7.2.1511(核心)
  • MySQL版本:5.6.14
  • VIP(虚拟IP):172.16.1.100
  • 主机信息:请参阅表1

字符

IP

主机名

网卡

server_id

功能

监控主机

172.16.1.124

hdp1

监视复制组

母版

172.16.1.127

hdp4

ens160

127

响应写请求

候选大师

172.16.1.126

hdp3

ens32

126

读取请求的响应

奴隶

172.16.1.125

hdp2

ens32

125

读取请求的响应

表1

\ 实验架构如图2所示。

图2

\ hdp1充当MHA管理器,其他三台主机组成一个MySQL一主机和二从机复制群集作为MHA节点。

\ MySQL主从复制配置相对简单,具体过程可参考MySQL官方文档,此处省略。如果是新构建的副本,则只需打开Master的binlog,然后将Slave master更改为指定的文件和pos,然后启动slave。如果要为正在使用的现有数据库构建从属库,则有两种方法。一种是使用mysqldump master-data参数记录主服务器的文件和pos,但它可能是卡库;一种更好的方法是使用innobackupex在线构建从属库。过程如下:

(1)前提条件

  • 主服务器和从属服务器已安装相关的软件包:
 

  • ?主服务器和从属服务器安装percona-xtrabackup
  • 设置PATH环境变量,例如:
 

(2)配置从主服务器到从服务器的SSH无密码连接

mysql用户主要执行:

(3)备份和传输

例如,在主用户上以mysql用户执行:

(4)恢复备份

mysql用户在从服务器上执行:

(5)后续工作

备份my.cnf,bat文件,crontab等。

\ 使用root用户在所有四个节点上执行以下操作。

\ 以root用户身份在hdp1 172.16.1.124(监视器)上执行:

\ 在hdp4 172.16.1.127(Master)上以root用户身份执行:

\ 以root用户身份在hdp3 172.16.1.126(slave1)上执行:

\ 以root用户身份在hdp2 172.16.1.125(slave2)上执行:

\ 下载地址:https://github.com/yoshinorim/mha4mysql-manager/wiki/下载

使用root用户对hdp2,hdp3和hdp4执行以下操作。

\ 安装完成后,/usr/bin/目录中将包含以下与MHA相关的文件:

\ 这些脚本工具通常是由MHA Manager脚本触发的,无需人工干预。脚本描述:

  • apply_diff_relay_logs:标识差异中继日志事件并将差异事件应用于其他从站。
  • filter_mysqlbinlog:删除不必要的ROLLBACK事件(MHA不再使用此工具)。
  • purge_relay_logs:清除中继日志(不会阻塞SQL线程)。
  • save_binary_logs:保存并复制主数据库的二进制日志。

\ 下载地址:https://github.com/yoshinorim/mha4mysql-manager/wiki/下载

在hdp1上使用root用户执行以下操作。

\ 安装完成后,/usr/bin/目录中将包含以下与MHA相关的文件:

\ 在hdp1上使用root用户执行以下操作(1),(2)和(3)。

(1)创建一个配置文件目录

(2)创建一个具有以下内容的配置文件/etc/masterha/app1.cnf:

\ 服务器默认部分是管理器的一些基本配置参数。 server1,server2和server3分别对应于复制中的主服务器,第一从服务器和第二从服务器。该文件的语法很严格,并且变量值后不应有多余的空格。主要配置项目如下所述。

  • manager_log:设置管理器日志文件。
  • manager_workdir:设置经理的工作目录。
  • master_binlog_dir:设置主服务器保存二进制日志的位置,以便MHA可以找到主服务器的日志,即mysql数据目录。
  • master_ip_failover_script:设置自动故障转移的切换脚本。
  • master_ip_online_change_script:在手动切换期间设置切换脚本。
  • password:在mysql中设置root用户的密码。
  • ping_interval:设置监视主库和发送ping数据包的时间间隔。默认值为3秒。三次尝试后如果没有任何响应,滑行将自动执行。
  • remote_workdir:设置切换发生时的远程mysql binlog存储位置。
  • repl_password:设置复制用户的密码。
  • repl_user:在复制环境中设置复制用户名
  • secondary_check_script:一旦MHA和hdp4监视之间出现问题,MHA Manager将尝试从hdp3登录到hdp4。
  • shutdown_script:设置脚本以在发生故障后关闭故障主机。该脚本的主要功能是关闭主机,然后将其放入裂开的大脑中,此处不使用。
  • ssh_user:设置ssh的登录用户名。
  • 用户:将监视用户设置为root。
  • 候选主:设置为候选主。设置此参数后,发生主从切换后,即使主库不是集群中最新的从属,从属库也将升级为主库。
  • check_repl_delay:默认情况下,如果从属服务器落后于主服务器100M的中继日志,则MHA不会选择该从属服务器作为新的主服务器,因为通过设置check_repl_delay = 0来恢复该从属服务器需要很长时间。选择新的主服务器时,切换将忽略复制延迟。该参数对于候选主站= 1的主机非常有用,因为该候选主站在切换期间必须是新的主站。

(3)建立软连接

(4)设置复制期间从站的relay_log_purge参数

在带有MySQL用户执行的hdp3和hdp2上:

\ 请注意,在MHA切换过程中,从库中进行恢复的过程取决于中继日志的相关信息。清除中继日志的方法。默认情况下,执行SQL线程后,将从属服务器上的中继日志将被自动删除。但是,在MHA环境中,还原其他从属服务器时可以使用这些中继日志。因此,您需要禁用中继日志的自动删除。定期清除中继日志需要考虑复制延迟问题。在ext3文件系统下,删除大文件需要一定的时间,这可能会导致严重的复制延迟。为了避免复制延迟,有必要临时为中继日志创建硬链接,因为在Linux系统中通过硬链接删除大文件的速度非常快。 (在mysql数据库中,删除大表时,通常也使用建立硬链接的方法)

(1)创建一个定期清理的中继脚本

在hdp3和hdp2的两个slave上创建/root/purge_relay_log.sh文件,内容如下:

\ purge_relay_logs参数说明:

  • 用户mysql:MySQL用户名。
  • 密码mysql:MySQL用户密码。
  • 端口:MySQL端口号。
  • workdir:指定在其中创建中继日志的硬链接的位置。默认值为/var/tmp。由于在系统的不同分区中创建硬链接文件将失败,因此需要执行硬链接的特定位置。成功执行脚本后,将删除硬链接中继日志文件。
  • disable_relay_log_purge:默认情况下,如果relay_log_purge = 1,则脚本将不清除任何内容并自动退出。通过设置此参数,当relay_log_purge = 1时,relay_log_purge将设置为0。清除继电器日志后,最后将参数设置为OFF。

\ 将模式更改为可执行文件:

\ 手动执行/root/purge_relay_log.sh,在控制台中输出:

\ 添加到crontab:

(2)创建一个自动故障转移脚本

在hdp1上创建具有以下内容的/usr/bin/master_ip_failover文件:

\ 请注意脚本的VIP漂移部分。

(3)创建手动故障转移脚本

在hdp1上创建/usr/bin/master_ip_online_change文件,其内容如下:

\ 请注意脚本的VIP漂移部分。

\ 在hdp1上使用root用户。

\ 您可以看到每个节点的ssh验证都可以。

\ 在hdp1上使用root用户。

\ 没有明显的错误,只有一些警告,并且复印显示正常。

\ 在hdp1上使用root用户。

\ 显示” NOT_RUNNING”,这意味着MHA监视未打开。执行以下命令以在后台启动MHA。

\ 启动参数说明:

  • remove_dead_master_conf:此参数表示在发生主从切换时,将从配置文件中删除旧的主ip。
  • manger_log:日志存储位置。
  • ignore_last_failover:默认情况下,如果MHA检测到连续中断,并且两次中断之间的间隔少于8小时,则不会进行故障转移。这种限制的原因是为了避免乒乓效应。此参数表示忽略最后一个MHA触发的开关生成的文件。默认情况下,MHA会在切换后在日志目录中生成app1.failover.complete文件,即上面的/数据。如果找到下一次再次切换,除非在第一次切换后删除该文件,否则该文件在目录中的存在将无法触发切换。为了方便起见,请将其设置为–ignore_last_failover。

\ 再次检查MHA Manager的状态:

\ 您可以看到它已经受到监视,并且主控主机为172.16.1.127。

\ 在hdp1上使用root用户。

\ 以root用户身份在hdp4 172.16.1.127(master)上执行:

\ 查看VIP:

(1)停止slave1库(172.16.1.126)上的从IO线程,以模拟主从延迟:

(2)在主库(172.16.1.127)中安装sysbench,生成sysbench数据,并在sbtest库下生成sbtest表,该记录总共有10W记录。

(3)使用root用户停止主服务器的mysql服务。

(4)验证VIP漂移。

以hdp3上的root用户身份。

\ 在hdp4上使用root用户。

\ 您可以看到VIP已从hdp4 172.16.1.127(master)移到hdp3 172.16.1.126(slave1)。

(5)客户端使用VIP访问数据库

\ 在创建sbtest库之前,172.16.1.126停止了从属sql线程。在新的Master 172.16.1.126上查看数据,您可以看到反向数据也已同步,并且数据没有丢失。

(6)查看复制的主从开关

\ 如您所见,172.16.1.126被称为新主服务器,而172.16.1.125也指向该新主服务器。

(7)检查MHA Manager的状态

在hdp1上使用root用户执行以下操作。

\ 发现执行自动故障转移后,MHA Manager进程停止了。官方网站对此情况的解释如下:

\ 意味着安装一个流程工具并通过该工具与脚本结合来管理流程。

\ 首先,还原环境。

\ 恢复数据库复制:

\ 恢复VIP绑定:

\ 恢复配置文件:

在hdp1上编辑/etc/masterha/app1.cnf,然后将[server1]部分添加回去。

\ 启动MHA管理:

\ 此时,环境已还原,您可以开始测试手动切换。当主服务器出现故障时,请手动调用MHA来执行故障转移操作,步骤如下。

(1)停止MHA管理

以hdp1上的root用户身份。

(2)关闭母版

在hdp4上使用root用户。

(3)进行手动切换

以hdp1上的root用户身份。

(4)验证VIP是否漂移到172.16.1.126

(5)验证复制关系

(6)验证客户端VIP访问权限

\ 在许多情况下,有必要将现有的主服务器迁移到另一台服务器。例如,主服务器的硬件故障,RAID控制器卡需要重建,并将主服务器移至性能更好的服务器。维护主服务器会导致性能下降,从而导致停机期间至少没有数据写入。另外,阻止或终止当前正在运行的会话可能会导致主服务器与主服务器之间的数据不一致。 MHA提供快速切换和优雅的阻止写入功能。此切换过程仅需0.5-2s,在此期间无法写入数据。在许多情况下,接受0.5-2s的阻塞写入是可以接受的。因此,切换主服务器不需要计划分配维护时间窗口。

\ MHA在线切换的大致过程:

  1. 检测复制设置并确定当前的主服务器
  2. 标识新的主服务器
  3. 阻止写入当前的主服务器
  4. 等待所有从属服务器赶上复制
  5. 授予写入新主服务器的权限
  6. 重置从属服务器。

请注意,在联机切换时,应用程序体系结构需要考虑以下两个问题:

  1. 自动识别主机和从机的问题(主机可能会切换),如果使用vip方法,则可以基本解决此问题。
  2. 负载平衡问题(您可以定义近似读写比率,每台计算机可以承受的负载比率,并且当计算机离开群集时需要考虑此问题)

为了确保完全的数据一致性并在最快的时间内完成切换,MHA在线切换必须满足以下条件才能成功进行切换,否则切换将失败。

  • 所有从IO线程都在运行
  • 所有从属SQL线程都在运行
  • 所有显示从属状态输出中的

  • Seconds_Behind_Master参数小于或等于running_updates_limit秒。如果在切换期间未指定running_updates_limit,则默认情况下running_updates_limit为1秒。
  • 在主端,通过show processlist输出,没有更新花费的时间超过running_updates_limit秒。

\ 在测试之前,请首先根据上述”测试手动切换”测试之前的步骤执行还原环境(手动切换不需要修改/etc/masterha/app1.cnf配置文件),然后按照以下步骤操作测试线路切换:

(1)停止MHA管理

以hdp1上的root用户身份。

(2)执行在线切换命令

以hdp1上的root用户身份。

(3)验证复制关系

查看hdp2,hdp3,hdp4中的从站状态:

\ 您可以看到hdp3 172.16.1.126成为新的主服务器,而hdp2 172.16.1.125和hdp4 172.16.1.127成为指向新主服务器的从设备。

(4)验证VIP自动漂移

(5)验证客户端是否通过VIP访问数据库

\ 在正常情况下,自动切换后,原始母版可能已被放弃。修复原始主控主机后,如果数据已完成,则可能需要将原始主控机用作新的主控机。奴隶。这时,我们可以在自动切换时使用MHA日志来完成原始主机的修复。以下是提取相关日志的命令:

\ 您可以看到类似于以下内容的信息:

\ 表示如果主控主机已修复,则可以在主机上执行CHANGE MASTER操作。将Master修复为新的从属库。

  • 构建MySQL高可用性MHA

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638