MHA

MHA高可用集群 文章目录 一、MHA 简介： 二、部署 MHA： 第一步：三台主从服务器安装 mysql 第二步：修改 mysql 的主配置文件：/etc/my.cnf ，注意三台服务器的 server-id 不能一样 第三步：三台服务器启动 mysql 服务 第四步：配置 Mysql 主从同步（一主两从） 第五步：安装 MHA 第六步：启动 MHA 一、MHA 简介： MHA（Master High Availability） （1）简介 目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 （2）该软件由两部分组成： MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时

MHA算是业内比较成熟的MySQL高可用解决方案，在MySQL故障切换过程中，MHA能做到自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。软件主要有MHA Manager（管理节点）和MHA Node（数据节点）两部分组成，在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。 目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器。 下面我们就开始着手配置我们的MHA高可用，因为本人只有两台虚拟机，所以就只能按照两台来搞了，中间也踩了点坑，下面看一下我们的基本环境： MySQL1（master）：172.16.16.34:3306 +MHA Manager

关于 MHA： 1.Master HA，对主节点进行监控，可实现自动故障转 移至其它从节点；通过提升某一从 节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多 从的架构，要搭建MHA,要求一个复制集群中必须最少有 三台数据库服务器，一主二从， 即一台充当master，一台充当备用master，另外一台充当从库，如果财大气粗，也 可以用一台专门的服务器来当MHA监控管理服务器 2.MHA工作原理 1 从宕机崩溃的master保存二进制日志事件（binlog events） 2 识别含有最新更新的slave 3 应用差异的中继日志（relay log）到其他的slave 4 应用从master保存的二进制日志事件（binlog events） 5 提升一个slave为新的master 6 使其他的slave连接新的master进行复制 注意：MHA需要基于ssh，key验证登入方法 MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。 1.Manager工具包主要包括以下几个工具： masterha_check_ssh 检查MHA的SSH配置状况 masterha_check_repl 检查MySQL复制状况 masterha_manger 启动MHA masterha_check_status 检测当前MHA运行状态

一、MHA介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中（通过将从库提升为主库），大概0.5-2秒内即可完成。 自动故障检测和自动故障转移 MHA能够在一个已经存在的复制环境中监控MySQL，当检测到Master故障后能够实现自动故障转移，通过鉴定出最“新”的Salve的relay log，并将其应用到所有的Slave，这样MHA就能够保证各个slave之间的数据一致性，即使有些slave在主库崩溃时还没有收到最新的relay log事件。一个slave节点能否成为候选的主节点可通过在配置文件中配置它的优先级。由于master能够保证各个slave之间的数据一致性，所以所有的slave节点都有希望成为主节点。在通常的replication环境中由于复制中断而极容易产生的数据一致性问题，在MHA中将不会发生。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一个系统可能包含很多模块，如数据库、前端、缓存、搜索、消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用的实现可能更加复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，在容灾之外，还要同时考虑方案中数据一致性问题。 本文将通过介绍一些业界主流的数据库高可用架构、每种方案的特性和优缺点，以及数据库高可用架构的自动化运维实现，讲讲数据库高可用容灾方案设计与实现，希望抛砖引玉，和大家一起讨论。 一、高可用数据库概述 什么是高可用数据库？ 高可用数据库是由一系列数据库构成的总体系统，在任何时刻，至少有一个节点可以接受用户的请求并提供数据库服务。大多数数据库架构中，有一个主节点处理主要请求，还有若干备用节点用于容灾切换，当主节点不能提供服务时，备用节点成为主节点继续提供服务，用以保证整个系统的可用和稳定。 高可用数据库有很多优点： 第一，方便读写分离。数据库请求当中，一般读操作的请求次数远大于写操作，高可用数据库可以通过将写操作放在主数据库节点上进行，将读操作分担到若干从库上，来提升读操作吞吐量，进而提升读写效率； 第二，变更不停服。当整个高可用数据库架构或者主节点升级时，可以让高可用数据库先进行主库切换，让备用节点替换原主节点提供数据库服务

mysql-day08 部署 MYSQL 高可用集群 u 集群架构 MHA 工作过程 • MHA Manager 会定时探测集群中的 master 节点 , 当 master 出现故障时 , 它可以自动将最新数据的 sl ave 提升为新的 master , 然后将所有其他的 slave 重新指向新的 master 。整个故障转移过程对应用程 序完全透明。 – ( 1 ) 从宕机崩溃的 master 保存二进制日志事件 ( binlog events) – ( 2 ) 识别含有最新更新的 slave – ( 3 ) 应用差异的中继日志 ( relay log ) 到其他的 slave – ( 4 ) 应用从 master 保存的二进制日志事件 ( binlog events ) – ( 5 ) 提升一个 slave 为新的 master ; – ( 6 ) 使其他的 slave 连接新的 master 进行复制 ; u 准备环境 一、集群定义：使用多台服务提供相同的服务 二、高可用集群定义：主备模式，被客户端访问的称作主，当主宕机时，备用 服务器自动接收客户端访问。 拓扑结构 client | | --> vip 192.168.4.100 《 51 ， 52 ， 53 》 _____________________________________________________

实现 MHA VIP 功能 配置 master_ip_failover 脚本(db3) 把 master_ip_failover 上传到 /iba/software 上 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.31.88/24'; my $key = '1'; my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip"; my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down"; GetOptions( 'command=s' => \$command, 'ssh_user=s' => \$ssh_user, 'orig_master_host=s' => \$orig_master_host, 'orig_master_ip=s

最近整理了目前的MySQL高可用方案。 MySQL 高可用方案包括3大类： 共享存储 同步复制 基于复制的冗余 下面分别看下每种方案。 1.共享存储 共享存储实现了数据库服务器和存储设备的解耦。 比较典型的是SAN共享存储和DRBD磁盘复制。 1.1 SAN SAN(Storage Area Network)存储如图所示。 SAN共享存储中，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。 1.2 DRBD DRBD(Distributed Replicated Block Device)是Linux内核模块实现的块级别的同步复制技术，可以与SAN达到相同的共享存储效果。 2.同步复制 同步复制的基本原理是，要求数据在集群中所有节点或大多数节点上提交。 同步复制的数据库高可用方案，主要包括3种： MySQL Cluster Galera Cluster MGR 2.1 MySQL Cluster MySQL Cluster 或NDB Cluster 是MySQL 官方集群部署方案，基于NDB(Network DataBase) 存储引擎的完整的分布式数据库系统。 MySQL cluster主要由3部分组成： SQL 层的 SQL 服务器节点 Storage 层的 NDB 数据节点 负责管理各个节点的 Manage 节点 2.2 Galera

MHA 官方网址 Manager : https://github.com/yoshinorim/mha4mysql-manager Node : https://github.com/yoshinorim/mha4mysql-node MHA 工作原理 主库宕机处理过程 1. 监控节点 (通过配置文件获取所有节点信息) 系统,网络,SSH连接性 主从状态,重点是主库 2. 选主 (1) 如果判断从库(position或者GTID),数据有差异,最接近于 Master 的 slave,成为备选主 (2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主. (3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主. 1. 默认情况下如果一个 slave 落后 master 100M的 relay logs 的话，即使有权重,也会失效. 2. 如果 check_repl_delay=0 的话,即使落后很多日志,也强制选择其为备选主 3. 数据补偿 (1) 当SSH能连接,从库对比主库 GTID 或者 position 号,立即将二进制日志保存至各个从节点并且应用( save_binary_logs ) (2) 当SSH不能连接, 对比从库之间的relaylog的差异( apply_diff_relay_logs ) 4.

目录 一、恢复MHA 二、MHA切换 三、配置VIP漂移 一、恢复MHA #1.修复旧主库 [root@db01 ~]# /etc/init.d/mysqld start #2.在mha日志中找到change master语句 #GTID模式下： [root@db04 ~]# grep -i 'change master to' /etc/mha/manager.log Tue Nov 19 20:49:31 2019 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='slave', MASTER_PASSWORD='123'; #普通模式下： [root@db03 ~]# grep -i 'change master to' /etc/mha/manager.log Tue Nov 19 19:22:22 2019 - [info] All other slaves should start replication from here. Statement should be