文章目录
- 基于现有版本出具高可用多副本改造方案
- 1.1.单副本与多副本比较
- 1.2.多副本升级方案
- 1.2.1.升级方案参考
- 1.2.2.多副本部署过程示例
- 1.2.3.验证mongodb数据高可用
基于现有版本出具高可用多副本改造方案
1.1.单副本与多副本比较
现有xx平台的数据库mongodb部署架构为单节点单副本方式，要升级为多副本模式，利用数据冗余与安全。
1.2.多副本升级方案
1.2.1.升级方案参考
以下是单副本升级为多副本方案，可作为参考
1.2.2.多副本部署过程示例
以下为多副本部署的试例，可作参考
1.2.2.1.使用sts,先成功部署mongodb
利用现有yaml文件，可成功部署mongo-0,mongo-1,仲裁节点mongo-arbiter,如下示例
1.2.2.2.初始化mongodb数据库
通过kubectl -n mongodb exec -it mongo-0 /bin/bah登录进入容器中，直接执行mongo进入到mongodb数据库中
使用
Use adminrs.initiate(
{ _id: "rs0",
members: [
{ _id: 0, host: "mongo-0.mongo-headless.mongodb.svc.cluster.local:27017", priority: 50 },
{ _id: 1, host: "mongo-1.mongo-headless.mongodb.svc.cluster.local:27017", priority: 40 },
{ _id: 2, host: "mongo-arbiter-0.mongo-headless.mo-*ngodb.svc.cluster.local:27017", arbiterOnly: true } ] })执行结果如下：
对以上初始化命令作一解释：
rs.initiate() 是 MongoDB 中用于首次初始化一个副本集（Replica Set）的命令。执行该命令后，MongoDB 实例将从独立模式（Standalone）切换为副本集模式，并根据配置启动选举流程，选出主节点（Primary），建立主从复制关系
_id: “rs0”
指定副本集的逻辑名称为 rs0。
所有成员必须使用相同的副本集名称才能加入该集群。
该名称在整个 MongoDB 部署中应保持唯一。
成员 1：mongo-0（主节点候选）
{_id: 0,host: "mongo-0.mongo-headless.mongodb.svc.cluster.local:27017",priority: 50
}_id: 0：该成员在副本集中的唯一编号。
host：该成员的主机地址，使用 Kubernetes Headless Service 提供的 DNS 名称，确保 Pod 重启后地址不变。
priority: 50：优先级为 50（默认为 1），数值越高越容易被选举为主节点。mongo-0 在正常情况下将作为主节点运行。
成员 2：mongo-1（从节点）
{_id: 1,host: "mongo-1.mongo-headless.mongodb.svc.cluster.local:27017",priority: 40
}_id: 1：该成员的唯一编号。
host：指向 mongo-1 Pod 的 DNS 地址。
priority: 40：优先级低于 mongo-0，正常情况下作为从节点（Secondary）运行，用于数据同步和读负载分担。
成员 3：mongo-arbiter-0（仲裁节点）
{_id: 2,host: "mongo-arbiter-0.mongo-headless.mongodb.svc.cluster.local:27017",arbiterOnly: true
}arbiterOnly: true：表示这是一个纯仲裁节点（Arbiter）。
仲裁节点不存储数据，仅参与选举投票。作用是在两个数据节点之间提供“决胜一票”，确保在主节点故障时能选出新的主节点，避免脑裂（Split-Brain）问题。
资源占用小，适合用于优化部署成本。
通过rs.status（）查看：
主从节点，从节点，仲裁节点三个
通过rs.conf()再查看副本集，如下图：
1.2.3.验证mongodb数据高可用
1.2.3.1.插入数据测试主从高可用
在主节点上，插入数据1000条，用于验证，返回1000
// 插入 1000 条测试数据
for (let i = 1; i <= 1000; i++) {db.test.insertOne({_id: i,name: "user" + i,ts: new Date()});
}
// 查询总记录数
db.test.count();
再到从上查询，可以查询到1000，表示主从同步正常。
1.2.3.2.mongo-0优先级高时切换情况
1.2.3.2.1.停主节点mongo-0是否切换
停主节点mongo-0,验证mongo-1 从是否切换为主，
通过停进程，可以快速查询到mongo-1切换为主， mongo-0为从
当仲裁节点检测到原主节点mongo-0恢复并重新接入集群后，会触发新一轮选举；由于初始化时已配置mongo-0的优先级高于mongo-1，因此在选举中mongo-0获胜并自动重新成为主节点，实现主从角色的自动回归。
容器化部署好处，当delete mongo-0容器时，k8也会自动拉取起的mongo-0,
整个来回切换时间为10-20秒时间完成。不需要人为干预。
此时查看主从的数据
1000个数据存在，正常读取。
1.2.3.3.mongo-0、1优先级相同时切换情况
1.2.3.3.1.停主节点mongo-0是否切换
当delete掉mongo-0 后，快速查看副本情况，mongo-0是异常的。
此时mongo-1变为主节点，
待10-20秒后，再次查看mongo-0，已经变为从节点，如下图：
当主节点与从节点的优先级相同时，若主节点发生异常，副本集可自动将从节点选举为新的主节点，实现故障切换，保障系统高可用性。
查看数据是否正常：
Mongo-1主上：
Mongo-0从上：
总结：通过仲裁的选举，mongdb能满足高可用需求，由于是k8s部署，我们还是以设置优先级指定mongo-0作为主，这样恢复后，不会造成数据因延迟切换到mongo-1进行写数据，造成数据不一致问题。