那篇文章简要提到的一件事是，每个 MariaDB 的 GTID 实现都可能在这种情况下导致问题。由于每个节点都维护着自己的 GTID 列表，并且 galera 事务没有自己的 id，因此相同的 GTID 可能不会指向每个服务器上的相同位置（请参阅本文）。
由于这个问题，如果没有 MariaDB 10.1，我不会尝试你正在做的事情。MariaDB 10.1.8 刚刚发布，是 10.1 系列的第一个 GA 版本。10.1 更改了 GTID 实现，因此 galera 事务使用自己的server_id（通过配置变量设置）。然后，您可以过滤从属服务器上的复制以仅复制 galera id。
要切换到不同的从服务器，您需要在旧从服务器上执行最后一个 GTID。gtid_slave_pos存储在 中，mysql.gtid_slave_pos但是mysql.*表不被复制。我不完全确定，我没有办法测试事务的原始 GTID 是否传递给其他从属 galera 节点（即，如果主集群的 galera server_id 为 1，从属集群的 galera server_id 为 2 并且MDBDR-01 获得一个 GTID 为 1-1-123 的从属事件，MDBDR-02 会将其记录为 1-1-123 或 1-2-456）。我猜它不会因为新的 GTID 实现应该更改 server_id，但您可以验证这一点。由于您可能无法从不同的从站 galera 节点获取最后执行的主 GTID，因此您可能需要从旧从站获取 GTID，除非您优雅地关闭旧从站，否则这可能是不可能的。您可能需要从新从站的 binlog 中最后执行的事务中找到 GTID，并尝试将其与 master 的 binlog 中的事务匹配。另外，如果你不使用sync_binlog = 1, binlog 不可靠，可能有点落后。
由于每个 galera 从节点可能不知道已执行的 GTID 并且不能跳过以前的 GTID 事件，SQL_SLAVE_SKIP_COUNTER因此如果您找到的 GTID 落后，您可能还必须玩弄才能到达正确的位置。
当您获得 GTID（或猜测）后，您将在新从属上设置复制，就像在原始从属上设置它一样。以下命令应该这样做：
SET GLOBAL gtid_slave_pos = "{最后执行的 GTID}";
将 MASTER 更改为 master_host="{Master Address}", master_port={Master Port}, master_user="{Replication User}", master_password={Replication Password}, master_use_gtid=slave_pos;
启动奴隶；
您还应该在旧从属设备上禁用复制，然后再重新启动它，这样错过的事件就不会被复制两次。
在执行的从 GTID 通过 galera 复制之前，这可能永远不会发生，这样的故障转移将是一个混乱的过程。