如果所有操作都在仲裁时执行，则确实需要修复。 通常需要修复以确保所有节点同步，但仲裁已确保仅在仲裁同步时返回成功。 因此，如果所有操作都在仲裁时执行，那么我们是否需要修复？
在我们的用例中，我们永远不会更新记录，我们只需添加然后删除记录。 （如果我们在“删除失败”之后看到这条消息是好的，那就不是灾难性的。）事实上 - 修复可以使记录恢复生机......这是不可取的（但不是灾难性的）< / p>
我认为在这种情况下，除非其中一个节点出现损坏，否则我们不需要修复。
我也会争论这个设置，即使删除成功，我们再次看到了记录，它不会是一个很大的交易＆＃39;。因此我认为我们实际上可以设置gc_grace = 0，如果quroum操作成功，那么只剩下2个......它们永远不会给我们提供针对那些违规节点的法定人数，因此我们永远不会看到这些记录无论如何（除非..节点死亡）。
因此，如果一个节点在删除后死亡（假设3个节点3用于仲裁）， 然后我们就有了陈旧的伴侣。 2vs2并且无法实现仲裁，但是如果再次读取其中一条记录，则提示修复将会启动（我不清楚这是否会运行，或者只运行配置的机会数量IE 10％是默认值，如果我们有法定人数失败？）。 如果gc_grace = 0，它可能会在删除后恢复生命，因此可能gc_grace = 24小时（允许读取修复更正）会降低再次查看记录的机会。
思想？
答案 0 :(得分：0)
您的基本思维过程是合理的 - 如果您使用法定人数进行编写并使用法定人数进行阅读并且永远不会覆盖，那么是的，您可能无需修复即可获得。
如果您必须重建失败的节点，则可能需要运行修复，因为替换可能会遗漏其中一个副本，并且您可能会留下三个中的一个，这可能是读完后会错过。如果发生这种情况，之前进行增量维修会使后续维修更快，但并非绝对必要。
你的最后两段并不一定准确 - 你的逻辑是有缺陷的（有5个节点和1个死亡，法定人数没有2v2僵局，这从根本上误解了法定人数的工作原理）。提示也是尽力而为，只在有限的窗口内，并且除非您将读取修复更改为非默认设置，否则无法保证读取修复。