印刻数据库

外观

MongoDB 复制集高可用性 ​

复制集架构设计 ​

节点数量选择 ​

  • 奇数节点设计：推荐使用3、5或7个节点，确保选举过程中能形成多数派
  • 节点角色分配：
    • 主节点（Primary）：处理所有写操作和读操作（默认）
    • 从节点（Secondary）：复制主节点数据，提供读扩展
    • 仲裁节点（Arbiter）：仅参与选举，不存储数据，用于奇数节点配置

地理分布式部署 ​

  • 多可用区部署：将节点分布在不同可用区，提高区域故障容忍度
  • 跨区域部署：使用延迟可接受的跨区域复制，实现灾备
  • 节点优先级设置：通过调整priority参数控制主节点选举偏好
javascript
// 配置节点优先级
cfg = rs.conf()
cfg.members[0].priority = 100  // 主节点优先
cfg.members[1].priority = 50   // 从节点次优先
cfg.members[2].priority = 1    // 从节点低优先
rs.reconfig(cfg)

自动故障转移机制 ​

故障检测流程 ​

  • 心跳检测：节点间每2秒发送一次心跳包
  • 故障判定：当主节点超过electionTimeoutMillis（默认10秒）未响应，触发选举
  • 选举过程：
    1. 从节点发起选举
    2. 收集其他节点投票
    3. 获得多数票的节点成为新主节点
    4. 新主节点通知所有节点

选举超时配置 ​

yaml
# mongod.conf
replication:
  replSetName: rs0
  electionTimeoutMillis: 15000  # 调整为15秒

读写分离配置 ​

读偏好设置 ​

  • primary：仅从主节点读取（默认）
  • primaryPreferred：优先从主节点读取，主节点不可用时从从节点读取
  • secondary：仅从从节点读取
  • secondaryPreferred：优先从从节点读取，从节点不可用时从主节点读取
  • nearest：从网络延迟最低的节点读取

应用层面配置 ​

javascript
// Node.js 驱动示例
const client = new MongoClient(uri, {
  readPreference: 'secondaryPreferred',
  readConcern: { level: 'majority' }
});

复制延迟管理 ​

复制延迟原因 ​

  • 网络延迟
  • 从节点负载过高
  • 大事务或批量写入
  • 索引构建或压缩操作

监控与优化 ​

  • 监控指标：
    • replLag：复制延迟时间
    • oplogWindowHours： oplog可覆盖的时间范围
    • replSetGetStatus：查看所有节点复制状态
bash
# 监控复制延迟
mongosh --host rs0/host1:27017,host2:27017,host3:27017 --eval "rs.printSecondaryReplicationInfo()"
  • 优化措施：
    • 确保从节点硬件配置不低于主节点
    • 调整oplogSizeMB参数，增大oplog容量
    • 使用writeConcern控制写操作持久化级别

优先节点与隐藏节点 ​

优先节点配置 ​

javascript
// 设置优先节点
cfg = rs.conf()
cfg.members[0].priority = 100
rs.reconfig(cfg)

隐藏节点使用场景 ​

  • 用于备份操作，避免影响生产流量
  • 用于报表查询，隔离分析负载
  • 用于升级测试，降低风险
javascript
// 配置隐藏节点
cfg = rs.conf()
cfg.members[3].hidden = true
cfg.members[3].priority = 0
rs.reconfig(cfg)

延迟节点配置 ​

延迟节点作用 ​

  • 用于恢复误删除数据
  • 提供时间点恢复能力
  • 延迟时间建议设置为业务可接受的最大恢复时间

配置方法 ​

javascript
// 配置延迟节点（延迟24小时）
cfg = rs.conf()
cfg.members[4].priority = 0
cfg.members[4].hidden = true
cfg.members[4].slaveDelay = 86400  // 秒
rs.reconfig(cfg)

复制集监控 ​

关键监控指标 ​

  • 选举事件：监控频繁选举情况
  • 复制延迟：设置阈值告警（如超过30秒）
  • ** oplog 状态**：监控oplog大小和剩余时间
  • 节点状态变化：跟踪节点角色切换

监控工具 ​

  • MongoDB Atlas：提供实时监控和告警
  • Ops Manager：企业级监控解决方案
  • Prometheus + Grafana：开源监控组合
  • mongostat：命令行监控工具
bash
# 使用mongostat监控复制集
mongostat --host rs0/host1:27017,host2:27017,host3:27017 --discover

常见问题（FAQ） ​

Q1: 复制集节点数量为什么推荐奇数？ ​

A1: 奇数节点可以确保在选举过程中总能形成多数派，避免脑裂问题。例如3节点集群中，2个节点即可形成多数派；5节点集群中，3个节点即可形成多数派。

Q2: 仲裁节点（Arbiter）的使用场景是什么？ ​

A2: 仲裁节点适用于资源有限的环境，当无法部署额外的数据节点时，使用仲裁节点来维持奇数节点配置。仲裁节点仅参与选举，不存储数据，资源消耗低。

Q3: 如何提高复制集的写性能？ ​

A3: 可以通过以下方式提高写性能：

  • 调整writeConcern级别，根据业务需求选择合适的持久化级别
  • 确保主节点硬件资源充足（CPU、内存、磁盘IO）
  • 合理设计文档结构，减少写入操作的复杂性
  • 使用分片集群扩展写能力

Q4: 复制延迟过高怎么办？ ​

A4: 复制延迟过高可能由多种原因引起：

  • 检查网络连接质量
  • 确保从节点硬件配置与主节点匹配
  • 检查从节点是否有长时间运行的操作（如索引构建）
  • 增大oplog容量，避免oplog滚动过快
  • 考虑使用更高效的存储引擎

Q5: 如何安全地添加新节点到复制集？ ​

A5: 安全添加新节点的步骤：

  1. 确保新节点硬件配置符合要求
  2. 安装相同版本的MongoDB
  3. 配置基本的mongod参数
  4. 启动mongod进程
  5. 使用rs.add()命令将节点添加到复制集
  6. 监控初始同步进度
  7. 根据需要调整节点角色和优先级

Q6: 复制集自动故障转移需要多长时间？ ​

A6: 自动故障转移时间主要由electionTimeoutMillis参数控制（默认10秒），加上选举过程时间，通常在10-30秒之间完成故障转移。可以根据业务需求调整electionTimeoutMillis参数，但过小的值可能导致不必要的选举。