MySQL 复制不在 binlog 中运行更新

Question

我有许多运行 5.1.63 版的 mysql 服务器，本周早些时候在对从属服务器运行一些查询时，我注意到从属服务器上的一些数据本应使用主服务器上的更新语句删除。

我最初的想法是:

• 团队中的某个人正在更新从站，此后我反对
• 正在更新的列已更改

因此，我通过运行 mysql show status "table"查询进行了调查。这是针对每个服务器上的测试数据库运行的，以查看数据长度，在很多情况下，它向我展示了服务器之间的数据长度不同，但在观察数据时，我可以看到数据是相同，所以我无法使用此方法查看是否有任何差异，因为它似乎容易出错。

接下来，我为每个表运行了一个简单的(跨所有数据库)行计数，以确认行计数是相同的 - 它是。

然后我开始查看 bin 日志以进行复制。我可以在日志中清楚地看到本应运行的更新语句，但更新从未运行过。

我需要知道的是:

1. 复制中断了吗？我假设是
2. 如果我创建新的从属服务器，我会遇到同样的问题吗？
3. 如何找出服务器上问题的严重程度？

感谢任何帮助。

Answer 1

如果您使用的是基于语句的复制，那么由于 INSERT 语句构造不当，很容易在主从上得到不同的结果。

不带 ORDER BY 的 INSERT SELECT，或者 ORDER BY 可能留下不确定结果的地方将导致从服务器与主服务器分道扬镳。

来自 MySQL 站点 http://dev.mysql.com/doc/refman/5.1/en/insert-select.html

The order in which rows are returned by a SELECT statement with no ORDER BY clause is not determined. This means that, when using replication, there is no guarantee that such a SELECT returns rows in the same order on the master and the slave; this can lead to inconsistencies between them. To prevent this from occurring, you should always write INSERT ... SELECT statements that are to be replicated as INSERT ... SELECT ... ORDER BY column. The choice of column does not matter as long as the same order for returning the rows is enforced on both the master and the slave. See also Section 16.4.1.15, “Replication and LIMIT”.

如果发生这种情况，那么您的副本已经发生分歧，使它们恢复正常的唯一安全方法是从主数据库的最近备份中重建它们。最糟糕的是错误可能永远不会导致复制失败，但结果却不一致。通常，当 UPDATE 或 DELETE 语句影响的行数与 master 上的行数不同时，复制会失败，这很令人困惑，因为实际上导致错误的不是 UPDATE，而且我知道解决该问题的唯一方法是检查中的每个 INSERT 查询代码库!