『叶问』#41，三节点的MGR集群，有两个节点宕机后还能正常工作吗

MGR集群故障与恢复：理解多数派投票与可用性
最新推荐文章于 2025-10-11 09:43:35 发布
原创 最新推荐文章于 2025-10-11 09:43:35 发布 · 604 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #mgr #greatsql

『叶问』#41，三节点的MGR集群，有两个节点宕机后还能正常工作吗

每周学点MGR知识。

1. 三节点的MGR集群，有两个节点宕机后还能正常工作吗

要看具体是哪种情况。

如果两个节点是正常关闭的话，则会向MGR集群发送退出信号，这种情况下，这两个节点属于正常退出，最后仅剩的节点会被提升为Primary角色，还可以正常工作，允许对其进行读写，只是此时没有可用性冗余了。当其他节点再次启动并加入集群后，又能恢复正常服务。

如果是因为网络故障，或者mysqld进程发生oom、或被误杀、或其他原因退出了，则这些节点会被标识为 UNREACHABLE 状态，等待直到 group_replication_member_expel_timeout 时长（单位：秒）后这个节点才会正式退出集群。在这种情况下，一旦超过多数派节点处于 UNREACHABLE 状态时，则整个集群不可用，无法提供读写服务。这种情况下，需要把剩下的节点重启MGR服务才能恢复。

正常情况下，不要把 group_replication_member_expel_timeout 值调整太大，并且MGR的事务一致性级别尽量不要选择 AFTER 模式，以防出现整个集群服务不可用的问题，详细参见这篇文章：为什么MGR一致性模式不推荐AFTER。

2. MGR可以像主从复制那样只启动两个节点吗

MGR在初始化启动时，是可以只启动两个节点，甚至只有一个节点，但是这样就失去MGR的意义了。因为只要少于三个节点，就没办法进行多数派投票，当发生网络故障等情况时，无法投票确认哪些节点该被踢出集群。

Enjoy GreatSQL :)

文章推荐：

GreatSQL MGR FAQ https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA

万答#12，MGR整个集群挂掉后，如何才能自动选主，不用手动干预 https://mp.weixin.qq.com/s/07o1poO44zwQIvaJNKEoPA

『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实践》 https://mp.weixin.qq.com/s/u7k99y6i7riq7ScYs7ySnA

一条sql语句慢在哪之抓包分析 https://mp.weixin.qq.com/s/AYibbzl860D90rOeyjB6IQ

万答#15，都有哪些情况可能导致MGR服务无法启动 https://mp.weixin.qq.com/s/inSGpd0Q_XIl2Mb-VsvNsA

技术分享 | 为什么MGR一致性模式不推荐AFTER https://mp.weixin.qq.com/s/rNeq479RNsklY1BlfKOsYg

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支，专注于提升MGR可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。

Gitee: https://gitee.com/GreatSQL/GreatSQL

GitHub: https://github.com/GreatSQL/GreatSQL

Bilibili： https://space.bilibili.com/1363850082/video

微信&QQ群： 可搜索添加GreatSQL社区助手微信好友，发送验证信息“加群”加入GreatSQL/MGR交流微信群

QQ群：533341697 微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 发布！

GreatSQL社区
关注
MGR 多主模式节点宕机重启
shilukun的博客
11-14 2377
1，初始主节点宕机 当mysql服务进程还在: 执行如下命名  mysql>  select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+-...
《叶问》38期，MGR整个集群挂掉后，如何才能自动选主，不用手动干预
老叶茶馆
11-28 1342
当集群中所有节点都宕机后，集群再次启动后，能否自动选主1、MGR集群所有节点都宕机后，集群重启，能否自动选主和启动MGR服务这是个来自群友的问题。首先，MySQL服务利用systemd...
《叶问》37期，三节点的MGR集群关掉两个节点后还能继续读写吗
老叶茶馆
11-21 1626
不发碎碎念了，唠叨那些没啥意思，重回『叶问』正轨。1. 三节点的MGR集群关掉两个节点后还能继续读写吗这里要先明确一个前提，两个节点是正常关闭MGR服务，还是异常宕机。如果两个节点是手动执...
快速测试 3节点的redis sentinel集群宕机2个节点以后是否仍能正常使用
wejack的专栏
12-07 805
有同事问我，三个redis sentinel节点，宕机两个节点以后，是否还能够正常的通过redis sentinel正常访问redis的数据。我想了想，理论上是可以的，但是我没试过，今天有时间就测试了一下。python 程序启动后会每秒请求sentinel地址获取redis连接设置值，然后我将sentinel集群的节点停掉两个（包括master节点），依然可以正常设置值，在redis的 master节点可以获取最新设置的值，说明sentinel节点停掉两个仍是可用状态。集群启动好以后，测试是否正常启动。
GreatSQL数据库8.0快速安装部署
最新发布
m0_61389590的博客
10-11 380
本文介绍了GreatSQL数据库在Linux系统上的安装配置流程。主要内容包括：1)系统兼容性检查和环境准备；2)关闭SELinux和防火墙；3)安装依赖包；4)创建安装目录并上传安装包；5)解压和安装RPM包；6)配置数据目录权限；7)初始化数据库并获取临时密码；8)修改配置文件；9)启动服务并修改密码；10)创建远程访问用户。最后还说明了如何使用Navicat客户端连接数据库。整个流程详细说明了从安装到配置的完整步骤。
mysql实战之mgr集群
qq_62789440的博客
01-10 2936
MGR 是一个新的高可用与高扩展的方案，集群中的任何节点数据都是一样的，可以实现任何节点都可以写入，实现了真正意义上的多主。
mysql从节点宕机重启_MGR 多主模式节点宕机重启
weixin_39614011的博客
02-10 791
1，初始主节点宕机当mysql服务进程还在:执行如下命名mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+------...
《童虎学习笔记》9分钟学会向MySQL MGR集群中添加节点-方案1
tonghu_note的博客
04-09 1468
1
mysql高可用集群MGR组复制集群介绍及搭建说明
05-27
- **节点**: MGR集群由多个节点组成，每个节点都是一个MySQL实例。 - **通信**: 节点间通过网络通信来交换数据和状态信息。 - **组**: 所有参与MGR的节点形成一个逻辑组，共同维护数据的一致性和完整性。 **2. ...
详解MySQL 5.7 MGR单主确定主节点方法
09-09
在单主模式下，MGR会自动选举出一个主节点，其余节点作为从节点。本知识点重点解释如何在MySQL 5.7 MGR环境中确定当前的主节点。 在MGR中，每个组成员都有一个唯一的成员ID（MEMBER_ID），这个ID是安装时自动生成的...
galeracluster高可用集群异常恢复
github_39319229的博客
06-28 1676
galeracluster高可用集群异常恢复
《童虎学习笔记》14分钟结合ProxySQL处理超半数MGR节点故障
tonghu_note的博客
04-18 1109
1
Docker之MySQL_GROUP_REPLICATION组复制（MGR）、宕机节点恢复和Spirngboot整合
Meta39的博客
12-06 1007
Docker之MySQL_GROUP_REPLICATION组复制（MGR）、宕机节点恢复和Spirngboot整合
mysql脑裂_GALERA ARBITRATOR - 数据库多主集群对应脑裂的解决方案
weixin_35704532的博客
12-23 642
GALERA ARBITRATOR因为Galera集群需要至少3个节点组成集群，才不会发生脑裂状况。Galera集群部署推荐的是至少三个实例或三个节点或三个数据中心等等。如果添加一个节点会成本太高，比如添加多一台数据库服务器，那你可以选择使用Galera Arbitrator。Galera Arbitrator就是集群中的一份子，可以参与投票，但不参与实际的复制。注意：虽然Galera Arbi...
mysql 分裂式集群_mysql galera cluster 集群的分裂与仲裁机制
weixin_29219539的博客
01-19 447
集群的分裂当集群由于网络原因分裂为几个单独的组时(一组可能是单节点，也可能是几个互联的节点)，数据出现不一致，此时可能产生脑裂及数据不一致。这种情况 下，只有一组节点能够继续提供服务，这组节点的状态是primary。当这种状况发生时，galera cluster会启动特别的仲裁算法来选举一个组件作为primary组件。cluster size决定了quorum仲裁的投票数(因此是单数比较好，避免产...
mysql mgr集群断电重启
ApexPredator的博客
07-01 762
mysql mgr集群断电重启
[MySQL] MySQL MGR集群单台重启后没有自动重新加入集群
第八个男人
10-08 1669
长假期间一台物理机宕机，致使运行在上面的某个MySQL MGR集群三台数据库中的某一台虚拟机HOSTNAME1宕机。修复物理机后，将该虚拟机开机，开机会却未能自动重新加入集群。在集群的另外一台HOSTNAME2上使用cluster.status()查看状态是这样的。 原本HOSTNAME1是ReadWrite，HOSTNAME2和HOSTNAME3是ReadOnly状态。目前来看，宕机的HOSTNAME1为R/W的Missing状态，而HOSTNAME3被选择成为了新的R/W角色。 在HOSTNAM
MySQL MGR 宕机后如何开启复制
灯火觅阑珊
06-13 1721
MGR断电后的重启，分两种情况 整个MGR集群宕机 1.首先将所有实例开启，例如 mysqld_safe --defaults-file=/etc/my.cnf1 --user=mysql & 2.然后连接上一个实例，执行以下操作，引导并开启组复制 set global group_replication_bootstrap_group=on; start group_replicatio...
mysql mgr优点_MySQL MGR 有哪些优点
weixin_42166918的博客
01-28 931
MGR(Mysql Group Replication)是5.7版本新加的特性，是一个MySQL插件。MGR 是一个新的高可用与高扩展的方案，集群中的任何节点数据都是一样的，可以实现任何节点都可以写入，实现了真正意义上的多主。主要包含以下几部分：API层：负责完成和MySQL Server的交互，得到Server状态，完成事务的管理。组件层：主要包括3个特定组件，Capture负责收集事务执行的相...
一个mster两个woker节点的集群是不是不能用rook部署ceph集群，三个mons 2个mgr,三个ods
04-02
<think>好的，我现在需要帮助用户解答关于在1个master和2个worker节点的Kubernetes集群上使用Rook部署Ceph集群的问题，用户还提到想要部署3个MON、2个MGR和3个OSD。首先，我需要回忆Ceph和Rook的相关知识，特别是关于节点数量和组件部署的要求。 首先，用户的问题是关于在这样的集群架构下是否可行。用户可能是在自己的测试环境中尝试搭建Ceph，可能遇到了问题，或者想确认是否可行。用户提到的是三个MON、两个MGR和三个OSD，但节点数量只有三个（1 master + 2 worker）。需要分析每个组件的需求。 Ceph的MON（Monitor）需要奇数个来维持仲裁，通常至少三个。但如果在三个节点的情况下，每个节点部署一个MON，理论上是可以的。不过问题在于，如果master节点是否也作为工作节点使用。通常，Kubernetes的master节点默认有污点，不允许普通Pod调度，除非用户手动去掉污点。所以用户需要确认master节点是否可以作为MON、MGR或OSD的节点。如果master节点不可调度，那么只有两个worker节点，这时候部署三个MON可能有问题，因为需要三个节点，而用户只有两个可用。这时候可能需要调整MON的数量为1个，但这会牺牲高可用性。 接下来是MGR（Manager），Ceph要求至少两个MGR以实现高可用。用户想要部署两个，这在两个节点上是可行的，每个节点一个MGR。但同样需要考虑节点调度的问题。 然后是OSD，每个OSD对应一个磁盘。用户想要三个OSD，但只有两个worker节点的话，可能需要每个节点部署多个OSD，这取决于每个节点上的可用磁盘数量。Rook会自动在每个节点上为每个可用磁盘创建OSD，所以如果每个worker节点有多个磁盘，可以部署多个OSD。但如果每个节点只能有一个OSD，那么总共只能有两个，无法满足三个OSD的需求。所以用户需要检查每个worker节点是否有足够的磁盘。 另外，还需要考虑资源限制。如果master节点也被用来部署Ceph组件，需要确保有足够的CPU、内存和存储资源。否则可能导致性能问题或Pod无法调度。 总结一下，用户的问题主要在于节点数量和组件部署的匹配。可能的解决方案包括调整MON数量，确保节点可调度，检查磁盘数量，以及资源分配是否足够。需要将这些点详细解释给用户，并给出具体的配置建议和注意事项。</think>--- ### **一、核心结论** **可以部署**，但需要满足以下条件： 1. **Master节点需解除污点（Taint）**，允许调度Ceph Pod（默认Master节点不允许部署工作负载） 2. **至少3个节点均具备存储设备**（每个节点至少1块可用磁盘用于OSD） 3. **合理规划资源配额**，避免资源争抢 --- ### **二、关键组件部署规则分析** | 组件 | 最小数量 | 节点分布要求 | 注意事项 | |-------|----------|----------------------------------|--------------------------------------------------------------------------| | **MON** | 3 | **必须部署在不同节点** | 若节点数不足3，需强制调整`mon.count=1`（牺牲高可用性） | | **MGR** | 2 | 可部署在任意节点 | 建议分散到不同节点以提高可用性 | | **OSD** | 3 | 每个OSD对应一个独立磁盘 | 若节点数不足，需在部分节点挂载多块磁盘（例如：2节点各挂载2块磁盘） | --- ### **三、具体场景验证** #### **场景1：Master节点参与调度** - **步骤1：解除Master节点的污点** ```bash kubectl taint nodes <master-node-name> node-role.kubernetes.io/control-plane- ``` - **步骤2：部署Rook Ceph** ```yaml # cephcluster.yaml 示例片段 spec: mon: count: 3 # 强制要求3个节点可用 allowMultiplePerNode: false # 禁止单节点部署多个MON mgr: count: 2 storage: nodes: - name: "master-node" devices: - name: "sdb" # 必须存在实际磁盘 - name: "worker-node-1" devices: - name: "sdb" - name: "worker-node-2" devices: - name: "sdb" ``` **风险**：Master节点承担Ceph负载可能导致稳定性下降 #### **场景2：仅使用2个Worker节点** - **调整MON数量为1**（不推荐生产环境） ```yaml spec: mon: count: 1 # 失去高可用性 allowMultiplePerNode: false ``` - **OSD解决方案**：每个Worker节点挂载2块磁盘 ```yaml storage: nodes: - name: "worker-node-1" devices: - name: "sdb" - name: "sdc" # 第二块磁盘 - name: "worker-node-2" devices: - name: "sdb" - name: "sdc" ``` --- ### **四、生产环境建议** 1. **最小集群规模**：3个Worker节点（每个节点部署1MON+1OSD） 2. **Master节点隔离**：仅用于控制平面，不参与Ceph数据存储 3. **硬件配置**： - 每个节点至少2核4GB内存 - 磁盘类型：SSD优先（HDD需增加OSD数量补偿性能） 4. **网络要求**： - 万兆网络（至少千兆） - 分离公共网络与集群网络（通过`network`配置实现） --- ### **五、部署验证命令** ```bash # 检查MON分布 kubectl -n rook-ceph get pods -l app=rook-ceph-mon -o wide # 检查OSD状态 kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph osd tree # 查看资源使用 kubectl -n rook-ceph top pod ``` --- ### **六、故障模拟与恢复** - **单节点故障测试**： ```bash # 关闭一个Worker节点 kubectl cordon <node-name> && kubectl drain <node-name> # 观察Ceph健康状态（预期出现HEALTH_WARN，但数据仍可访问） ``` - **恢复策略**： - 自动：Rook默认启用故障转移（需确保资源充足） - 手动：替换故障磁盘后执行`kubectl uncordon <node-name>` --- 通过合理规划，即使在小规模集群中也能部署Rook Ceph，但需明确**牺牲高可用性带来的风险**。建议测试环境验证通过后再投入生产使用。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值