MariaDB GTID current_pos 與 slave_pos
在使用 MariaDB（此時為 10.3）和 GTID（全域事務 ID）的標準主從設置中，不清楚是使用current_pos還是slave_pos。
文件中的提醒：
- 使用current_pos值會導致從站根據 gtid_current_pos 系統變數設置其位置。從伺服器佔據主伺服器給它的位置。
- 使用值slave_pos會導致從站改為使用 gtid_slave_pos 系統變數。使用這種方法，slave 會考慮其自己的二進制日誌中存在的事務。
我想我理解其中的區別，但推薦的選項是什麼？
如果兩者都存在，一個案例可能更好，另一個案例可能更好，但文件沒有明確說明在哪種情況下應該使用哪個……
對於非常常見的主從複製情況，您會使用以下哪個選項？
編輯 2019-01-18：上下文
導致我問自己是否應該使用 current_pos 或 slave_pos 的上下文：
我最近使用 APT 在 Debian Stretch 上將一些 MariaDB 集群（主從設置）從 MariaDB 10.1 或 10.2 升級到了 MariaDB 10.3。
在實踐中，我總是這樣進行：
- 將 slave(s) 升級到 10.3（使用 apt dist-upgrade）
- 執行 mysql_upgrade
- 切換主機（使用 Signal18 Replication-manager）
- 升級舊的主人（在上一步變成奴隸）
- 再次切換master回到原來的配置
然而，在最近的更新中，我在執行mysql_upgrade命令後在 Slave Start 遇到了一些故障。它沒有找到使用 GTID 目前位置的二進制日誌。
我相信，自上次主伺服器切換以來主伺服器上沒有事務時，就會發生這種情況。在這種情況下，將 GTID 模式從current_pos切換到slave_pos 可以解決問題…
那麼，我一定要使用slave_pos嗎？然而，即使在這種情況下，Replication-Manager 在切換後強制 GTID 模式為current_pos ……
用於
current_pos切換主控。用於slave_pos定期複製。
current_pos- GTID 域的最後一次更改
slave_pos- SQL 執行緒或併行工作人員在副本上應用的最後一次複製更改。因此，想像一下您的普通副本（node2）切換到主副本。
slave_pos不會遞增，因為更改會直接應用而無需任何複製。然後你需要重新配置集群，讓新的master再次成為replica。您將在 node2 上看到什麼？
SHOW global variables like '%pos%'?你會看到，
slave_pos在切換的那一刻停止增加，current_pos正確增加。為了使 node2 成為副本，您必須
current_pos在工作負載切換到新的 master 之後使用。總結：
slave_pos
- 當您不假裝寫入副本時使用此選項
- 您不希望 GTID 的事務 id 部分在從屬設備上增加
- 您正在向集群添加一個新的從屬伺服器，並希望從
GTID.slave_pos
current_pos
- 當您確實寫入從屬設備並想要增加 GTID 事務 ID 時使用它
- 當一個主人需要成為一個新的奴隸時
舊執行緒，但 mysql_upgrade 現在有一個 no bin log 選項，需要在這種升級場景中使用