在在线服务器设置复制模式之前，了解复制的关键概念非常重要。这一节解释了这些概念，并且在尝试修改在线服务器的复制模式之前，需要阅读。

MySQL 复制模式的不同技术用于识别已记录的事务。以下列出了复制中使用的交易类型：

使用 GTIDs 可以利用 GTID 自动定位和自动故障转移，并使用 WAIT_FOR_EXECUTED_GTID_SET()、session_track_gtids 和 Performance Schema 表来监控复制事务（见 Section 29.12.11, “Performance Schema Replication Tables”）。

从源服务器运行的老版本 MySQL 中的交易日志可能不带任何特定的事件，但是在复制服务器的二进制日志中被记录后，它将被前缀为 Anonymous_gtid_log_event。

要在线更改复制模式，需要将 gtid_mode 和 enforce_gtid_consistency 变量使用具有足够权限的帐户设置全局系统变量；见 Section 7.1.9.1, “System Variable Privileges”。 gtid_mode 允许的值列表如下，按顺序列出，及其含义：

可以在同一个复制拓扑结构中使用使用匿名事务的服务器和使用 GTID 事务的服务器。例如，一个使用gtid_mode=ON的源服务器可以复制到一个使用gtid_mode=ON_PERMISSIVE的副本服务器。

从使用gtid_mode=ON的源服务器复制提供了使用 GTID 自动定位的能力，这可以通过SOURCE_AUTO_POSITION选项来配置的CHANGE REPLICATION SOURCE TO语句。拓扑结构的使用将影响是否可以启用自动定位或否，因为这个功能依赖于 GTIDs 并且与匿名事务不兼容。强烈建议在启用自动定位前确保拓扑结构中没有任何匿名事务；请参阅第19.1.4.2节，“在线启用 GTID 事务”。

下表显示了源和副本的gtid_mode和自动定位的有效组合。每个条目都有以下含义：

当前gtid_mode的值也会影响gtid_next。下表显示了服务器在不同gtid_mode和gtid_next组合中的行为。每个条目都有以下含义：

当不使用二进制日志记录时，并且gtid_next为AUTOMATIC，那么不生成GTID。