难以理解Postgres synchronous_commit = off和数据丢失

Question

我搞不懂“数据丢失”指的是synchronous_commit = off的上下文。

听起来，synchronous_commit = off增加写perf相当安全，可能会导致“数据丢失”，但不会导致“数据损坏”，这听起来更糟。

因此，据我所知，如果事情崩溃，我可能已经失去了一些数据在崩溃前一秒。但是数据库仍然是一致的，并且没有“损坏”，所以我可以简单地重新运行那些在备份后没有经历过的事情，对吗？我的数据库并没有以“有点发生”的状态结束，而所有的数据都被搞砸了？

我认为它也可以帮助我理解给我一些synchronous_commit = off不能使用的例子。

在文档(https://www.postgresql.org/docs/11/wal-async-commit.html)中，它说：

因此，如果客户端将根据事务将被记住的假设采取外部操作，则不应使用异步提交。例如，银行肯定不会使用异步提交来记录ATM分配现金的事务。但是，在许多情况下，例如事件日志记录，不需要这种强有力的保证。

我很困惑，因为ATM分配现金的例子太明显了，事件记录示例没有深入到足以让我理解差异的程度。

假设我们希望在我们的数据库表numbers：[1, 2, 3]中依次保存3项，我们有一个客户端，它查询表numbers上一次保存的内容，然后从停止保存的地方恢复。

numbers
---
id
---
1

因此，如果我们运行我们的客户机，它将找到1，从2开始。现在，如果我们编写2，使用异步提交，我们会得到一个过早的成功信号，但是我们的数据库突然崩溃，然后它才能真正持久。现在，如果我们要重新启动我们的客户端，它是从2重新恢复(正确)还是跳过它并从3开始(不正确)？

Answer 1

所以我可以简单地重新运行那些在恢复后没有经历过的事情，对吗？

你怎么知道要这么做？

假设我们想顺序地在数据库表中保存3个条目，名为numbers：1，2，3，我们有一个客户端，它查询表号以确定上次保存的内容，然后从停止保存的地方恢复。

所以它拯救了这三个人。它查询数据库并查看所有三个。然后写着“好的，我很好”然后就离开了。但是接着数据库崩溃了，当它恢复时，只有第一个数据库在那里。除非客户端总是定期重新检查，否则它不会知道为了修复它丢失了什么。

另一种情况。一个客户端提交所有三行，第二个程序立即查询并查看这三个行，并使用这些数据进行决策。如果第二个程序的决定完全记录在数据库中，那么您就没事了。如果这3行中的任何一行丢失，记录的决定也将丢失。但是，如果第二个程序将它的决定发送到数据库之外的东西，那么您可能会遇到问题，因为外部决策在崩溃中幸存下来，但是一旦数据库恢复，决策所依据的数据可能就不再存在了。