mysql - 为什么在 MySQL 复制中使用 GTID？

Question

说到数据库复制，全局事务标识符有什么用？为什么我们需要它来防止跨服务器的并发？这种预防到底是如何实现的？

我试着阅读文档 http://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html但还是没能看清楚。这听起来可能很基础，但如果有人能向我解释这些概念，我将不胜感激。

Answer 1

全局事务 ID 的原因是允许 MySQL slave 知道它是否应用了给定事务，以保持 Master 和 Slave 之间的同步。如果连接断开，它也可以用于重新启动从站，再次知道时间点。如果不使用 GTID，则必须根据给定二进制事务日志文件 (bin log) 中的位置来控制复制。这比 GTID 方法更难管理。

主服务器是唯一通常被写入的服务器，因此从服务器仅通过按顺序应用每个事务来重建主服务器的副本。

了解 MySQL 复制可以以 3 种模式之一运行也很重要:

• 基于语句:每个 SQL 语句都记录到二进制日志中，并作为语句复制到从属设备。在某些情况下，这在从站可能不明确，导致数据不完全匹配。 (大多数情况下，它适合普通用途)。
• 基于行:在这种模式下，MySQL 将实际数据更改复制到每个表，每行都有“之前”和“之后”的图片，这是完全准确的。这可能会导致更大的二进制日志，例如，如果您有批量更新查询，例如:UPDATE t1 SET c1 = 'a' WHERE c2 = 'b'。
• Mixed:在这种模式下，MySQL 将在 binlog 中混合使用基于语句和基于行的日志记录。

我只提到复制模式，因为在您引用的文档中提到，如果您使用 GTID，基于行是推荐的选项。

还有一种叫做Master-Master replication的选项，你可以写入两个master(每个作为另一个的slave)，但这需要一个特殊的配置来确保写入每个master的数据是唯一的。它比典型的主/从设置更难管理。

因此，为了使典型的复制过程正常运行，您必须从应用程序中确保防止写入从站。从一个 Slave 读取是可以的，但是你不应该写它。请注意，如果您将 Slave 用于读取，则 Slave 可能会落后于 Master，因此最好对可能落后于 Master 的事物执行查询(例如在秒或毫秒之前不重要的报告)。您可以通过使您的普通应用程序用户成为从服务器的只读用户和主服务器的读写用户来确保不写入从服务器。