MongoDB是一种流行的非关系型数据库，它支持分布式部署和复制集模式，可以提高数据的可靠性和容错性。在复制集模式下，MongoDB会选举一个主节点（primary）来处理客户端的读写请求，同时有若干个从节点（secondary）来同步主节点的数据，并在主节点故障时接替其角色。为了避免出现脑裂（split-brain）现象，即两个或以上的节点都认为自己是主节点，MongoDB要求复制集中必须有超过半数的节点存活才能选举出一个有效的主节点。这就意味着，如果复制集中有偶数个节点，那么就需要增加一个仲裁节点（arbiter）来参与投票，但不存储数据。仲裁节点可以是一个轻量级的进程，不需要占用太多的资源。
然而，仲裁节点也可能出现故障，导致复制集无法正常工作。例如，如果一个三节点的复制集中有一个从节点和仲裁节点同时宕机，那么剩下的主节点就会降级为从节点，停止接受写请求，因为它无法得到超过半数的投票。这种情况下，应该如何恢复复制集的正常运作呢？这里有几个可能的解决方案：
1.重启仲裁节点或从节点。这是最简单的方法，只要能够让仲裁节点或从节点重新加入复制集，就可以恢复投票机制，重新选举出一个主节点。当然，这需要保证仲裁节点或从节点的故障是暂时的，并且可以在较短的时间内修复。
2.添加一个新的仲裁节点或从节点。如果仲裁节点或从节点无法修复，或者需要较长的时间才能修复，那么可以考虑添加一个新的仲裁节点或从节点到复制集中，以补充投票数。这需要在剩下的从节点上执行rs.addArb()或rs.add()命令，并确保新加入的节点可以与其他节点通信。
3.强制重新配置复制集。如果以上两种方法都不可行，或者想要尽快恢复写服务，那么可以考虑强制重新配置复制集，即修改剩下的从节点的配置文件，让它认为自己是主节点，并且忽略其他失效的节点。这需要在剩下的从节点上执行rs.reconfig()命令，并传入force:true参数。这种方法有一定的风险，因为可能会导致数据不一致或丢失，所以应该谨慎使用，并且尽快修复或移除失效的节点。