首页 / MYSQL / 详解MySQL高可用MMM搭建方案及架构原理

详解MySQL高可用MMM搭建方案及架构原理

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了详解MySQL高可用MMM搭建方案及架构原理，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含11843字，纯文字阅读大概需要17分钟。

内容图文

先来看看架构，如下图：

详解MySQL高可用MMM搭建方案及架构原理 - 文章图片

部署

1.修改hosts

在所有的服务器中执行相同的操作。

vim /etc/hosts

192.168.137.10 master
192.168.137.20 backup
192.168.137.30 slave
192.168.137.40 monitor

2.添加mysql用户

只需要在所有的数据库端执行即可，监控端不需要。

GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.137.%' IDENTIFIED BY 'mmm_monitor'; 
GRANT SUPER,REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'192.168.137.%' IDENTIFIED BY 'mmm_agent';
flush privileges;

详解MySQL高可用MMM搭建方案及架构原理 - 文章图片

注意：repl用户在搭建主从服务的时候已经创建好了。

3.安装监控软件

注意：监控端全部安装，但是监控端只需要用到mysql-mmm-monitor，mysql-mmm-agent不需要启动。

数据库端只需要安装mysql-mmm-agent

1.在监控服务器执行

wget http://mirrors.ustc.edu.cn/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm –ivh epel-release-6-8.noarch.rpm
yum –y install mysql-mmm*

2.在数据库服务器上执行，每个数据库服务器上都要执行

wget http://mirrors.ustc.edu.cn/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm –ivh epel-release-6-8.noarch.rpm
yum -y install mysql-mmm-agent

路径说明：

详解MySQL高可用MMM搭建方案及架构原理 - 文章图片

4.配置文件

db服务器配置文件：mmm_agent.conf，mmm_common.conf

监控服务器的配置文件：mmm_mon.conf，mmm_common.conf（该文件所有服务器一样）

配置db服务器

1.修改master服务器

vim /etc/mysql-mmm/mmm_common.conf

active_master_role  writer  ###积极的master角色的标示，所有的db服务器都需要开启read_only参数，对于writer服务器监控代理会自动将read_only属性关闭。

<host default>
 cluster_interface  eth0  #####群集的网络接口
 pid_path    /var/run/mysql-mmm/mmm_agentd.pid ####pid路径
 bin_path    /usr/libexec/mysql-mmm/    #####可执行文件路径 
 replication_user  repl   #######复制用户
 replication_password repl   #######复制用户密码
 agent_user    mmm_agent  #######代理用户，用于更改只读操作
 agent_password   mmm_agent  #######代理用户密码
</host>

<host master>   ##########master1的host名
 ip  192.168.137.10 #####master1的ip
 mode master  ########角色属性，master代表是主
 peer backup  ########与master1对等的服务器的host名，也就是master2的服务器host名
</host>

<host backup>  ####和master的概念一样
 ip  192.168.137.20
 mode master
 peer master
</host>

<host slave>  #####从库的host名,如果存在多个从库可以重复一样的配置
 ip  192.168.137.30 ####从的ip
 mode slave #####slave的角色属性代表当前host是从
</host>

<role writer> ####writer角色配置
 hosts master,backup ####能进行写操作的服务器的host名，如果不想切换写操作这里可以只配置master,这样也可以避免因为网络延时而进行write的切换，但是一旦master出现故障那么当前的MMM就没有writer了只有对外的read操作。
 ips  192.168.137.100 #####对外提供的写操作的虚拟IP
 mode exclusive #####exclusive代表只允许存在一个主，也就是只能提供一个写的IP
</role>

<role reader> #####read角色配置
 hosts backup,slave ######对外提供读操作的服务器的host名,当然这里也可以把master加进来
 ips  192.168.137.120,192.168.137.130,192.168.137.140 ###对外提供读操作的虚拟ip，这两个ip和host不是一一对应的,并且ips也hosts的数目也可以不相同，如果这样配置的话其中一个hosts会分配两个ip
 mode balanced ###balanced代表负载均衡
</role>

同时将这个文件拷贝到其它的服务器包括监控服务器，配置不变

scp /etc/mysql-mmm/mmm_common.conf slave:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf backup:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf monitor:/etc/mysql-mmm/

2.代理文件配置

vim /etc/mysql-mmm/mmm_agent.conf

详解MySQL高可用MMM搭建方案及架构原理 - 文章图片

注意：这个配置只配置db服务器，监控服务器不需要配置，this后面的host名改成当前服务器的host命令，master2和slave也改成对应的服务器的host名。

3.启动代理进程

chkconfig mysql-mmm-agent on

service mysql-mmm-agent start

每台db服务器上都需要启动

配置监控服务器

vim /etc/mysql-mmm/mmm_mon.conf

include mmm_common.conf
<monitor>
 ip     127.0.0.1
 pid_path   /var/run/mysql-mmm/mmm_mond.pid
 bin_path   /usr/libexec/mysql-mmm
 status_path   /var/lib/mysql-mmm/mmm_mond.status #####群集的状态文件，也就是执行mmm_control show操作的显示来源。
 ping_ips   192.168.137.10,192.168.137.20,192.168.137.30 ######被监控的db服务器的ip地址
 auto_set_online  0 ####设置自动online的时间，默认是超过60s就将它设置为online，默认是60s，这里将其设为0就是立即online

 # The kill_host_bin does not exist by default, though the monitor will
 # throw a warning about it missing. See the section 5.10 "Kill Host
 # Functionality" in the PDF documentation.
 #
 # kill_host_bin  /usr/libexec/mysql-mmm/monitor/kill_host
 #
</monitor>

<host default>
 monitor_user  mmm_monitor ####监控db服务器的用户
 monitor_password mmm_monitor ####监控db服务器的密码
</host>

debug 0  #######debug 0正常模式，1为debug模式

注意：配置文件中的注释是为了便于理解，在部署的时候最好把注释去掉以免因为注释造成的潜在影响。

启动监控进程

chkconfig mysql-mmm- monitor on
service mysql-mmm-monitor start

注意：无论是在db端还是在监控端如果有对配置文件进行修改操作都需要重启代理进程和监控进程。

操作分析

日志文件

日志文件往往是分析错误的关键，所以要善于利用日志文件进行问题分析。

db端：/var/log/mysql-mmm/mmm_agentd.log

监控端：/var/log/mysql-mmm/mmm_mond.log

命令文件

mmm_agentd ：db代理进程的启动文件

mmm_mond ：监控进程的启动文件

mmm_backup ：备份文件

mmm_restore ：还原文件

mmm_clone

mmm_control：监控操作命令文件

db服务器端只有mmm_agentd程序，其它的都是在monitor服务器端。

mmm_control用法

mmm_control程序可以用于监控群集状态、切换writer、设置online\offline操作等。

Valid commands are:
 help        - show this message ###帮助信息
 ping        - ping monitor ###ping当前的群集是否正常
 show        - show status ####群集在线状态检查
 checks [<host>|all [<check>|all]] - show checks status #####执行监控检查操作
 set_online <host>     - set host <host> online ####将host设置为online
 set_offline <host>    - set host <host> offline ###将host设置为offline
 mode        - print current mode. ####打印

输出当前的mode set_active - switch into active mode. set_manual - switch into manual mode. set_passive - switch into passive mode. move_role [--force] <role> <host> - move exclusive role <role> to host <host> ####移除writer服务器为指定的host服务器 (Only use --force if you know what you are doing!) set_ip <ip> <host> - set role with ip <ip> to host <host>

1.检查所有的db服务器群集状态

[root@monitor mysql-mmm]# mmm_control checks all
master ping   [last change: 2016/06/07 16:31:24] OK
master mysql  [last change: 2016/06/07 16:31:24] OK
master rep_threads [last change: 2016/06/07 16:31:24] OK
master rep_backlog [last change: 2016/06/07 16:31:24] OK: Backlog is null
slave ping   [last change: 2016/06/07 16:31:24] OK
slave mysql  [last change: 2016/06/07 16:31:24] OK
slave rep_threads [last change: 2016/06/07 16:31:24] OK
slave rep_backlog [last change: 2016/06/07 16:31:24] OK: Backlog is null
backup ping   [last change: 2016/06/07 16:31:24] OK
backup mysql  [last change: 2016/06/07 16:31:24] OK
backup rep_threads [last change: 2016/06/07 16:31:24] OK
backup rep_backlog [last change: 2016/06/07 16:31:24] OK: Backlog is null

检查项包括：ping、mysql是否正常运行、复制线程是否正常等

2.检查群集环境在线状况

[root@monitor mysql-mmm]# mmm_control show
 backup(192.168.137.20) master/ONLINE. Roles: reader(192.168.137.120)
 master(192.168.137.10) master/ONLINE. Roles: writer(192.168.137.100)
 slave(192.168.137.30) slave/ONLINE. Roles: reader(192.168.137.130)

3.对指定的host执行offline操作

[root@monitor mysql-mmm]# mmm_control set_offline backup
OK: State of 'backup' changed to ADMIN_OFFLINE. Now you can wait some time and check all roles!
[root@monitor mysql-mmm]# mmm_control show
 backup(192.168.137.20) master/ADMIN_OFFLINE. Roles: 
 master(192.168.137.10) master/ONLINE. Roles: writer(192.168.137.100)
 slave(192.168.137.30) slave/ONLINE. Roles: reader(192.168.137.120), reader(192.168.137.130)

4.对指定的host执行onine操作

[root@monitor mysql-mmm]# mmm_control set_online backup
OK: State of 'backup' changed to ONLINE. Now you can wait some time and check its new roles!
[root@monitor mysql-mmm]# mmm_control show
 backup(192.168.137.20) master/REPLICATION_FAIL. Roles: 
 master(192.168.137.10) master/ONLINE. Roles: writer(192.168.137.100)
 slave(192.168.137.30) slave/ONLINE. Roles: reader(192.168.137.120), reader(192.168.137.130)

[root@monitor mysql-mmm]# mmm_control show
 backup(192.168.137.20) master/ONLINE. Roles: reader(192.168.137.120)
 master(192.168.137.10) master/ONLINE. Roles: writer(192.168.137.100)
 slave(192.168.137.30) slave/ONLINE. Roles: reader(192.168.137.130)

5.执行write切换

1.查看当前的slave对应的master

[root@slave ~]# mysql -uroot -proot -e 'show slave status \G;'
Warning: Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
    Slave_IO_State: Waiting for master to send event
     Master_Host: 192.168.137.10
     Master_User: repl
     Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000073
   Read_Master_Log_Pos: 1461
    Relay_Log_File: mysql-relay-bin.000006
    Relay_Log_Pos: 283
  Relay_Master_Log_File: mysql-bin.000073
    Slave_IO_Running: Yes
   Slave_SQL_Running: Yes

2.writer切换，要确保mmm_common.conf文件中的writer属性有配置对应的host,否则无法切换

[root@monitor mysql-mmm]# mmm_control move_role writer backup
OK: Role 'writer' has been moved from 'master' to 'backup'. Now you can wait some time and check new roles info!
[root@monitor mysql-mmm]# mmm_control show
 backup(192.168.137.20) master/ONLINE. Roles: reader(192.168.137.120), writer(192.168.137.100)
 master(192.168.137.10) master/ONLINE. Roles: 
 slave(192.168.137.30) slave/ONLINE. Roles: reader(192.168.137.130)

3.save从库自动切换到了新的master

[root@slave ~]# mysql -uroot -proot -e 'show slave status \G;'
Warning: Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
    Slave_IO_State: Waiting for master to send event
     Master_Host: 192.168.137.20
     Master_User: repl
     Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000039
   Read_Master_Log_Pos: 120
    Relay_Log_File: mysql-relay-bin.000002
    Relay_Log_Pos: 283
  Relay_Master_Log_File: mysql-bin.000039
    Slave_IO_Running: Yes
   Slave_SQL_Running: Yes

其它处理问题

如果不想让writer从master切换到backup（包括主从的延时也会导致写VIP的切换），那么可以在配置/etc/mysql-mmm/mmm_common.conf时，去掉<role write>中的backup

<role writer> ####writer角色配置
 hosts master ###这里只配置一个Hosts
 ips  192.168.137.100 #####对外提供的写操作的虚拟IP
 mode exclusive #####exclusive代表只允许存在一个主，也就是只能提供一个写的IP
</role>

这样的话当master出现故障了writer写操作不会切换到backup服务器，并且slave也不会指向新的master，此时当前的MMM之前对外提供写服务。

总结

主从的延时会导致写VIP的切换。

1.对外提供读写的虚拟IP是由monitor程序控制。如果monitor没有启动那么db服务器不会被分配虚拟ip,但是如果已经分配好了虚拟ip当monitor程序关闭了原先分配的虚拟ip不会立即关闭外部程序还可以连接访问（只要不重启网络），这样的好处就是对于monitor的可靠性要求就会低一些，目前还不知道能维持多长的时间，但是如果这个时候其中的某一个db服务器故障了就无法处理切换，也就是原先的虚拟ip还是维持不变，挂掉的那台DB的虚拟ip会变的不可访问。

2.agent程序受monitor程序的控制处理write切换，从库切换等操作。如果monitor进程关闭了那么agent进程就起不到什么作用，它本身不能处理故障。

3.monitor程序负责监控db服务器的状态，包括Mysql数据库、服务器是否运行、复制线程是否正常、主从延时等；它还用于控制agent程序处理故障。

4.monitor会每隔几秒钟监控db服务器的状态，如果db服务器已经从故障变成了正常，那么monitor会自动在60s之后将其设置为online状态(默认是60s可以设为其它的值)，有监控端的配置文件参数“auto_set_online”决定，群集服务器的状态有三种分别是：HARD_OFFLINE→AWAITING_RECOVERY→online

5.默认monitor会控制mmm_agent会将writer db服务器read_only修改为OFF，其它的db服务器read_only修改为ON,所以为了严谨可以在所有的服务器的my.cnf文件中加入read_only=1由monitor控制来控制writer和read,root用户和复制用户不受read_only参数的影响

以上就是本文的全部内容，希望本文对大家学习mysql有所帮助。

您可能感兴趣的文章:

关于避免MySQL替换逻辑SQL的坑爹操作详解
利用PHP访问MySql数据库的逻辑操作以及增删改查的实例讲解
MySql存储过程之逻辑判断和条件控制
mysql基础架构教程之查询语句执行的流程详解
redis服务器环境下mysql实现lnmp架构缓存
keeplive+mysql+drbd高可用架构安装步骤
mysql 5.7 docker 主从复制架构搭建教程
从零开始搭建MySQL MMM架构
mysql数据库应付大流量网站的的3种架构扩展方式介绍
Mysql逻辑架构详解

内容总结

以上是互联网集市为您收集整理的详解MySQL高可用MMM搭建方案及架构原理全部内容，希望文章能够帮你解决详解MySQL高可用MMM搭建方案及架构原理所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/583685.html

来源：【匿名】

【上一篇】MySQL索引用法实例分析【下一篇】用IE远程创建Mysql数据库的简易程序

更多 ►

【详解MySQL高可用MMM搭建方案及架构原理】教程文章相关的互联网学习教程文章

实现MHA，MySQL高可用集群架构【代码】

MHA：Master HA，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，如果财大气粗，也可以用一台专门的服务器来当MHA监控管理服务器 MHA工作原理1 从宕机崩溃的master保存二进制日志...

MySQL 部署 MHA 高可用架构 (一)【代码】

MHA 官方网址Manager : https://github.com/yoshinorim/mha4mysql-manager Node : https://github.com/yoshinorim/mha4mysql-nodeMHA 工作原理主库宕机处理过程 1. 监控节点 (通过配置文件获取所有节点信息)系统,网络,SSH连接性主从状态,重点是主库2. 选主 (1) 如果判断从库(position或者GTID),数据有差异,最接近于 Master 的 slave,成为备选主 (2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主. (3) 如果设定有...

在CentOS7上部署MySQL-MMM高可用群集【代码】【图】

MMM简介 MMM(MySQL主主复制管理器）是一套支持双主故障切换和双主日常管理的脚本程序。主要用来监控和管理MySQL Master-Master（双主）复制，虽然叫双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主切换时备选主的预热，可以说MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个Slave的read负载均衡。MMM时一套灵活的脚本程序，基于perl实现，...

keepalived+amoeba+mysql-mmm+mysql实现mysql读写分离及高可用【代码】【图】

最近尝试了一下mysql的读写分离和高可用的搭建。搭好之后体验了一下，效果还不错。这里跟大家分享一下。1、首先介绍一下mysql-mmm这个工具是干嘛使的？众所周知，mysql自身提供了AB复制。我们也可以很轻松的实现master-master双向复制，同时再为其中的一个master节点搭建一个slave库。这样就实现了master1与master2之间的双向复制，同时master1与slave1之间主从复制这样的架构。这样整个体系中就存在两个master，正常情况下只有...

mysql高可用方案MHA介绍

mysql高可用方案MHA介绍概述 MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用.在宕机的时间内（通常10—30秒内），完成故障切换，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署。还支持在线切换，从当前运行master切换到一个新的master上面，只需要很短的时间（0.5-2秒内），此时仅仅阻塞写操作，并不影响读操作，便于主机硬件维护。...

[ZZ]MySQL高可用解决方案

MySQL高可用解决方案(MySQL HA Solution) 什么是高可用性？很多公司的服务都是24小时*365天不间断的。比如Call Center。这就要求高可用性。再比如购物网站，必须随时都可以交易。那么当购物网的server挂了一个的时候，不能对业务产生任何影响。这就是高可用性。高可用性2个问题：如何共享数据或同步数据？如何处理failover？解释failover，意思就是当服务器down掉，或者出现错误的时候，可以自动的切换到其他待命的服务器，不影...

通过KeepAlived搭建MySQL双主模式的高可用集群系统【图】

企业级MySQL集群具备高可用、可扩展、易管理、低成本的特点。下面将介绍企业环境中经常应用的一个解决方案，即MySQL的双主互备架构，主要设计思路是通过MySQL Replication技术将两台MySQL Server互相将对方作为自己的Master，自己又同时作为对方的Slave来进行复制。这样就实现了高可用构架中的数据同步功能，同时，将采用KeepAlived来实现Mysql的自动failover。在这个构架中，虽然两台MySQL Server互为主从，但同一时刻只有一个MyS...

Mysql 高可用集群 ------ 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高可用配置【代码】

openstack高可用配置文档介绍利用两台物理主机实现高可用的openstack云平台，这里主要说明mysql和rabbitmq的高可用配置。 l 安装openstack云平台（两台主机上都部署openstack I版）安装centos操作系统，由于以active-passive模式配置mysql等服务的高可用时，需要单独的硬盘分区来装载和同步mysql等服务的数据，所以安装系统时，在系统镜像配置文件里预留出2-3块20G左右单独的硬盘分区作为备用;Yum –y update && reboot系统安装完...

mysql+mha高可用搭建

主库：172.25.254.125备库：172.25.254.225管理节点：172.25.254.126在开始之前，请先配置好服务器间的时间同步和名称解析一:在数据库节点安装mha node[root@dg53 ~]# rpm -ivh epel-release-5-4.noarch.rpm Retrieving epel-release-5-4.noarch.rpm warning: /var/tmp/rpm-xfer.yqwfYT: Header V3 DSA signature: NOKEY, key ID 217521f6 Preparing... ########################################### [100%] ...

mysql实现高可用架构之MHA

mysql实现高可用架构之MHA 一、简介MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automatingmaster failover （自动化主故障转移）功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。 MHA 是由...

MySQL 5.6通过MMM实现读写分离的高可用架构【代码】【图】

上一篇博文我们使用keepalived+主从同步搭建了一个简单的MySQL高可用架构（详见http://blog.51cto.com/jiangjianlong/1981994），今天再分享下通过MMM搭建的实现MySQL读写分离的高可用群集。MMM (Master-Master Replication Manager for MySQL)是使用perl开发的MySQL主主复制管理器，可实现读写分离的高可用架构，对主库实现写请求的高可用，对从库实现读请求的负载均衡。本文的架构示意图如下：一、部署环境二、环境准备1、配置好...

mysql mha高可用架构的安装

MMM无法全然地保证数据的一致性，所以MMM适用于对数据的一致性要求不是非常高。可是又想最大程度的保证业务可用性的场景对于那些对数据一致性要求非常高的业务，非常不建议採用MMM的这样的高可用性架构。那么可以考虑使用MHA。在mysql故障切换的过程中。MHA可以在0-30s内自己主动完毕数据库的故障切换操作，而且MHA可以最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA软件由两部分组成，Manager工具包和Node工具包。详...

docker swarm使用keepalived+haproxy搭建基于percona-xtradb-cluster方案的高可用mysql集群【代码】【图】

一、部署环境序号hostnameip备注1manager10710.0.3.107centos7;3.10.0-957.1.3.el7.x86_642worker6810.0.3.68centos7;3.10.0-957.1.3.el7.x86_643worker8010.0.3.80centos7;3.10.0-957.1.3.el7.x86_64docker版本docker version Client:Version: 18.09.0API version: 1.39Go version: go1.10.4Git commit: 4d60db4Built: Wed Nov 700:48:222018OS/Arch: linux/amd64Experimen...

keepalived + mysqlroute +mysql实现mysql高可用【代码】【图】

一、环境介绍： 1.1服务器角色配置：mysql-master 10.0.0.101(外) 172.168.1.101(内) mysql-slave 10.0.0.103 (外) 172.168.1.103(内) mysql-router01 10.0.0.102 (外) 172.168.1.102(内) mysql-router02 10.0.0.104 (外) 172.168.1.104(内) jumpserver 10.0.0.128 (外) 172.168.1.128(内)1.2配置数据库的一主两从库Slave01 和master都是允许读写的，slave02提供只读同时MySQL的主从复制都是事先配置成功的(此环境是开...

首页 / MYSQL / 详解MySQL高可用MMM搭建方案及架构原理

详解MySQL高可用MMM搭建方案及架构原理

内容导读

内容图文

您可能感兴趣的文章:

内容总结

内容备注

内容手机端

【详解MySQL高可用MMM搭建方案及架构原理】教程文章相关的互联网学习教程文章

实现MHA，MySQL高可用集群架构【代码】

MySQL 部署 MHA 高可用架构 (一)【代码】

在CentOS7上部署MySQL-MMM高可用群集【代码】【图】

keepalived+amoeba+mysql-mmm+mysql实现mysql读写分离及高可用【代码】【图】

mysql高可用方案MHA介绍

[ZZ]MySQL高可用解决方案

通过KeepAlived搭建MySQL双主模式的高可用集群系统【图】

Mysql 高可用集群 ------ MHA【代码】【图】

MySQL高可用配置【代码】

mysql+mha高可用搭建

mysql实现高可用架构之MHA

MySQL 5.6通过MMM实现读写分离的高可用架构【代码】【图】

mysql mha高可用架构的安装

docker swarm使用keepalived+haproxy搭建基于percona-xtradb-cluster方案的高可用mysql集群【代码】【图】

keepalived + mysqlroute +mysql实现mysql高可用【代码】【图】

MYSQL - 相关标签

架构 - 相关标签

MYSQL - 技术教程分类

MYSQL - 最新教程

MYSQL - 最热教程