MySQL复制具有即时数据一致性吗？

Question

我正在考虑使用一种noSQL方案来处理当前的项目，但是我对很多这些数据库中的“最终一致性”条款感到犹豫。最终一致性与处理复制滞后的mySQL数据库有什么不同吗？在需要立即数据一致性时，我过去使用的一种解决方案是从主服务器读取。

然而，我对关系型数据库声称具有强数据一致性感到困惑。我猜我应该使用事务，并且那会给我强一致性。那么，假设mySQL复制可能会滞后，编写应用程序时是否明智？

- inquiring minds

---

我认为对于你的问题，更精确的技术是InnoDB，而不是mysql。存储引擎是处理复制与其他选项相当的地方。 - Anthony

http://www.palominodb.com/blog/2012/06/20/mystery-solved-replication-lag-innodb - Anthony

谢谢。我猜事务可以防止主服务器写入和从服务器读取不一致，你可以使用InnoDB来实现。我正在编辑我的问题。 - inquiring minds

Answer 1

在ACID中，一致性意味着在任何更改之前和之后都满足所有约束条件。当系统确保您无法读取不一致的数据时，例如他们说您永远不会读取其中一个子行引用不存在的父行，或者只应用了一半事务但另一半还没有应用（经典示例是从一个银行账户借记但尚未为收件人银行账户贷记）。

MySQL中的复制默认情况下是异步的，或者最好是“半同步”的。在任何一种情况下，它都有延迟。实际上，复制副本始终落后于至少一小部分秒，因为主服务器直到事务提交才写入其二进制日志，然后副本必须下载二进制日志并中继事件。

但更改仍然是原子的。不能读取部分更改的数据。您可以读取已提交的更改，在这种情况下，满足所有约束条件，否则更改尚未提交，在这种情况下，您将看到事务开始前的数据状态。

因此，在滞后的复制系统中，您可能会暂时读取旧数据，但不会读取不一致的数据。

而在“最终一致性”的系统中，您可能会读取部分更新的数据，其中一个账户已被借记，但第二个账户尚未贷记。因此，您可以看到不一致的数据。

如果您的应用程序需要绝对实时数据，则确实需要小心从副本中读取。每个应用程序都有不同的复制延迟容忍度，实际上，在一个应用程序中，不同的查询对延迟有不同的容忍度。关于此我做了一个演示：MySQL和PHP的读写分离（Percona网络研讨会2013）

- Bill Karwin

---

Bill，你能看一下这个吗？https://dev59.com/l7Tma4cB1Zd3GeqP1iKI - Foo

@Bill Karwin，能否请您发布您演示文稿的新链接？ - RP-

我认为这就是那个 https://www.percona.com/sites/default/files/presentations/Read%20Write%20Split.pdf - RP-

那就是了。我不知道它已经从Slideshare中删除了。我会联系他们，找出为什么它被暂停了。我猜因为演示中频繁使用了“奴隶”一词。 - Bill Karwin

Answer 2

为了完整起见，我还将从CAP定理的角度回答这个问题。另外，在ACID中的一致性与CAP中的一致性不同。

根据CAP定理中的一致性原则，每次读取都会接收到最新的写入或错误信息（这被称为线性可序性，也称为强一致性或原子一致性）。由于MySQL使用异步复制，默认情况下它不是强一致的，因此在某些节点拥有最新的写入时，其他节点可能仍未拥有该信息。

如果您的MySQL版本为8.0.14或更高版本，则group_replication_consistency可以进行配置，但仍然默认为EVENTUAL（在以前的MySQL版本中，这是不可配置的，默认值）。详情请参阅：https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-consistency-guarantees.html 此外，如果您正在使用MySQL Cluster（这是一个不同的产品/技术，我发现他们称其为“集群”很困惑），MySQL文档本身说它只保证事件上一致性。详情请参阅：https://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-eventual-consistency.html 因此，我们可以说MySQL是一个最终一致的系统。根据定义，每个异步复制的系统都是最终一致的。

- wow so much info