MongoDB是一种流行的非关系型数据库，它支持复制集的功能，即将数据分布在多个节点上，以提高数据的可用性和容错性。复制集中有一个主节点（primary）和若干个从节点（secondary），主节点负责处理客户端的读写请求，从节点负责同步主节点的数据，并在主节点出现故障时接替其角色。
然而，如果复制集中只剩下一个节点，无论是主节点还是从节点，都会导致复制集无法正常工作。这是因为MongoDB要求复制集中至少有一个主节点和一个从节点，或者有一个仲裁者（arbiter），才能保证数据的一致性和完整性。如果复制集中只有一个节点，那么这个节点会降级为次要节点（secondary），并拒绝处理任何写请求，只能处理读请求，并且需要指定读取偏好（read preference）为次要节点。
那么，如果遇到了这种情况，我们应该怎么办呢？以下是一些可能的解决方案：
1.如果我们知道其他节点什么时候能够恢复，那么我们可以等待它们重新加入复制集，然后重新选举出一个主节点。这种情况下，我们需要保证剩下的那个节点有足够的磁盘空间来存储操作日志（oplog），以便与其他节点同步数据。
2.如果我们不知道其他节点是否能够恢复，或者我们想尽快恢复写服务，那么我们可以强制将剩下的那个节点提升为主节点。这种情况下，我们需要使用rs.reconfig()命令来修改复制集的配置，并将_id参数设置为剩下的那个节点的_id值，将priority参数设置为1，将votes参数设置为1，并将其他所有节点的priority和votes参数设置为0。这样，剩下的那个节点就会成为唯一的候选者，并自动成为主节点。但是，这种方法有一个风险，就是如果其他节点恢复了，并且有比剩下的那个节点更新的数据，那么就会出现数据不一致的问题。因此，在使用这种方法之前，我们需要确认其他节点是否已经彻底失效，并且不会再加入复制集。
3.如果我们想要保持复制集的完整性，并且避免强制提升主节点带来的风险，那么我们可以添加一个仲裁者到复制集中。仲裁者是一种特殊的节点，它不存储任何数据，只参与选举过程。通过添加一个仲裁者，我们可以使得复制集中有奇数个投票成员，并且能够选出一个主节点。这种情况下，我们需要使用rs.addArb()命令来添加一个仲裁者，并指定其地址和端口号。然后，剩下的那个节点就会与仲裁者进行选举，并成为主节点。但是，这种方法也有一个缺点，就是仲裁者本身也可能出现故障或网络问题，导致复制集再次失去多数投票成员，并降级为次要节点。因此，在使用这种方法之后，我们需要尽快恢复其他节点，并将仲裁者移除。
当MongoDB复制集只剩下一个节点时，我们需要根据实际情况，选择合适的方法来恢复复制集的正常工作。同时，我们也需要注意复制集的高可用性和故障转移策略，尽量避免出现这种情况。