如何/为什么在运行中的事务在同步复制中丢失，而不是半同步的？
如何/为什么在运行中的事务在同步复制中丢失，而不是半同步的？
提问于 2023-03-25 13:11:21
我正在阅读一篇关于SQL数据库难以扩展和ACID问题的文章。
以下是短文的链接：链接
今天的解决方案通常是后写复制，每个事务首先在某个主副本上执行，更新在事实发生后传播到其他副本。基本的主-从/日志传送复制是最简单的后写复制的例子，尽管在多个可能的主程序之一上首先执行每个事务的其他方案属于这个类别。除了对从副本进行过时读取的可能性之外，这些系统还面临一个基本的延迟-持久性-一致性权衡:要么主副本等待提交每个事务直到收到足够的复制的确认，要么在完成事务时提交。在后一种情况下，在运行中的事务在主副本失败时丢失，威胁到持久性，或者只有在失败的节点恢复后才会检索它们，而在其他副本上执行的事务则在发生故障时威胁一致性。
我假设通过前一条语句，它指向半同步复制，而后者则指向异步复制，这样，一旦在主副本上提交了事务，提交就被认为是成功的。
但是，我不太明白在失败时丢失事务意味着什么，以及如何在同步复制而不是半同步情况下丢失在运行中的事务？有人能帮我解释一下吗？
在执行事务之前，不是将其保存到磁盘吗？
回答 1
Database Administration用户
发布于 2023-03-27 14:18:54
在执行事务之前，不是将其保存到磁盘吗？
对于同步复制，事务中的新数据是：
- 写入事务日志，
- 根据实现的不同，可能还会写入数据文件，
- 发送到二级系统，
- 将其写入磁盘，然后
- 将确认发送回主服务器。
- 只有这样，主节点才会提交数据。
- 如果它不是在步骤2中写入数据文件，那么它现在就写在那里了。
如果主服务器出现故障，则二级系统(有数据)应该被提升为新的主系统。因此，没有数据丢失。
在后一种情况下，在运行中的事务在主副本失败时丢失，威胁到持久性，或者只有在失败的节点恢复后才会检索它们，而在其他副本上执行的事务则在发生故障时威胁一致性。
这是众所周知的异步复制的权衡。
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://dba.stackexchange.com/questions/325171
复制相关文章
相似问题
腾讯云开发者
