MySQL MHA 典型使用场景

1      管理节点部署位置

1.1.       Dedicated Manager server and multiple MySQL (master,slaves) servers

使用专用的管理服务器管理多组MySQL主从服务器

Since MHA Manager uses very little CPU/Memory resources, you can manage lots of (master, slaves) pairs from single MHA Manager. It is even possible to manage 100+ pairs from single manager server.

 

1.2.       Running MHA Manager on one of MySQL slaves

在一个从库上部署管理节点

If you have only one (master, slaves) pair, you may not like allocating dedicated hardware for MHA Manager because it adds relatively high costs. In such cases, running MHA Manager on one of slaves makes sense. Note that current version of MHA Manager connects to MySQL slave server via SSH even though the MySQL server is located on the same host as MHA Manager, so you need to enable SSH public key authentication from the same host.

2      不同主从配置下的主从切换场景

2.1         Single master, multiple slaves(单主多从)

        M(RW)                            M(RW), promoted from S1
         |                                             |
  +------+------+        --(master crash)-->     +-----+-----+
 S1(R) S2(R)   S3(R)                           S2(R)        S3(R)

This is the most common replication settings. MHA works very well here.

 

2.2         Single master, multiple slaves (one on remote datacenter) 单主多从,一个从位于远程数据中心

        M(RW)                                M(RW), promoted from S1
         |                                                 |
  +------+---------+         --(master crash)-->     +-----+------+
 S1(R) S2(R)     Sr(R,no_master=1)                   S2(R)         Sr(R,no_master=1)

In many cases you want to deploy at least one slave server on a remote datacenter. When the master crashes, you may not want to promote the remote slave to the new master, but let one of other slaves running on the local datacenter become the new master. MHA supports such requirements. Setting no_master=1 in the configuration file makes the slave never becomes new master.

 

2.3         Single master, multiple slaves, one candidate master(单主多从,一个候选主)

      M(RW)-----S0(R,candidate_master=1)   M(RW), promoted from S0
       |                                          |
  +----+----+          --(master crash)-->   +----+----+
 S1(R)     S2(R)                             S1(R)      S2(R)

In some cases you may want to promote a specific server to the new master if the current master crashes. In such cases, setting candidate_master=1 in the configuration file will help.

 

2.4         Multiple masters, multiple slaves(多主多从)

      M(RW)<--->M2(R,candidate_master=1)   M(RW), promoted from M2
       |                                          |
  +----+----+          --(master crash)-->   +----+----+
 S(R)     S2(R)                             S1(R)      S2(R)

In some cases you may want to use multi-master configurations, and you may want to make the read-only master the new master if the current master crashes. MHA Manager supports multi-master configurations as long as all non-primary masters (M2 in this figure) are read-only.

 

2.5         Three tier replication(三层复制架构)

        M(RW)                                   M(RW), promoted from S1
         |                                                 |
  +------+---------+         --(master crash)-->     +-----+------+
 S1(R) S2(R)     Sr(R)                              S2(R)       Sr(R)
                   |                                              |
                   +                                              +
                  Sr2                                            Sr2

In some cases you may want to use three-tier replication like this. MHA can still be used for master failover. In the configuration file, manage the master and all second-tier slaves (in this figure, add M,S1,S2 and Sr in the MHA config file, but do not add Sr2). If the current master (M) fails, MHA automatically promotes one of the second-tier slaves(S1,S2,Sr, and you can also set priorities) to the new master, and recover the rest second-tier slaves. The third tier slave(Sr2) is not managed by MHA, but as long as Sr (Sr2's master) is alive, Sr2 can continue replication without changing anything.

If Sr crashes, Sr2 can't continue replication because Sr2's master is Sr. MHA can NOT be used to recover Sr2. This is where support for global transaction id is desired. Hopefully this is less serious than master crash.

 

2.6         Three tier replication, multi-master(三层复制架构,多主)

   M1(host1,RW) <-----------------> M2(host2,read-only)
        |                                |
  +-----+--------+                       +
 S1(host3,R)    S2(host4,R)             S3(host5,R)

=> After failover

 

          M2(host2,RW)

                 |

  +--------------+--------------------------+

 S1(host3,R)    S2(host4,R)             S3(host5,R)

 

This structure is also supported. In this case, host5 is a third-tier slave, so MHA does not manage host5(MHA does not execute CHANGE MASTER on host5 when the primary master host1 fails). When current master host1 is down, host2 will be new master, so host5 can keep replication from host2 without doing anything. Here are configuration file example.

[server default]
multi_tier_slave=1

[server1]
hostname=host1
candidate_master=1

[server2]
hostname=host2
candidate_master=1

[server3]
hostname=host3

[server4]
hostname=host4

[server5]
hostname=host5

 

时间: 2024-10-29 16:48:08

MySQL MHA 典型使用场景的相关文章

阿里云的典型应用场景有哪些

阿里云典型应用场景 云服务器 ECS 应用非常广泛,既可以单独使用作为简单的 Web 服务器,也可以与其他阿里云产品(如 OSS.CDN 等)搭配提供强大的多媒体解决方案.以下是云服务器ECS的典型应用场景. 企业官网.简单的 Web 应用 网站初始阶段访问量小,只需要一台低配置的云服务器 ECS 即可运行应用程序.数据库.存储文件等.随着网站发展,您可以随时提高 ECS 的配置和增加数量,无需担心低配服务器在业务突增时带来的资源不足问题. 多媒体.大流量的 APP 或网站 云服务器 ECS 与

阿里云播放器SDK的正确打开方式 | 版本差异与三大典型应用场景(二)

阿里云播放器SDK(ApsaraVideo for Player SDK)是阿里视频云端到云到端服务的重要一环,除了支持点播和直播的基础播放功能外,还深度融合视频云业务,支持视频的加密播放.安全下载.首屏秒开.低延时等业务场景,为用户提供简单.快速.安全.稳定的视频播放服务.本文衔接上文,从版本.功能和典型应用场景等几个方面来介绍阿里云播放器SDK. 不同版本的播放器SDK 阿里云播放器SDK提供基础播放器.高级播放器和UI播放器三层框架满足不同用户.不同业务场景需求,开发者可根据自己的业务需求

细说社交化经销商服务的十大典型应用场景

这期云服务百言堂将用友优普运营经理沙猛介绍社交化的经销商服务.沙猛介绍道,用友从为企业提供财务软件的1.0时代.管理软件的2.0时代,到现在提供社会化商业服务平台的3.0时代,每一个时代的背景都是来源自企业用户的实际需求. 据了解,社会化商业背景下,传统企业需要整合包括营销.经销商.供应商资源,以及实体资源.制造资源等在内的企业资源,并通过整合这些资源更好地服务消费者. 其中,经销商服务的社交化是企业数字化转型中一个重要方向,利用互联网技术将企业成千上万的经销商进行聚合,建立经销商生态,将服务触

Redis开发运维实践开发者设计规范之典型使用场景参考

4.6 典型使用场景参考 下面是Redis适用的一些场景: 1. 取最新 N 个数据的操作 比如典型的取你网站的最新文章,通过下面方式,我们可以将最新的 5000条评论的ID放在Redis的List集合中,并将超出集合部分从数据库获取. 使用LPUSH latest.comments命令,向 list集合中插入数据 插入完成后再用 LTRIM latest.comments 0 5000 命令使其永远只保存最近5000个 ID 然后我们在客户端获取某一页评论时可以用下面的逻辑 FUNCTION

【Spring】Redis的两个典型应用场景--good

  原创 BOOT Redis简介 Redis是目前业界使用最广泛的内存数据存储.相比memcached,Redis支持更丰富的数据结构,例如hashes, lists, sets等,同时支持数据持久化.除此之外,Redis还提供一些类数据库的特性,比如事务,HA,主从库.可以说Redis兼具了缓存系统和数据库的一些特性,因此有着丰富的应用场景.本文介绍Redis在Spring Boot中两个典型的应用场景. 场景1:数据缓存 第一个应用场景是数据缓存,最典型的当属缓存数据库查询结果.对于高频读

【实战】Docker的典型应用场景

本文讲的是[实战]Docker的典型应用场景,[编者的话]Docker技术已日趋成熟,但很多新接触Docker的朋友可能对「Docker到底能用来干什么」这一问题比较纠结.本文总结了一些作者在应用打包.多版本混合部署.升级回滚.多租户资源隔离以及内部开发环境方面使用Docker的一些经验,希望能抛砖引玉,给Docker的观望者一些启发. 相对于VM,Docker在其轻量.配置复杂度以及资源利用率方面有着明显的优势. 随着Docker技术的不断成熟,越来越多的企业开始考虑通过Docker来改进自己

zookeeper典型应用场景一览

ZooKeeper典型应用场景一览 数据发布与订阅(配置中心) 发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新.例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用. 应用中用到的一些配置信息放到ZK上进行集中管理.这类场景通常是这样:应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher,这样一来,以后每次配置有更新的时候,都会实时通知到订阅的客户端,从来达到获取最新配置信息的

ZooKeeper 典型应用场景一览

ZooKeeper 典型应用场景一览 数据发布与订阅(配置中心) 发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新.例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用. 1. 应用中用到的一些配置信息放到ZK上进行集中管理.这类场景通常是这样:应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher,这样一来,以后每次配置有更新的时候,都会实时通知到订阅的客户端,从来达到获取最新配

基于Docker的mysql mha 的集群环境构建实践

12月2日,云计算高级工程师王佩老师,在[DBA+社群]中间件用户组进行了一次主题为"基于Docker的mysql mha 的集群环境构建实践"的线上分享.小编特别整理出其中精华内容,供大家学习交流.同时,也非常感谢王佩老师对DBA+社群给予的大力支持.    嘉宾简介   云计算高级工程师 目前主要研究docker 相关的云计算技术   演讲实录  关于docker 想必前面的各位大牛分享的演讲讲的非常多了,今天主要跟大家分享基于docker快速构建 mysql mha 的一个实战案