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

Question

在数据库复制方面，全局事务标识符的用途是什么？为什么我们需要阻止服务器之间的并发？这种预防是如何实现的？

我试着阅读文档 http://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html但仍然无法理解。这可能听起来很基本，但如果有人能向我解释这些概念，我真的很感激。

Answer 1

全局事务ID的原因是允许MySQL从设备知道它是否已应用给定事务，以使主设备和从设备之间保持同步。如果连接断开，它还可以用于重新启动从站，再次知道时间点。在不使用GTID的情况下，必须根据给定二进制事务日志文件（bin日志）中的位置来控制复制。这比GTID方法更难管理。

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

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

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

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

还有另一个选项称为Master-Master复制，您可以在其中写入两个主服务器（每个主服务器充当另一个主服务器的从服务器），但这需要特殊配置以确保写入每个主服务器的数据是唯一的。管理比典型的主/从设置要复杂得多。

因此，防止对Slave的写入是您必须确保从应用程序中恢复典型复制过程才能正常运行的。从奴隶那里读书是好的，但你不应该写它。请注意，如果您将Slave用于读取，则Slave可以位于Master之后，因此最好对Master之后的事物执行查询（例如，在第二个或毫秒之前不重要的报告）。通过使公共应用程序用户成为Slave服务器的只读用户和Master的读写用户，可以确保不对Slave写入。

Answer 2

  

为什么我们需要阻止服务器之间的并发？

如果我正确理解了这个问题，那你就是在谈论一致性。如果是这样，答案是您需要在分布式系统中保持一致状态。例如，如果我的银行帐户信息在几个不同的服务器中复制，那么它们具有完全相同的余额是至关重要的。现在想象一下，我执行了多笔货币交易（存款/支出），并且每个交易都连接到不同的服务器：并发问题会导致我的帐户余额在每台服务器上不同，这是不可接受的。

  

这种预防是如何实现的？

使用主/从方法。在服务器中，您有一个服务器（主服务器）负责处理每个写入操作，这意味着必须仅由此服务器处理对数据库的修改。此主服务器的数据库被复制到所有其他服务器（从属服务器），这些服务器不允许修改数据库，但可用于读取数据库（例如SELECT操作）。知道只允许一台服务器修改数据库，就没有一致性问题。

  

全局事务标识符的用途是什么？

服务器之间的通信是异步的，并且从属服务器不需要始终与主服务器连接。因此，一旦从服务器与主服务器重新连接，它可能发现主数据库同时被修改，因此它必须更新其自己的数据库。现在的问题是了解主服务器执行的所有修改，这些修改是从服务器在之前的日期已执行的修改，以及尚未执行的修改。

GTID解决了这个问题：它们唯一地标识了主服务器执行的每个事务。现在，从服务器可以识别主服务器执行的所有事务，这些事务是之前没有见过的事务。