Carry の Blog Carry の Blog
首页
关于
  • Hermes Agent 平台
  • Claude Code
  • OpenClaw
  • GPU 推理节点运维
  • MySQL 运维知识地图
  • Elasticsearch 运维知识地图
  • Redis 运维知识地图
  • TiDB 体系
  • DBA 常用 SQL 与命令
  • Nginx 运维知识地图
  • Prometheus 监控
  • Docker
  • Systemd
  • Iptables
  • Firewalld
  • Sshd
  • MySQL8 运维 SOP 手册
  • MySQL 实战 45 讲(读书笔记)
  • 分类
  • 标签
  • 归档
GitHub (opens new window)

Carry の Blog

好记性不如烂键盘
首页
关于
  • Hermes Agent 平台
  • Claude Code
  • OpenClaw
  • GPU 推理节点运维
  • MySQL 运维知识地图
  • Elasticsearch 运维知识地图
  • Redis 运维知识地图
  • TiDB 体系
  • DBA 常用 SQL 与命令
  • Nginx 运维知识地图
  • Prometheus 监控
  • Docker
  • Systemd
  • Iptables
  • Firewalld
  • Sshd
  • MySQL8 运维 SOP 手册
  • MySQL 实战 45 讲(读书笔记)
  • 分类
  • 标签
  • 归档
GitHub (opens new window)
  • MySQL

    • MySQL 运维知识地图:从入门配置到高可用排障
    • MySQL8 配置文件 my.cnf 重要参数解读
    • MySQL 导出 CSV 中文乱码:字符集链路从头讲一遍
    • MySQL 角色管理
    • MySQL网络抓包审计
    • MySQL 性能压测:Sysbench 1.0 实战
    • MySQL Router 实现读写分离
    • Gh-ost重建表,清除表碎片率
    • MySQL MGR配合MySQL-router实现innodb-cluster
    • MySQL 快速分析binlog定位问题
    • MySQL执行计划分析
    • DBA常用SQL和命令整理备查
    • 单表数据同步方案选型:为什么不该用 mysqldump 做「实时同步」
    • MySQL的事务隔离级别
    • MySQL存储过程批量生成数据
    • MySQL insert on duplicate key update,replace into , insert ignore的理解
    • MySQL不同字符集之间的区别和选择
    • MySQL为什么有时候会选错索引
    • MySQL死锁问题
    • MySQL使用SQL语句查重去重
    • MySQLdump逻辑备份
    • MySQL 基于 GTID 主从复制:跳过异常事务的正确姿势
    • MySQL8快速克隆插件使用指南
    • MySQL8双1设置保障安全
    • MySQL锁
    • innodb cluster安装
    • OPTIMIZE TABLE 和 ANALYZE TABLE 的区别:用实测数据说话
    • MySQLReplicaSet 安装
    • 脚本实现MySQL ReplicaSet 高可用
    • MySQL 的 Left join、Right join 和 Inner join 的区别
    • ORDER BY 配合 LIMIT 触发的索引选择陷阱
  • Redis

  • 高性能KV

  • TiDB

  • Elasticsearch

  • 数据管道

  • 其他数据库

  • 数据库
  • 其他数据库
Carry の Blog
2024-09-14
目录

MongoDB 集群Config Server 复制集的工作原理

# Config Server 复制集的工作原理

在 MongoDB 分片集群架构中,Config Server 负责存储集群的 元数据,包括每个分片上存储的数据范围和分片布局等重要信息。自 MongoDB 3.2 版本起,Config Server 必须以 复制集(Replica Set) 的方式部署,以确保元数据的高可用性和一致性。Config Server 复制集通过数据复制和自动故障转移来保证集群的稳定运行。

# 1. 配置服务器的角色

  • 元数据存储:Config Server 存储集群的元数据信息,包括每个 Shard 分片所管理的数据块范围(chunk)、数据分片的映射关系等。
  • 路由信息:Mongos 路由器在处理客户端请求时,会查询 Config Server,获取分片集群的结构信息,以确定请求应被路由到哪个分片上。

# 2. Config Server 复制集的组成

一个典型的 Config Server 复制集通常由 三个节点 组成,它们与普通的 MongoDB 复制集类似。通过复制集的方式,Config Server 具备高可用性,即使某个节点故障,其他节点仍然能够提供服务。

  • Primary(主节点):负责处理写操作,存储最新的元数据信息。
  • Secondary(从节点):从主节点同步数据,作为备份。当主节点失效时,从节点可以被选举为新的主节点。
  • Arbiter(仲裁节点)(可选):只参与投票选举,但不存储数据,用来保证奇数个节点以避免选举时出现平票。

# 3. Config Server 复制集的工作流程

  1. 元数据复制:在 Config Server 复制集中,元数据会通过 MongoDB 的复制机制从主节点(Primary)复制到从节点(Secondary)。这与普通的 MongoDB 复制集非常类似,保证所有 Config Server 节点的数据一致性。

  2. 高可用性和故障切换:

    • 当主节点失效时,剩下的 Secondary 节点会通过选举机制选出一个新的主节点,继续承担数据更新的职责。这保证了即使某个 Config Server 节点发生故障,整个集群仍然可以正常运行。
    • 在选举过程中,Mongos 会从其他可用的 Config Server 节点读取元数据,确保查询不中断。
  3. 读取和写入:

    • 读取:Mongos 会向 Config Server 复制集中的任意节点读取数据,通常是通过副本读取的方式从主节点获取最新的元数据。
    • 写入:当 Mongos 需要更新元数据(例如,当某个数据块被移动到其他分片时),它会写入到 Config Server 的主节点。主节点在写入后,其他从节点会同步这些更改。
  4. 防止单点故障:由于 Config Server 是复制集部署,所以即使某个节点出现故障,整个集群仍然可以通过其他副本继续提供服务,这样避免了元数据存储的单点故障问题。

# 4. Config Server 的部署要求

  • 奇数个节点:通常推荐部署三个节点的 Config Server 复制集。保持奇数个节点有助于选举过程中避免平票,同时在成本和冗余之间找到平衡。
  • 节点分布:为了提高容错性,Config Server 的节点应该分布在不同的物理机上,避免单点硬件故障导致集群元数据服务中断。

# 5. 配置步骤

假设我们有三台服务器,IP 地址分别为 192.0.2.11、192.0.2.12、192.0.2.13。可以通过以下步骤来配置 Config Server 复制集。

  1. 创建数据目录: 在每个配置服务器上,创建一个数据存储目录:

    mkdir -p /data/configdb
    
    1
  2. 编辑配置文件: 每台服务器上编辑 /etc/mongod.conf,使其作为 Config Server 启动:

    systemLog:
      destination: file
      path: "/var/log/mongodb/configsvr.log"
      logAppend: true
    storage:
      dbPath: "/data/configdb"
      journal:
        enabled: true
    net:
      bindIp: 0.0.0.0
      port: 27019
    replication:
      replSetName: "configReplSet"  # 定义配置服务器的复制集名称
    sharding:
      clusterRole: configsvr
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
  3. 启动 Config Server: 在每台 Config Server 上启动 MongoDB 实例:

    mongod --config /etc/mongod.conf --fork
    
    1
  4. 初始化复制集: 连接到其中一台 Config Server,并初始化复制集:

    mongo --host 192.0.2.11:27019
    rs.initiate({
      _id: "configReplSet",
      configsvr: true,
      members: [
        { _id: 0, host: "192.0.2.11:27019" },
        { _id: 1, host: "192.0.2.12:27019" },
        { _id: 2, host: "192.0.2.13:27019" }
      ]
    })
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
  5. 检查复制集状态: 使用 rs.status() 命令查看复制集状态,确保所有节点都正常加入并开始同步。


# 6. 小结

  • Config Server 在 MongoDB 分片集群中起到存储元数据的关键作用。
  • 自 MongoDB 3.2 起,Config Server 必须部署为 复制集,以确保元数据的高可用性。
  • Config Server 复制集通过 数据复制 和 自动故障转移,保证即使某个配置服务器节点宕机,集群仍能正常工作。
  • Mongos 会与 Config Server 交互以获取分片布局信息,处理客户端请求。

通过这样的架构设计,MongoDB 可以在大规模分片集群中提供强大的扩展性和高可用性,确保数据和元数据的可靠存储和访问。

#集群运维#MongoDB
上次更新: 8/29/2026
最近更新
01
当监控说没事而 DMV 说有事——N9E 与 SQL Server 指标交叉验证实战 原创
08-28
02
TiKV 节点 CPU 周期性打满,进程却只占 4%:一次热点 Region 的逆向排查 原创
08-28
03
托管 SQL Server 的运维边界:哪些 DBA 手段会失效,以及用什么替代 原创
08-28
更多文章>
Theme by Vdoing
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式