MariaDB GTID current_pos vs slave_pos

Question

在使用MariaDB (目前为10.3)和GTID (全局事务ID)的标准主从设置中，尚不清楚是使用current_pos还是slave_pos。

来自文档的提示：

• 使用current_pos值会使从站根据gtid_current_pos系统变量设置其位置。从服务器接收主服务器给它的位置。
• 使用值slave_pos会导致从服务器使用gtid_slave_pos系统变量。使用此方法，从服务器将考虑到它自己的二进制日志中存在的事务。

我想我理解不同之处，但推荐的方案是什么？

在两者都存在的情况下，一个可能更适合一个用例，另一个可能更适合另一个用例，但是文档没有清楚地说明在这种情况下应该使用哪一个.

在非常常见的主从复制情况下，您会使用这些选项中的哪一个？

编辑2019-01-18:上下文

导致我问自己应该使用current_pos还是slave_pos的上下文：

最近，我使用APT将一些MariaDB集群(主从设置)从Debian10.1或10.2升级为MariaDB 10.3。

在实践中，我总是这样做：

1. 将奴隶(S)升级为10.3 (使用apt dist-升级)
2. 运行mysql_upgrade
3. 切换母版(使用Signal18复制管理器)
4. 升级旧主人(在上一步变成奴隶)
5. 切换母版以返回到原始配置。

然而，在最近的更新中，在运行mysql_upgrade命令后，我在Start上遇到了一些失败。它没有使用GTID当前位置找到绑定日志。

我相信，自从上一次主服务器切换以来，在主服务器上没有任何事务时，就会发生这种情况。在这种情况下，将GTID模式从current_pos切换到slave_pos解决了这个问题.

那么，我应该绝对使用slave_pos吗？但是，即使在这种情况下，复制管理器在切换后强制GTID模式为current_pos .

Answer 1

使用current_pos进行主切换。使用slave_pos进行常规复制。

current_pos - GTID域中的最后一次更改

slave_pos - SQL线程或并行工作人员在副本上应用的最后一次复制更改。

那么，想象一下您的普通副本(node2)切换到一个主。slave_pos不递增，因为更改是直接应用的，没有任何复制。然后，您需要重新配置集群，并使新的主服务器再次成为副本。

你会在node2上看到什么？

SHOW global variables like '%pos%'?

您将看到，slave_pos在切换时停止递增，current_pos正确地递增。

为了使node2成为副本，您必须在工作负载切换到新的主服务器后使用current_pos。

总结：

slave_pos

• 当您不假装写入副本时，请使用此选项
• 您不希望GTID的事务id部分在从服务器上增加
• 您正在向集群中添加一个新的从服务器，并且希望开始从GTID.slave_pos中复制

current_pos

• 当您要写入从服务器并要增加GTID事务id时，请使用此方法。
• 当主人需要成为一个新的奴隶

Answer 2

旧线程，但mysql_upgrade现在有一个no bin日志选项，需要在这种升级场景中使用。