MGR on 冯威的博客

MySQL高可用：ProxySQL读写分离+MGR

Wed, 03 Sep 2025 16:46:00 +0800

MGR 解决了高可用的问题，但如果数据库访问量大，特别是读多写少的场景，就需要读写分离架构了了，在 MGR 的基础上，前面加上 ProxSQL 就可以实现读写分离。

应用程序只和 ProxySQL 打交道
ProxySQL 做为应用和 MGR 集群中间的一个桥梁，让应用对 MGR 的变化没有感知

组件说明

MGR

mysql-master: 主节点 (Primary)，处理写操作
mysql-slave-1: 从节点 (Secondary)，处理读操作
mysql-slave-2: 从节点 (Secondary)，处理读操作
配置为单主模式 (Single-Primary Mode)
实现自动故障转移和数据同步

ProxySQL

端口 6033: MySQL 协议接口，应用连接端口
端口 6032: 管理接口，用于配置和监控
端口 6080: Web 管理界面 (可选)
提供读写分离、连接池、查询路由功能，可以对 mysql 的每个节点进行健康检查，进行故障转移，发现主节点出现故障，会将新的强求转移到新的主

ProxySQL 安装和配置

在《MySQL高可用-使用Docker部署MGR》中介绍了 MGR 的安装部署，在此基础之上继续来安装 ProxySQL。

1、修改 docker-compose.yml 文件，添加 proxysql 节点。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


proxysql:
 image: proxysql/proxysql:2.6.1
 container_name: proxysql
 hostname: proxysql
 volumes:
 - proxysql-data:/var/lib/proxysql
 - ./proxysql-config/proxysql.cnf:/etc/proxysql.cnf
 - ./proxysql-init-scripts:/etc/proxysql
 ports:
 - "6033:6033"
 - "6032:6032"
 networks:
 - mysql-mgr-network
 depends_on:
 - mysql-master
 - mysql-slave-1
 - mysql-slave-2
 healthcheck:
 test: ["CMD", "mysql", "-h", "127.0.0.1", "-P", "6032", "-u", "admin", "-padmin", "-e", "SELECT 1"]
 interval: 10s
 timeout: 5s
 retries: 5

/proxysql-config/proxysql.cnf：proxysql 的配置文件
/proxysql-config/proxysql.cnf：proxysql 初始化脚本所在的目录，可以直接配置为 ./proxysql-init-scripts:/docker-entrypoint-initdb.d ，则会在容器启动时执行。上面是将目录中的文件映射到容器内部，后续需要手动执行。

2、volumes 中映射的文件和目录内容，点击查看原文查看。

MySQL高可用-MGR运维常见问题和注意事项

Wed, 13 Aug 2025 09:45:00 +0800

MySQL 的高可用可以选择 MGR 方案，部署 MGR 很简单，可以参考《MySQL高可用-使用Docker部署MGR》，但在运行过程中，如果出现问题，如何快速解决？需要持续学习和实践。

下面我以实际用到的和我搜集到的一些资料来说说 MGR 在运维过程中的常见问题和注意事项。

部署前注意事项

硬件和环境要求

1、网络要求

低延迟网络：MGR 对网络延迟敏感，建议延迟 < 5ms 。因为 MGR 基于 Paxos 变种的共识算法，每提交一次事务至少跨网两次（prepare>ack>commit）。
稳定带宽：确保有足够的带宽支持数据同步，建议 ≥ 1Gbps 。全量 recovery、大事务或 DDL 时会产生突发流量，带宽不足会导致 flow-control 触发，集群整体降速

2、服务器配置

CPU：建议多核 CPU，至少4核以上
内存：充足内存，建议 ≥ 16GB
存储：使用 SSD 存储，确保足够 IOPS，考虑使用 RAID 10 而非 RAID 5/6，以获得更好的写性能
时钟同步：所有节点必须时钟同步（NTP）。MGR 的 GTID、view_change 事件都带时间戳，时间漂移会导致 “member expel” 误判。误判会导致节点是正常的，但会被踢出去。
分离数据和日志：将二进制日志和数据文件放在不同的物理存储上，参数大致如下：

1
2
3
4
5


datadir = /data/mysql
log_bin = /binlog/mysql-bin
binlog_cache_size = 1M 
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

操作系统优化

1、文件描述符限制

1
2
3


# 文件描述符限制
echo "mysql soft nofile 65536" >> /etc/security/limits.conf
echo "mysql hard nofile 65536" >> /etc/security/limits.conf

MGR + InnoDB 打开的文件数 = 表数量 × 分区 × 3（ibd、frm、ibtmp）+ binlog + relay log。文件描述限制如果比较小，操作系统层面的文件描述符（fd）耗尽，后果是 mysqld 再想去 open() 任何文件（包括新的 ibd、binlog、relay-log、tmp-file、socket 等）时都会得到 EMFILE，导致各种莫名奇妙的错误。

MySQL高可用-使用Docker部署MGR

Tue, 22 Jul 2025 21:57:00 +0800

MySql 的高可用方案很多，有 MHA、MGR、MySQL InnoDB Cluster 等。起初想学习下 MHA，了解后发现 MHA 在 Github 上的仓库已经没有更新了。不过 MHA 的兼容性比较好，有老版本的 MySQL 需要做高可用，还是值得一试的。

本文介绍下 MGR 的部署。

MGR (MySQL Group Replication) 是 MySQL 5.7.17 提出的，既可以很好的保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入。是以插件的形式提供，可以灵活部署。

MySQL MGR 集群是多个 MysQL Server 节点共同组成的分布式集群，每个 Server 都有完整的副本，它是基于 ROW 格式的二进制日志文件和 GTID 特性来实现的。

MGR 的优点

1、强一致性：基于原生复制及 Paxos 协议的组复制技术（以插件形式提供），确保数据的严格一致性。

2、高容错性：在少数节点故障时仍可正常运行，具备自动故障检测机制。节点间资源冲突采用无锁设计（如先到者优先）处理，避免错误。

3、高扩展性：支持节点动态自动加入与移除。新节点加入后自动同步数据至一致状态；节点移除后，集群自动更新并维护组配置信息。

4、高灵活性：支持单主模式与多主模式。单主模式下自动选举主节点，所有写操作路由至主节点；多主模式下，所有节点均可并发处理写操作。

MGR 的一些限制

1、仅支持 InnoDB 表，并旦每个表一定要有一个主键。

2、必须打开 GTID 特性，二进制日志格式必须设置为 ROW 。

3、MGR 不支持大事务。

4、仅支持 IPv4 网络，组大小限制为最少3个节点、最多9个节点。

5、不支持外键。

6、二进制日志不支持 Binlog Event Checksum 。

7、所有节点 server_id 和 server_uuid 需唯一。

部署前准备

为了方便，mysql 的主节点和从节点在一台虚拟机中进行测试
docker 版本：20.10.0
docker compose 版本：2.26.2
mysql 版本：8.0.39

开始部署

1、采用 docker-compose 的方式进行部署，部署目录 mysql-mgr 的文件结构如下图：

docker-compose.yml：容器编排文件，配置一个主和两个从的 mysql 节点。
mysql-config：此目录中是主和从的 mysql 配置文件
mysql-init-srcipts：此目录中是 mysql 启动时需要创建复制账号以及安装 mgr 插件
start-mgr.sh：三个 mysql 节点启动后，执行该文件进行 mgr 集群的启动。

2、将 mysql-mgr 拷贝到服务器，进入 mysql-mgr 目录执行 docker-compose up -d 。