mysql（三）路由器、MHA高可用

最后更新：2022-07-16 07:22

1 mysql路由器

介绍: MySQL路由器是InnoDB集群的一部分,是轻量级中间件，可提供应用程序与后端MySQL服务器之间的透明路由。它可用于各种用例，例如,它通过有效引导数据库流量到适当的后端MySQL服务器来提供高可用性和可扩展性。mysql路由器不支持库表。

这个实验使用MySQL路由器通过绑定不同的端口实现不同的读写分离策略。下面的图示了mysql路由器在群复制群和应用程序之间。组复制多主模式，每个节点都可以读写,不需要作读写分离。在生产环境中将需要数据库读写分离。

因为此实验前是多主模式组复制架构，不区分master、slave，集群三个节点都读写。实际中可以选择主从模式，master节点作为读写端，slave节点作为只读端。

添加虚拟机server4为 mysql 路由器来作读写分离。 mysql 路由器直接定义策略就可以了。

在服务器4上安装路由器 mysql-router,并直接在 mysql路由器上定义读写分离策略。

在其他MySQL服务器上授权用户,因为服务器1、2、3是多个主机模式组的重复,其他节点将自动执行相同的操作。

1 客户 7001 访问 38 :

在服务器1上检查3306端口(mysqld端口),发现与服务器4和服务器1相连,服务器4等于代理,外部客户端通过阅读和写分层连接到服务器4和服务器1,连接服务器1 servermysqld的3306端口。

这是在其他服务器上看到,3306端口没有与服务器的连接信息,这意味着客户端没有通过路由器连接到这个服务器。

由于访问7001设置的是server1、2、3轮询，客户端重新访问7001，会通过server4路由器依次路由到server2、server3服务器上

2 客户端接入 7002 个端口 :

由于设置的是一直访问第一个服务器。除非此服务器挂掉，然后按照顺序访问下一个服务器，以此类推。访问顺序为server3、2、1。所以server3上查到了

外部客户端通过读写分离连接到服务器4和服务器3服务器,连接到服务器3 servermysqld的3306端口。

在停止3台服务器的mysqld服务后,再次访问,连接到2台服务器。

2 MHA高可用

MHA自动解决数据同步,

一、MHA介绍
MHA(Master High Availability)目前是一个相对成熟的 MySQL 高可用性解决方案。它是由日本公司DeNA Yoshimaton(现由Facebook公司雇佣)开发的,是一个使用Perl语言编写脚本管理工具的日语MySQL专家,此工具只适用于MySQL复制(二级)环境,目的是维持主图书馆的高可用性.这是一个高可用性软件集,用于在MySQL高可用性环境下调错和高级升级。在MySQL故障切换过程中,MHA能够在0~30秒内自动完成数据库故障开关操作,在进行故障切换的过程中,民政事务厅可以确保数据的最大一致性,实现真正的高可用性感。

MHA是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。
1.MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，它也可以部署在奴隶节点上。MHA Manager会定时探测集群中的node节点,当发现master出现故障的时候,它可以自动将具有最新数据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程对应用程序是透明的。
2.MHA节点在每个MySQL服务器上运行,通过监测具有分析和清理日志功能的脚部来加速故障的传输。

在MHA自动故障切换过程中,MHA试图存储延迟的主服务器的二进制日志,最大保障数据丢失,但这并非总是可能的。例如，如果主服务器硬件故障或无法通过ssh访问,MHA不能存储二进制日志,仅通过故障转移而丢失最新的数据.使用MySQL5的半同步版本,这可以大大降低数据丢失的风险。MHA可以与半同步复制相结合。如果只有一个奴隶收到了最新的二进制日志,MHA可以将最新的二进制日志应用到所有其他奴隶服务器上,因此,可以保证所有节点的数据一致性。

目前,海事处主要支持一个主要的多方向架构,为了建立一个MHA,一个复制组必须至少有三个数据库服务器,一主二从，就是,一个大师,一个作为备份大师,另外一台充当从库，因为您至少需要三个服务器,考虑到机器的成本,淘宝也在该基础上进行了改造，目前 Taobao TMHA 支持一个主语.

港大工作架构说明
文中说明了如何通过海事处经理管理多组 Master copying,并总结了海事处的工作原则:

与其他HA软件相比,MHA的目的在于维持MySQL Replication中Master库的高可用性，它的最大特点是它可以解决多个奴隶之间的差分记录,最后,要保持所有奴隶数据一致,然后从他们中间选出一位新主人,把其他奴隶指向它。工作流程主要如下：
1.从宕机崩溃的master保存二进制日志事件（binlog events）;
2.标识包含最新更新的奴隶;
3.应用差异的中继日志（relay log）到其他的slave；
4.应用从master保存的二进制日志事件（binlog events）；
5.提升一个slave为新的master；
(六)使其他奴隶与新主人相连,以复制;

当主人失败时,通过将I/O线程与奴隶之间进行比较,以读取主线程位置,选取最接近的slave做为latest slave。其他奴隶通过与最后的奴隶进行比较,生成差分记录。在latest slave上应用从master保存的binlog，同时将latest slave提升为master。最后,将相应的差异应用到其他奴隶身上,开始从新主人身上复制。

在民政事务厅实施总故障切换的过程中,MHA节点试图访问故障的主人(通过SSH),如果访问可用(不是硬件故障,(例如InnoDB数据文件损坏等)会保存二进制文件，确保数据不会尽可能地丢失。同时使用MHA和半同步复制大大降低了数据丢失的风险。

########## MHA如何保持数据的一致性呢？#########主要通过MHA node的以下几个工具实现，但是这些工具由mha manager触发：
save_binary_logs 如果master的二进制日志可以存取的话，保存复制master的二进制日志，最大程度保证数据不丢失
apply_diff_relay_logs 相对于最新的slave，生成差异的中继日志并将所有差异事件应用到其他所有的slave

注意：
对比的是relay log，relay log越新就越接近于master，才能保证数据是最新的。
purge_relay_logs 删除继发日志而不阻塞SQL线程

################# MHA的优势 ##################
1. 故障切换快
在主从复制集群中，只要从库中复制没有延迟,MHA通常可以在几秒内执行故障开关。在9~10秒内检查控制失败,你可以选择在7-10秒内关闭主机以避免大脑破裂,几秒钟内，将差异中继日志（relay log）应用到新的master上，总延迟通常为10-30秒。恢复新主人后,MHA继续恢复剩余的奴隶。甚至在数以万计的奴隶中,这不会影响主人的康复时间。

DeNA在超过150个MySQL（主要5.0/5.1版本）主从环境下使用了MHA。当mater故障后，MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中，4秒内完成故障切换是不可能的。

2.主机故障不会造成数据不一致
当当前的主人失败时,MHA自动识别slave之间中继日志（relay log）的不同，并适用于所有奴隶。这样所有药剂都能够同步,只要所有的奴隶都活着。和Semi-Synchronous Replication一起使用，(几乎)保证没有数据丢失。

3.不需要修改当前MySQL设置
MHA设计的一个重要原则是尽可能简单易用。MHA在传统的MySQL 5.0版本中运行,之后的版本主要是从环境中复制。与其他高可用性解决方案相比,MHA不需要更改MySQL部署环境。MHA适用于非同步和半同步主源复制。

启动/停止/升级/减少/安装/卸载MHA不需要更改(装载的启动/停止)MySQL拷贝。当您需要升级MHA到一个新的版本时,您不需要停止MySQL,只需用MHA的一个新的版本替换它,然后重新启动MHA经理。

MHA在MySQL5中运行,原始版本始于0。一些其他MySQL高可用性解决方案需要特定的版本(如MySQL集群、MySQL具有全球事务ID等),但是,应用程序的迁移不仅仅是因为主机的可用性。在大多数情况下，以前的MySQL应用程序已经部署,不要只是想获得大师的高可用性,迁移到不同的存储引擎或更新前端版本花费太多时间。MHA的工作包括5.0/5.1/5。 MySQL 5的原始版本,所以并不需要迁移。

4.不需要添加很多服务器
海事处由海事处经理和海事处节点组成。MHA节点运行在需要破坏/恢复的MySQL服务器上,不需要添加额外的服务器。MHA管理器运行在一个特定的服务器上,所以你需要添加一个(达到较高的可用性需要两个),但是MHA Manager可以监控大量（甚至上百台）单独的master，因此，不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上，实施海事部不需要增加服务的数量。

5. 无性能下降
MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。可以得到像原生MySQL复制一样快的性能。

6.适用于任何存储机
MHA可以运行在存储引擎上,它可以运行到MySQL复制的时间内,并且并不局限于InnoDB,尽管它也可以在传统的MyISAM引擎环境中使用,这些环境很难迁移。

实验环境配置:只使用一个集群:一个主两个链,服务器1是主机,服务器2和3是奴隶,所有设置为GTID模式。服务器4是管理端,在主机(服务器1)暂停后实现,主机自动切换到其他节点.

在前面的实验中,使用了多域群复制架构,并首次转换为单域双向架构和GTID模式。

在所有节点上关闭mysqld服务,在/data/mysql中清理数据,并修改/data/my.cnf文件重启配置:

配置文件/etc/my在服务器2.cnf上和服务器1只是不同的,在逆2:server_id=2上

在服务器3上:上配置文件/etc/my.cnf和服务器2只是不同的,在逆3上:server_id=3,然后是与服务器2相同的操作。

由于我们已经在主机上创建了一个repl用户,这个操作被写入一个二进制日志文件,并且用户在其他奴隶端同步创建。

一个主机和两个从GTID配置完成.

软件安装和管理端口服务器4的配置

在server4管理端安装mha的软件，从本机38上lftp到mha.zip，解压。安装管理端mha的时候有很多依赖性，依赖包全部放在了mha.zip中，直接全部安装即可。

管理节点 server4 decrypt连接所有服务器节点,并且在服务器节点之间进行解密:

免密成功。

在服务器的末端安装规格,并将rpm包安装到服务器上

在服务器的三个端安装 TY:

管理服务器4配置更改

编辑配置文件：

额外参数: check_repl_delay=0

[server]

hostname=172.25.254.2

candidate_master=1 #指定failover时此slave会接管master，即使数据不是最新的。check_repl_delay=0#默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为奴隶需要很长时间才能康复,通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置candidate_master=1主机非常有用,因为候选人必须在转换过程中成为一名新的大师

检查环境配置是否成功需要两个步骤:

1.检查机密 masterha_check_ssh --conf=/etc/mha/app1.conf

2.确定数据库主机配置是否成功

错误原因:管理端服务器4无法远程访问集群服务器节点数据库。

解决方案:在服务器1上,root用户拥有远程访问权限。由于一个主机在上面的两个到GTID模式中配置,则仅授予主机的权限,其他节点则自动同步:

在此测试中, 上述两项测试均成功,且规格环境配置均成功.

2.1手动切换：

服务器1是主机,server2、3为slave

在实验.failover.complete之前,删除锁定的 rm -fr app1文件,或禁止频繁转换主:

或者添加参数--ignore_last_failover 忽略锁定文件,每次更改主机时执行它,因为每次更改主机时 /etc/mha 将再次生成锁定文件

2.1.当主节点仍活着时:

在服务器4上:

全部选择yes，

服务器1已被转换为奴隶;

现在服务器2是主人,服务器1是奴隶,服务器3是奴隶

2.1.当主人挂断时,手动切换

server4上

--ignore_last_failover 忽略锁定的文件，因为系统为了防止频繁切换master做的，忽略的话强制切换master

在这个视角服务器1状态被切换为主机。由于服务器2已关闭,当服务器2重新启动时,配置未更改(或主配置),所以您必须手动移动主机到服务器2上的服务器1。

完成后服务器1是主机,server2、3为slave；

2.2自动切换

在自动切换之前,移除锁定的 rm -fr app1文件。 failover.complete,或禁止频繁转换主:

自动切换需要把程序推到后面.

测试：

禁用主服务器1'smysqld:

在管理服务器4:没有自动检测和/etc/mha视图logmanager.log发现错误

日志：
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Monitoring server 172.25.254.38 is NOT reachable!