MongoDB是一种流行的非关系型数据库，它支持分布式复制集，可以提高数据的可用性和容错性。复制集中有一个主节点（primary），负责处理客户端的读写请求，和多个从节点（secondary），负责同步主节点的数据。为了避免脑裂（split-brain）现象，即出现两个或以上的主节点，复制集还需要一个或多个仲裁节点（arbiter），负责在主节点故障时投票选举新的主节点。
但是，如果仲裁节点也发生了故障，那么复制集就会陷入一个无法自动恢复的状态。这是因为，如果剩余的节点数不足半数以上，那么就无法达成选举的法定人数（quorum），也就无法选出新的主节点。此时，从节点会变成只读模式，无法接受写入操作。这对于业务来说是非常不利的。
那么，在这种情况下，我们如何让备份节点变成主节点呢？有两种方法可以尝试：
方法一：恢复仲裁节点
如果仲裁节点是因为网络故障或者硬件故障而中断了，那么我们可以尽快修复它，并重新连接到复制集中。这样，仲裁节点就可以参与投票，帮助从节点选出新的主节点。这种方法的优点是比较简单和安全，不需要修改复制集的配置。但是，它的缺点是需要等待仲裁节点恢复，可能会造成较长时间的服务中断。
方法二：强制重新配置复制集
如果仲裁节点无法恢复，或者我们想要尽快让从节点变成主节点，那么我们可以采用强制重新配置复制集的方法。这种方法需要我们手动修改复制集的配置文件，指定一个从节点作为新的主节点，并删除仲裁节点。这样，从节点就可以强制成为主节点，并开始接受写入操作。这种方法的优点是比较快速和灵活，不需要等待仲裁节点恢复。但是，它的缺点是比较危险和不稳定，可能会导致数据不一致或者丢失。
具体操作步骤如下：
1. 登录到任意一个从节点上，执行rs.status()命令，查看复制集的状态和成员信息。
2. 找到一个数据最新且可用的从节点，并记下它的_id和host。
3. 执行rs.conf()命令，查看复制集的配置文件，并记下它的_version。
4. 执行cfg = rs.conf()命令，将配置文件赋值给一个变量。
5. 修改cfg变量中的以下内容：
将_version加一。
将_id为仲裁节点的成员删除。
将_id为新主节点的成员的_priority改为1。
将_id为其他从节点的成员的_priority改为0。
6. 执行rs.reconfig(cfg, {force: true})命令，强制重新配置复制集。
7. 执行rs.status()命令，查看复制集是否成功切换了主从角色。
注意：这种方法有一定的风险，可能会导致数据丢失或者不一致。在使用之前，请确保备份好数据，并在低峰期进行操作。