如何在 MongoDB 测试中用 mongobridge 注入网络延迟和连接拒绝故障

如何在 MongoDB 测试中用 mongobridge 注入网络延迟和连接拒绝故障【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo在编写 MongoDB 的副本集或分片测试时经常需要人为制造节点之间的网络问题让消息延迟几秒、彻底断开两个节点之间的连接然后验证写关注write concern是否会超时、主节点是否会失去多数派而 step down。MongoDB 测试框架内置了 mongobridge——一个网络故障注入工具它在每个测试节点和客户端包括集群内其他节点之间创建一个透明代理进程拦截消息并按配置执行延迟、丢弃、拒绝连接等操作再转发给节点本身。框架文档见 network_fault_injection_mongobridge.md示例测试见 mongobridge.js。本文的任务目标在ReplSetTest或ShardingTest测试中启用 mongobridge用delayMessagesFrom注入网络延迟、用rejectConnectionsFrom注入连接拒绝并通过断言验证注入生效和恢复后的正常行为。前提条件在写测试之前确认以下限制否则 mongobridge 无法工作或测试会被跳过enableTestCommands必须为true。mongobridge 的*From命令依赖 test commands测试环境中默认开启但建议在测试开头用assert.eq(jsTest.options().enableTestCommands, true);显式确认mongobridge.js 就是这么做的。集群不能启用 TLS。ReplSetTest和ShardingTest在useBridge: true且配置了 TLS 时会直接断言失败报错信息为useBridge cannot be true when using TLS见 replsettest.js 和 shardingtest.js。因此需要给测试文件加上requires_mongobridge标签让 resmoke 在 TLS variant 上跳过该测试。测试文件通常还需要requires_replication、requires_sharding分片场景标签写法可参考 mongobridge.js 头部。注意启用 priority ports 的 variant 下心跳等操作会绕过 bridge 代理所以 priority port 套件会排除所有带requires_mongobridge标签的测试见 replica_sets_with_priority_ports.yml 中的注释说明。步骤一在测试中启用 mongobridge通过useBridge: true参数开启。当ReplSetTest或ShardingTest配置了useBridge框架会为每个节点自动启动一个 mongobridge 进程客户端包括集群内节点的所有通信都经过这个代理let st new ShardingTest({ shards: {rs0: {nodes: 2}}, mongos: 1, config: 1, useBridge: true, // Enable mongobridge });副本集测试的写法类似let rst new ReplSetTest({ nodes: 3, useBridge: true, settings: {electionTimeoutMillis: 2000, heartbeatIntervalMillis: 400}, }); rst.startSet(); rst.initiate();示例中调低electionTimeoutMillis和heartbeatIntervalMillis是为了让分区导致的 step down 更快发生。如果你担心故障注入期间频繁选举干扰断言可以像 mongobridge.js 那样显式放大选举超时rsOptions: {settings: {electionTimeoutMillis: 60000}}。mongobridge 的构建目标位于 src/mongo/tools/mongobridge_tool/BUILD.bazel通常无需手动构建测试运行时由框架启动。步骤二注入网络延迟并验证写超时delayMessagesFrom(bridges, delayMs)让指定来源节点发往本节点的消息延迟delayMs毫秒转发传0表示移除延迟。它常用于模拟慢网络或测试超时行为。下面来自 mongobridge.js 的完整片段展示了“注入延迟 → 断言写失败 → 恢复”的主路径let st new ShardingTest({ shards: {rs0: {nodes: 2}}, mongos: 1, config: 1, useBridge: true, rsOptions: {settings: {electionTimeoutMillis: 60000}}, }); // 先在网络健康时注册数据库避免建库 DDL 的提交阶段因复制被中断而挂起 assert.commandWorked(st.s.adminCommand({enableSharding: testDB})); let wc {writeConcern: {w: 2, wtimeout: 4000}}; // delayMessagesFrom 应导致带 wtimeout 的写入报错 st.rs0.getPrimary().delayMessagesFrom(st.rs0.getSecondary(), 13000); assert.commandFailed(st.s0.getCollection(testDB.cll).insert({test: 5}, wc)); st.rs0.getPrimary().delayMessagesFrom(st.rs0.getSecondary(), 0);判断依据是assert.commandFailed复制被延迟 13000ms而w: 2, wtimeout: 4000的写关注会在 4000ms 内等不到第二份确认而失败。恢复delayMessagesFrom(..., 0)之后同样的写入应当成功用assert.commandWorked验证。这里有一个容易踩的坑文档在 mongobridge.js 的注释里明确说明如果测试会故意破坏复制要在网络健康时预先完成enableSharding等建库操作。否则首次向新 collection 写入会隐式注册数据库触发对 shard 和 config server 的 majority 写而复制恰好被中断测试会挂在建库 DDL 的提交阶段。步骤三拒绝连接与恢复rejectConnectionsFrom(bridges)立即断开指定来源的连接新连接会被拒绝已存在的连接在下次有请求通过时被关闭效果相当于模拟网络完全分区。恢复用acceptConnectionsFrom(bridges)它把代理恢复为默认的正常转发状态。接续步骤二的同一测试mongobridge.js 展示了拒绝连接的验证方式// 拒绝 secondary 到 primary 的连接后w2 的写入应失败 st.rs0.getPrimary().rejectConnectionsFrom(st.rs0.getSecondary()); assert.commandFailed(st.s0.getCollection(testDB.cll).insert({test: 5}, wc)); // 恢复连接后写入应成功 st.rs0.getPrimary().acceptConnectionsFrom(st.rs0.getSecondary()); // 注意恢复后的这条写入不带 wtimeout慢机器上 secondary 可能还在追数据 assert.commandWorked(st.s0.getCollection(testDB.cll).insert({test: 5}, {writeConcern: {w: 2}}));注意恢复后的断言刻意去掉了wtimeout源文档注释解释慢速机器上 secondary 可能还在追赶复制带wtimeout的断言容易引入 flakiness。*From命令的bridges参数可以传单个节点也可以传节点数组例如node.acceptConnectionsFrom([node1, node2, node3])。mongobridge 一共有四个故障注入命令acceptConnectionsFrom、rejectConnectionsFrom、delayMessagesFrom以及discardMessagesFrom(bridges, lossProbability)按 0.0 到 1.0 的概率随机丢弃消息模拟丢包。本文聚焦延迟与拒绝连接discardMessagesFrom的用法可查阅 network_fault_injection_mongobridge.md 的 Command Reference 一节。完整示例网络分区触发主节点 step down如果想验证更完整的故障——primary 与全部 secondary 断联后失去多数派——可以用文档给出的副本集分区示例来自 network_fault_injection_mongobridge.mdassert.eq(jsTest.options().enableTestCommands, true); // 设置带 mongobridge 的副本集 let rst new ReplSetTest({ nodes: 3, useBridge: true, settings: {electionTimeoutMillis: 2000, heartbeatIntervalMillis: 400}, }); rst.startSet(); rst.initiate(); // 将 primary 与所有 secondary 分区 let primary rst.getPrimary(); let secondaries rst.getSecondaries(); primary.rejectConnectionsFrom(secondaries); // 验证 primary 因失去多数派而 step down assert.soon(() { return rst.getPrimary() ! primary; }); // 恢复网络 primary.acceptConnectionsFrom(secondaries); rst.stopSet();验证点是assert.soon在超时时间内主节点引用发生变化说明选举发生了。恢复网络用acceptConnectionsFrom完成。注意事项与已知限制故障会影响下游状态。文档明确提醒在节点之间注入网络故障会影响心跳、sync source 选择、SDAM 等下游机制故障注入后测试集群可能不处于你预期中的状态。因此 mongobridge 测试应保持相对短小、目标明确避免这些故障的副作用污染后续测试。*From命令只影响经过 bridge 代理的连接。只有走代理的连接才会被拦截直连不经过 bridge 的通信不受影响。OP_QUERY exhaust 不支持。legacy exhaust query 不受 mongobridge 处理OP_MSG 的 exhaust cursor 是支持的。TLS 集群不支持这也是必须加requires_mongobridge标签的原因。如果测试关闭了enableTestCommands*From命令会失败mongobridge_testcommands.js 专门验证了这一行为命令在 test commands 开启时成功、关闭后失败。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考