如何避免复制滞后的情况下，所有写在主和副本上读取？

Question

我一直在处理复制滞后问题。我正在尝试重构我的DB基础结构。第一步是读写分离.我使用ProxySQLто实现它。现在我有了masterDb，在这里所有的插入和更新都在执行，而在两个副本中我路由所有选择。

但我面临的主要问题是复制滞后。因为通常在更改DB中的某些内容时，您会立即读取数据，并期望查询结果中有新的数据，但是由于复制滞后，我会收到过时的数据。在谷歌搜索后，我找到了这篇文章https://www.percona.com/blog/2018/11/29/mysql-high-availability-stale-reads-and-how-to-fix-them/，根据这个信息，2018年最好的选择是"ProxySQL 2.0GTID一致读取“

有2018年的最新消息吗？也许你们知道更好的解决方案？请分享!

Answer 1

有些SELECTs用于支持您将要执行的插入/更新/删除操作。您不能将它们发送到副本；它们必须在主服务器中完成，通常在与写操作相同的事务中完成。检查一下，看看ProxySQL没有那么做。

除了比尔提到的以外，还有其他的花招。通过将某些内容插入复制流中，然后在副本上检查它，您可能能够查看您的写入是否已写入副本。在复制变成多线程之前，这是很好的。所以要小心那些老掉牙的建议。

您还可以计划将您的应用程序更改为至少有两种连接方式--要么通过代理连接，要么通过故意进入主服务器。

另一个问题是--任何对复制品新鲜度的检查都必须与你将要做的SELECT保持相同的联系。这是因为不同的连接可能会击中不同的副本。复制品不一定是同样新鲜的。(一个大的SELECT一个副本可以在很多方面减缓复制速度。)

Galera

由于您已经使用了3台服务器运行，所以不妨考虑切换到Percona (或MySQL 5.7 + Galera，或者使用Galera内置的MariaDB )。它在SELECT级别提供了一个“wsrep”方法，以确保数据是同步的。同时，它提供了更好的HA支持、自动故障转移和(可选)写入任何节点。

Answer 2

复制总是滞后的，即使数量很小，因为在提交事务之前，您的数据更改甚至不会写入二进制日志。然后，副本必须在二进制日志中下载这些事件，并将它们应用于副本实例。这通常是非常快的，但根据定义，对于每个事件，它都是>0滞后。

在应用程序提交自己的事务之前，您的应用程序也可以尝试读取它刚刚写入的数据。在这种情况下，复制不可能有相同的更改，因为它甚至还没有提交到源实例。

如果应用程序需要绝对最新的数据，不可能读取陈旧的数据，那么查询必须从源实例中读取，而不是从副本中读取。

但并不是每一个读取都需要读取如此严格的当前数据。您的应用程序中的每个查询对读取数据的敏感性都可能不同，这些数据有点落后于源。

我为Percona编写了一个演示文稿用MySQL和和进行读写拆分，它描述了不同级别复制延迟容忍的几种不同解决方案。