写入关注为 1 时主要的 mongodb 回滚答案

【问题标题】：mongodb rollback of primary when write concern is 1写入关注为 1 时主要的 mongodb 回滚
【发布时间】：2020-10-19 08:14:44
【问题描述】：

当客户端以副本集模式写入服务器时，以这种情况为例：

成功写入和确认
失败和错误。

如果 1. 发生但紧接着主节点出现故障 - 在将数据发送到辅助节点之前，会有麻烦。当返回时，它会回滚，虽然客户端得到了确认，但数据被解除了。

问题

为什么当主节点返回时它会回滚而不是将数据发送到其余节点？这是因为选举而发生的吗？而如果选举的结果是同一个节点呢？

猜想：服务器宕机，触发选举，发生不同的服务器。当它赶上新的primary时，写的消息不在oplog中，我猜他们继续使用不同的oplog？

我知道我们可以使用多数来改变这种行为，但想了解为什么会发生这种回滚。

有什么想法吗？

【问题讨论】：

标签： mongodb

【解决方案1】：

MongoDB 实现了单主复制，它要求任何时候只有一个服务器是权威的复制源。如果要复制回滚的数据，则必须将其合并到新的主节点中，这很复杂且容易出错，因为在旧主节点关闭时数据可能已被多次更改。

当主服务器出现故障并随后重新加入集群时，它会将自己的 oplog 副本与当前作为主服务器的服务器中的副本进行协调。由于其他写入操作可能同时发生在新主节点上，因此新的权威复制源是新主节点的 oplog。因此，旧主节点必须清除其 oplog 中不存在于新主节点 oplog 中的任何操作，并且这些操作会被回滚。

如果服务器重新加入时集群中没有可用的主服务器，则选举负责选择具有最新数据副本的服务器（基于 oplog 中最后一次操作的时间戳）。这成为新的主服务器，所有其他服务器将其 oplog 同步到此。因此，如果旧的主节点再次变为主节点并且集群中没有发生新的写入，则不会回滚。

回滚的数据不会丢失，而是保存在文件中，以便 DBA 检查并最终在需要时恢复。但是，您应该考虑所存储数据的性质，如果回滚永远不会发生至关重要，那么请使用适当的写入关注点来确保制作额外的副本以确保它永远不会丢失。

【讨论】：

我不太明白第一段，但其余部分非常清楚。非常感谢@Emir。
只是对下一段的介绍。单主复制是 MongoDB 复制的工作方式。另一种选择是多主复制，但在多主系统上，您会遇到数据冲突，因此您需要一种解决这些冲突的方法。它与 git 之类的源代码控制系统没有什么不同。如果两个开发人员更改了同一个文件，就会发生冲突，并且有人必须合并这两个版本。