第17章复制

要将主服务器配置为使用基于二进制日志文件位置的复制，必须确保启用二进制日志记录，并建立唯一的服务器ID。 如果尚未执行此操作，则需要重新启动服务器。

主服务器上需要二进制日志记录，因为二进制日志是将更改从主服务器复制到其从服务器的基础。 默认情况下启用二进制日志记录（ log_bin 系统变量设置为ON）。 该 --log-bin 选项告诉服务器用于二进制日志文件的基本名称。 建议您指定此选项以为二进制日志文件提供非默认基本名称，以便在主机名更改时，您可以轻松地继续使用相同的二进制日志文件名（请参见 第B.4.7节“已知” MySQL中的问题“ ）。

必须使用唯一的服务器ID配置复制拓扑中的每个服务器，您可以使用该 --server-id 选项 指定该服务器ID 。 此服务器标识用于标识复制拓扑中的各个服务器，并且必须是介于1和（2 ³² ）-1 之间的正整数 。 如果在主服务器上设置服务器ID为0，则拒绝来自从服务器的任何连接，如果在从服务器上设置服务器ID为0，则拒绝连接到主服务器。 除此之外，您可以选择如何组织和选择数字，只要每个服务器ID与复制拓扑中任何其他服务器使用的每个其他服务器ID不同即可。 该 server_id 系统变量默认设置为1。 可以使用此默认服务器ID启动服务器，但如果未明确指定服务器ID，则会发出信息性消息。

每个复制从站必须具有唯一的服务器ID。 如果尚未完成此操作，则从属设置的这一部分需要重新启动服务器。

如果尚未设置从属服务器ID，或者当前值与您为主服务器选择的值冲突，请关闭从属服务器并编辑 [mysqld] 配置文件 的 部分以指定唯一的服务器ID。 例如：

的[mysqld]
服务器ID = 2

进行更改后，重新启动服务器。

如果要设置多个从站，则每个从站必须具有唯一的非零 server-id 值，该值不同于主站和任何其他从站的 非零 值。

默认情况下，在所有服务器上启用二进制日志记录 从站不需要启用二进制日志记录以进行复制。 但是，从站上的二进制日志记录意味着从站的二进制日志可用于数据备份和崩溃恢复。

启用了二进制日志记录的从站也可以用作更复杂的复制拓扑的一部分。 例如，您可能希望使用此链式排列设置复制服务器：

A  - > B  - > C.

在这里， A 作为奴隶的主人 B ，并 B 作为奴隶的主人 C 。 为此， B 必须是主人 和 奴隶。 收到的更新 A 必须记录 B 到其二进制日志中，以便传递给 C 。 除二进制日志记录外，此复制拓扑还需要 --log-slave-updates 启用 该 选项。 使用此选项，从站将从主服务器接收并由从属SQL线程执行的更新写入从属自己的二进制日志。 --log-slave-updates 默认情况下启用 该 选项。

如果需要在从属服务器上禁用二进制日志记录或从属更新日志记录，则可以通过为从属服务器指定 --skip-log-bin 和 --skip-log-slave-updates 选项 来执行此操作 。

每个从站使用MySQL用户名和密码连接到主站，因此主站上必须有用户帐户，从站可以使用该帐户进行连接。 设置复制从站时 ，用户名由 命令 MASTER_USER 上 的 选项 指定 CHANGE MASTER TO 。 任何帐户都可以用于此操作，只要它已被授予 REPLICATION SLAVE 特权。 您可以选择为每个从站创建不同的帐户，也可以使用每个从站的相同帐户连接到主站。

虽然您不必专门为复制创建帐户，但您应该知道复制用户名和密码以纯文本形式存储在主信息存储库表中 mysql.slave_master_info （请参见 第17.2.4.2节“从属状态日志” ）。 因此，您可能希望创建一个仅具有复制过程权限的单独帐户，以最大程度地降低对其他帐户的危害。

要创建新帐户，请使用 CREATE USER 。 要授予此帐户复制所需的权限，请使用该 GRANT 语句。 如果您仅为复制目的创建帐户，则该帐户仅需要该 REPLICATION SLAVE 权限。 例如，要设置 repl 可以从 example.com 域中的 任何主机连接进行复制 的新用户，请 在主服务器上发出以下语句：

mysql> 
mysql>CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';

有关 操作用户帐户的语句的更多信息 ， 请参见 第13.7.1节“帐户管理语句” 。

要将从站配置为在正确的位置启动复制过程，您需要在其二进制日志中记下主站的当前坐标。

如果您计划关闭主服务器以创建数据快照，则可以选择跳过此过程，而是存储二进制日志索引文件的副本以及数据快照。 在这种情况下，主服务器会在重新启动时创建新的二进制日志文件。 因此，从属服务器必须启动复制过程的主二进制日志坐标是该新文件的开始，该文件是在复制的二进制日志索引文件中列出的文件之后的主服务器上的下一个二进制日志文件。

要获取主二进制日志坐标，请按照下列步骤操作：

现在，您可以获得所需的信息，以使从服务器能够从正确的位置开始读取二进制日志以开始复制。

下一步取决于您是否在主服务器上有现有数据。 选择以下选项之一：

如果主数据库包含现有数据，则必须将此数据复制到每个从站。 有多种方法可以从master数据库转储数据。 以下部分描述了可能的选项。

要选择转储数据库的适当方法，请在以下选项之间进行选择：

外壳> mysqldump --all-databases --master-data > dbdump.db

以下部分描述了如何设置从站。 在继续之前，请确保您拥有：

接下来的步骤取决于您是否有现有数据导入到从属设备。 有关 更多信息 ， 请参见 第17.1.2.5节“为数据快照选择方法” 。 选择以下之一：

外壳> mysql -h master < fulldb.dump

要将从站设置为与主站通信以进行复制，请使用必要的连接信息配置从站。 为此，请在从站上执行以下语句，将选项值替换为与系统相关的实际值：

mysql> CHANGE MASTER TO
    - >      
    - >      
    - >      
    - >      
    - >     MASTER_HOST='master_host_name',MASTER_USER='replication_user_name',MASTER_PASSWORD='replication_password',MASTER_LOG_FILE='recorded_log_file_name',MASTER_LOG_POS=recorded_log_position;

该 CHANGE MASTER TO 声明还有其他选择。 例如，可以使用SSL设置安全复制。 有关选项的完整列表以及有关字符串值选项的最大允许长度的信息，请参见 第13.4.2.1节“将语法更改为语法” 。

您可以将另一个从站添加到现有复制配置，而无需停止主站。 为此，您可以通过复制现有从站的数据目录并为新从站提供不同的服务器ID（由用户指定）和服务器UUID（在启动时生成）来设置新从站。

要复制现有的从属：

全局事务标识符（GTID）是创建的唯一标识符，并与在源服务器（主服务器）上提交的每个事务相关联。 此标识符不仅对其发起的服务器是唯一的，而且在给定复制拓扑中的所有服务器上都是唯一的。

GTID分配区分在主服务器上提交的客户端事务和在从服务器上复制的复制事务。 在主服务器上提交客户端事务时，如果事务已写入二进制日志，则会为其分配新的GTID。 保证客户交易具有单调增加的GTID，而生成的数字之间没有间隙。 如果未将客户端事务写入二进制日志（例如，因为事务已被过滤掉，或者事务是只读的），则不会在源服务器上为其分配GTID。

复制的事务保留与分配给源服务器上的事务相同的GTID。 GTID在复制事务开始执行之前存在，并且即使复制的事务未写入从服务器上的二进制日志，或者在从服务器上过滤掉，也会持久存在。 MySQL系统表 mysql.gtid_executed 用于保存MySQL服务器上应用的所有事务的已分配GTID，但存储在当前活动的二进制日志文件中的事务除外。

GTID的自动跳过功能意味着在主服务器上提交的事务可以在从服务器上应用不超过一次，这有助于保证一致性。 一旦在给定服务器上提交了具有给定GTID的事务，则该服务器将忽略使用相同GTID执行后续事务的任何尝试。 不会引发错误，并且不会执行事务中的语句。

如果具有给定GTID的事务已开始在服务器上执行但尚未提交或回滚，则任何在具有相同GTID的服务器上启动并发事务的尝试都将被阻止。 服务器既不开始执行并发事务也不将控制权返回给客户端。 一旦第一次尝试事务提交或回滚，就可以继续在同一GTID上阻塞的并发会话。 如果第一次尝试回滚，则一个并发会话继续尝试该事务，并且在同一GTID上阻塞的任何其他并发会话仍然被阻止。 如果第一次尝试提交，则所有并发会话都将被阻止，并自动跳过事务的所有语句。

GTID表示为一对坐标，用冒号字符（ : ） 分隔 ，如下所示：

GTID = source_id：transaction_id

该 source_id 标识的源服务器。 通常，主人 server_uuid 用于此目的。 这 transaction_id 是一个序列号，由在主服务器上提交事务的顺序确定。 例如，要提交的第一个事务具有 1 其 transaction_id ，并且被分配一个相同的始发服务器上被提交第十交易 transaction_id 的 10 。 事务不可能 0 在GTID中具有序列号。 例如，最初在具有UUID的服务器上提交的第二十三个事务 3E11FA47-71CA-11E1-9E33-C80AA9429562 具有以下GTID：

3E11FA47-71CA-11E1-9E33-C80AA9429562：23

事务的GTID显示在 mysqlbinlog 的输出中 ，例如，它用于标识性能模式复制状态表中的单个事务 replication_applier_status_by_worker 。 gtid_next 系统变量（ @@GLOBAL.gtid_next ） 存储的值 是单个GTID。

3E11FA47-71CA-11E1-9E33-C80AA9429562：1-5

3E11FA47-71CA-11E1-9E33-C80AA9429562：1-3：11：47-49

2174B383-5441-11E8-B90A-C80AA9429562：1-3,24DA167-0C0C-11E8-8442-00059A3C7B00：1-19

gtid_set：
     uuid_set[，uuid_set] ......
    | “”

uuid_set：
     uuid：interval[：interval] ...

uuid：
     hhhhhhhh- hhhh- hhhh- hhhh-hhhhhhhhhhhh

h：
    [0-9 | AF]

interval：
     n[ - n]

    （n> = 1）

CREATE TABLE gtid_executed（
    source_uuid CHAR（36）NOT NULL，
    interval_start BIGINT（20）NOT NULL，
    interval_end BIGINT（20）NOT NULL，                                                                                                                                                                                  
    PRIMARY KEY（source_uuid，interval_start）
）      

+ -------------------------------------- + ---------- ------ + -------------- +
| source_uuid | interval_start | interval_end |
| -------------------------------------- + ---------- ------ + -------------- |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 37 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38 | 38 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39 | 39 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40 | 40 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41 | 41 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42 | 42 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43 | 43 |
...

+ -------------------------------------- + ---------- ------ + -------------- +
| source_uuid | interval_start | interval_end |
| -------------------------------------- + ---------- ------ + -------------- |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 43 |
...

MySQL的> SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
*************************** 1。排******************** *******
          THREAD_ID：26
               名称：thread / sql / compress_gtid_table
               类型：FOREGROUND
     PROCESSLIST_ID：1
   PROCESSLIST_USER：NULL
   PROCESSLIST_HOST：NULL
     PROCESSLIST_DB：NULL
PROCESSLIST_COMMAND：守护进程
   PROCESSLIST_TIME：1509
  PROCESSLIST_STATE：暂停
   PROCESSLIST_INFO：NULL
   PARENT_THREAD_ID：1
               角色：空
       仪表：是的
            历史：是的
    CONNECTION_TYPE：NULL
       THREAD_OS_ID：18677

GTID的生命周期包括以下步骤：

在主服务器上完全过滤掉的客户端事务未分配GTID，因此它们不会添加到 gtid_executed 系统变量中 的事务集中，也不会添加到 mysql.gtid_executed 表中。 但是，在从属设备上完全过滤掉的复制事务的GTID是持久的。 如果在从属设备上启用了二进制日志记录，则过滤掉的事务将作为a Gtid_log_event 后跟仅包含 BEGIN 和 COMMIT 语句 的空事务 写入二进制日志 。 如果禁用二进制日志记录，则已过滤掉的事务的GTID将写入 mysql.gtid_executed 表中。 为过滤掉的事务保留GTID确保了 mysql.gtid_executed gtid_executed 可以压缩 表和 系统变量中 的GTID集 。 它还确保如果从站重新连接到主站，则不会再次检索过滤掉的事务，如 第17.1.3.3节“GTID自动定位”中所述 。

在多线程复制从属（带 slave_parallel_workers > 0 ）上，可以并行应用事务，因此复制的事务可以无序提交（除非 slave_preserve_commit_order=1 已设置）。 当发生这种情况时， gtid_executed 系统变量中的GTID 集 将包含多个GTID范围，它们之间存在间隙。 （在主机或单线程复制从机上，将会有单调增加的GTID，数字之间没有间隙。）多线程复制从机上的间隙仅发生在最近应用的事务中，并在复制过程中填充。 使用时干净地停止复制线程 STOP SLAVE 语句，应用正在进行的事务以填补空白。如果发生关闭（如服务器故障或使用 KILL 语句停止复制线程），则可能会出现间隙。

GTID替换先前所需的文件偏移对，以确定启动，停止或恢复主设备和从设备之间的数据流的点。 当使用GTID时，从属设备需要与主设备同步的所有信息都直接从复制数据流中获取。

要使用基于GTID的复制启动从属服务器，请不要 在 用于指示从属服务器从给定主服务器进行复制 的 语句中 包含 MASTER_LOG_FILE 或 MASTER_LOG_POS 选项 CHANGE MASTER TO 。 这些选项指定日志文件的名称和文件中的起始位置，但是对于GTID，从站不需要此非本地数据。 相反，您需要启用该 MASTER_AUTO_POSITION 选项。 有关使用基于GTID的复制配置和启动主站和从站的完整说明，请参见 第17.1.3.4节“ 使用GTID 设置复制” 。

MASTER_AUTO_POSITION 默认情况下禁用 该 选项。 如果在从属设备上启用了多源复制，则需要为每个适用的复制通道设置选项。 禁用 MASTER_AUTO_POSITION 再次选项使从恢复到基于文件的复制，在这种情况下，你还必须指定的一个或两个 MASTER_LOG_FILE 或 MASTER_LOG_POS 选项。

当复制从站启用GTID（ GTID_MODE=ON ， ON_PERMISSIVE, 或 OFF_PERMISSIVE ）并 MASTER_AUTO_POSITION 启用 该 选项时，将激活自动定位以连接到主站。 必须 GTID_MODE=ON 设置 主服务器 才能使连接成功。 在初始握手中，从站发送一个GTID集，其中包含已经收到，已提交或两者都已完成的事务。 此GTID集等于 gtid_executed 系统变量（ @@GLOBAL.gtid_executed ）中GTID集的并集，以及性能模式 replication_connection_status 表中 记录 为接收事务（语句结果 SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status ） 的GTID集 。

主设备通过发送其二进制日志中记录的所有事务来响应，其GTID不包括在从设备发送的GTID集中。 此交换确保主服务器仅使用从服务器尚未接收或提交的GTID发送事务。 如果从属设备从多个主设备接收事务，如菱形拓扑结构，则自动跳过功能可确保事务不会应用两次。

如果主服务器应发送的任何事务已从主服务器的二进制日志中清除，或 gtid_purged 通过其他方法 添加到 系统变量中 的GTID集中 ，则主服务器将错误 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS 发送 给从服务器，并且复制不会开始。 将识别丢失的清除事务的GTID，并在警告消息 ER_FOUND_MISSING_GTIDS 中的主控错误日志中 列出 。 从站无法自动从此错误中恢复，因为已清除了赶上主站所需的部分事务历史记录。 试图重新连接没有 MASTER_AUTO_POSITION 启用选项只会导致从站上清除的事务丢失。 从这种情况中恢复的正确方法是从 服务器 从另一个源 复制 ER_FOUND_MISSING_GTIDS 消息中 列出的丢失事务 ，或者从更新的备份创建的新从服务器替换从服务器。 考虑修改主服务器上的二进制日志有效期（ binlog_expire_logs_seconds ）以确保不再发生这种情况。

如果在事务交换期间发现从服务器已经在GTID中接收或提交了与主服务器UUID的事务，但主服务器本身没有它们的记录，则主服务器将错误 ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER 发送 给从服务器并且复制不会开始。 如果没有的主人可能会发生这种情况 sync_binlog=1 设置遇到电源故障或操作系统崩溃，并丢失尚未同步到二进制日志文件但已由从属设备接收的已提交事务。 如果任何客户端在重新启动后在主服务器上提交事务，则主服务器和从服务器可以发散，这可能导致主服务器和从服务器对不同的事务使用相同的GTID。 从这种情况中恢复的正确方法是手动检查主设备和从设备是否已发散。 如果现在对不同的事务使用相同的GTID，则需要根据需要对各个事务执行手动冲突解决，或者从复制拓扑中删除主服务器或从服务器。

本节介绍在MySQL 8.0中配置和启动基于GTID的复制的过程。 这是一个 “ 冷启动 ” 过程，它假定您是第一次启动复制主服务器，或者可以停止它; 有关使用来自正在运行的主服务器的GTID供应复制从服务器的信息，请参见 第17.1.3.5节“使用GTID进行故障转移和扩展” 。 有关在线更改服务器上的GTID模式的信息，请参见 第17.1.5节“在线服务器上更改复制模式” 。

此启动过程中最简单的GTID复制拓扑的关键步骤（包括一个主服务器和一个从服务器）如​​下所示：

在以下示例中，使用MySQL的基于二进制日志位置的复制协议，两个服务器已作为主服务器和从服务器运行。 如果 要从 新服务器启动，请参见 第17.1.2.3节“为复制创建用户” 以获取有关为复制连接添加特定用户 的信息，以及有关设置 变量的 信息 ，请参见 第17.1.2.1 节“设置复制主配置” 。 server_id 。 以下示例显示如何 在服务器的选项文件中 存储 mysqld 启动选项， 有关详细信息 ，请参见 第4.2.2.2节“使用选项文件” 。 或者，您可以在运行 mysqld 时使用启动选项 。

以下大多数步骤都需要使用MySQL root 帐户或具有该 SUPER 权限的 其他MySQL用户帐户 。 mysqladmin shutdown 需要 SUPER 特权或 SHUTDOWN 特权。

第1步：同步服务器。  只有在不使用GTID的情况下复制已经复制的服务器时，才需要执行此步骤。 对于新服务器，请继续执行步骤3. 通过发出以下命令，通过在每台服务器上 设置 read_only 系统变量， 使服务器成为只读 ON ：

MySQL的> SET @@GLOBAL.read_only = ON;

等待所有正在进行的事务提交或回滚。 然后，让奴隶赶上主人。 在继续之前确保从站已处理所有更新非常重要 。

如果将二进制日志用于复制以外的任何其他日志，例如进行即时备份和还原，请等到不需要包含没有GTID的事务的旧二进制日志。 理想情况下，等待服务器清除所有二进制日志，并等待任何现有备份过期。

第2步：停止两台服务器。  使用 mysqladmin 停止每个服务器 ，如下所示， username 具有足够权限关闭服务器的MySQL用户的用户名 在哪里 ：

外壳> mysqladmin -uusername -p shutdown

然后在提示符下提供此用户的密码。

步骤3：启用两台启用了GTID的服务器。  要启用基于GTID的复制，必须通过将 gtid_mode 变量 设置为启用GTID模式来启动每个服务器 ON ，并 enforce_gtid_consistency 启用变量以确保仅记录对基于GTID的复制安全的语句。 例如：

gtid_mode = ON
执行-GTID一致性=真

此外， --skip-slave-start 在配置从站设置之前 ，应该使用该 选项 启动从 站。 有关GTID相关选项和变量的更多信息，请参见 第17.1.6.5节“全局事务ID选项和变量” 。

在使用 mysql.gtid_executed表 时，不必强制启用二进制日志记录以使用GTID 。 主人必须始终启用二进制日志记录才能进行复制。 但是，从服务器可以使用GTID但不使用二进制日志记录。 如果需要在从属服务器上禁用二进制日志记录，可以通过指定从属服务器 --skip-log-bin 和 --skip-log-slave-updates 选项 来执行此操作 。

步骤4：配置从站以使用基于GTID的自动定位。  告诉从属设备使用具有基于GTID的事务的主服务器作为复制数据源，并使用基于GTID的自动定位而不是基于文件的定位。 CHANGE MASTER TO 在奴隶上 发出 声明，包括 MASTER_AUTO_POSITION 声明中 的 选项，告诉奴隶主人的交易是由GTID识别的。

您可能还需要为主服务器的主机名和端口号提供适当的值，以及复制用户帐户的用户名和密码，从服务器可以使用该帐户连接到主服务器; 如果已经在步骤1之前设置了这些，并且不需要进行进一步的更改，则可以从此处显示的语句中安全地省略相应的选项。

的MySQL> CHANGE MASTER TO
     >      
     >      
     >      
     >      
     >     MASTER_HOST = host,MASTER_PORT = port,MASTER_USER = user,MASTER_PASSWORD = password,MASTER_AUTO_POSITION = 1;

无论是 MASTER_LOG_FILE 选择还是 MASTER_LOG_POS 选择可能与使用 MASTER_AUTO_POSITION 等于1尝试这样做会导致 CHANGE MASTER TO 失败，错误陈述。

第5步：进行新备份。  由于您已启用GTID，因此在启用GTID之前创建的现有备份现在无法在这些服务器上使用。 此时进行新备份，这样您就不会没有可用的备份。

例如，您可以 FLUSH LOGS 在要进行备份的服务器上 执行 。 然后显式地进行备份或等待您可能已设置的任何定期备份例程的下一次迭代。

步骤6：启动从站并禁用只读模式。  像这样启动奴隶：

MySQL的> START SLAVE;

仅当您在步骤1中将服务器配置为只读时，才需要执行以下步骤。要允许服务器再次开始接受更新，请发出以下语句：

MySQL的> SET @@GLOBAL.read_only = OFF;

现在应该正在运行基于GTID的复制，您可以像以前一样在主服务器上开始（或恢复）活动。 第17.1.3.5节“使用GTID进行故障转移和扩展” 讨论了在使用GTID时创建新的从服务器。

将MySQL Replication与全局事务标识符（GTID）一起使用时，有许多技术可用于配置新的从属设备，然后可以将其用于扩展，并根据故障转移的需要提升为主设备。 本节介绍以下技术：

全局事务标识符已添加到MySQL Replication中，以简化复制数据流和特别是故障转移活动的一般管理。 每个标识符唯一地标识一起构成事务的一组二进制日志事件。 GTID在将更改应用于数据库时起着关键作用：服务器自动跳过具有服务器识别为之前已处理的标识符的任何事务。 此行为对于自动复制定位和正确的故障转移至关重要。

在二进制日志中捕获标识符和包括给定事务的事件集之间的映射。 当使用来自另一个现有服务器的数据配置新服务器时，这会带来一些挑战。 要重现在新服务器上设置的标识符，必须将标识符从旧服务器复制到新服务器，并保留标识符与实际事件之间的关系。 这对于恢复立即可用作故障转移或切换成为新主服务器的候选服务器是必要的。

简单的复制。  在新服务器上重现所有标识符和事务的最简单方法是使新服务器成为具有完整执行历史记录的主服务器的从属服务器，并在两个服务器上启用全局事务标识符。 有关 更多信息 ， 请参见 第17.1.3.4节“使用GTID设置复制” 。

启动复制后，新服务器将从主服务器复制整个二进制日志，从而获取有关所有GTID的所有信息。

这种方法简单有效，但要求从设备从主设备读取二进制日志; 新的从服务器有时需要相对较长的时间来赶上主服务器，因此这种方法不适合快速故障转移或从备份恢复。 本节介绍如何通过将二进制日志文件复制到新服务器来避免从主服务器获取所有执行历史记录。

将数据和事务复制到从属服务器。  当源服务器先前处理了大量事务时，执行整个事务历史记录可能非常耗时，这可能是设置新复制从站时的主要瓶颈。 为了消除此要求，可以将源服务器包含的数据集快照，二进制日志和全局事务信息导入新从属服务器。 源服务器可以是主服务器，也可以是从服务器，但必须确保源在复制数据之前已处理了所有必需的事务。

这种方法有几种变体，区别在于数据转储和二进制日志中的事务转移到从属的方式，如下所述：

这种方法的优点是几乎可以立即使用新的服务器; 只有那些在重放快照或转储文件时提交的事务仍需要从现有主服务器获取。 这意味着从属设备的可用性不是即时的，但是从属设备只需要相对较短的时间来赶上这些剩余的事务。

事先将二进制日志复制到目标服务器通常比从主服务器实时读取整个事务执行历史记录更快。 但是，由于大小或其他考虑因素，在需要时将这些文件移动到目标可能并不总是可行的。 本节中讨论的另外两种配置新从站的方法使用其他方法将有关事务的信息传输到新从站。

注入空交易。  master的全局 gtid_executed 变量包含在 master上 执行的所有事务的集合。 在拍摄快照以配置新服务器时，您可以改为记录 gtid_executed 拍摄快照的服务器上的 内容，而不是复制二进制日志 。 在将新服务器添加到复制链之前，只需在新服务器上为主服务器中包含的每个事务标识符提交一个空事务 gtid_executed ，如下所示：

SET GTID_NEXT ='aaa-bbb-ccc-ddd：N';

开始;
承诺;

SET GTID_NEXT ='AUTOMATIC';

使用空事务以这种方式恢复所有事务标识符后，必须刷新并清除slave的二进制日志，如此处所示，其中 N 是当前二进制日志文件名的非零后缀：

FLUSH LOGS;
PURGE BINARY登录N' master-bin.00000 ';

您应该执行此操作以防止此服务器在以后将其提升为主服务器时使用虚假事务充斥复制流。 （该 FLUSH LOGS 语句强制创建新的二进制日志文件; PURGE BINARY LOGS 清除空事务，但保留其标识符。）

此方法创建一个本质上是快照的服务器，但由于其二进制日志历史记录与复制流的历史记录收敛（即，当它赶上主服务器或主服务器时），因此能够及时成为主服务器。 该结果与使用剩余供应方法获得的结果类似，我们将在接下来的几段中讨论。

使用gtid_purged排除交易。  master的全局 gtid_purged 变量包含从主服务器的二进制日志中清除的所有事务的集合。 与前面讨论的方法一样（请参阅 注入空事务 ），您可以记录 gtid_executed 从中获取快照的服务器上 的值 （而不是将二进制日志复制到新服务器）。 与以前的方法不同，不需要提交空事务（或发布 PURGE BINARY LOGS ）; 相反，您可以 gtid_purged 根据 gtid_executed 从中获取备份或快照的服务器 上的值直接在从站上 进行设置 。

与使用空事务的方法一样，此方法创建一个功能上为快照的服务器，但由于其二进制日志历史记录与复制主服务器或组的历史记录收敛，因此能够及时成为主服务器。

恢复GTID模式从站。  在遇到错误的基于GTID的复制设置中还原从站时，注入空事务可能无法解决问题，因为事件没有GTID。

使用 mysqlbinlog 查找下一个事务，这可能是事件发生后下一个日志文件中的第一个事务。 将所有内容复制到该 COMMIT 事务，确保包含该事务 SET @@SESSION.gtid_next 。 即使您不使用基于行的复制，仍可以在命令行客户端中运行二进制日志行事件。

停止从属并运行您复制的事务。 该 mysqlbinlog可以 输出设置的分隔符 /*!*/; ，所以将其设置回：

MySQL的> DELIMITER ;

自动从正确的位置重新启动复制：

mysql> SET GTID_NEXT=automatic;
mysql> RESET SLAVE;
mysql>START SLAVE;

由于基于GTID的复制依赖于事务，因此在使用时不支持MySQL中可用的某些功能。 本节提供有关使用GTID进行复制的限制和限制的信息。

涉及非事务存储引擎的更新。  使用GTID时，使用非事务性存储引擎对表进行更新（例如， MyISAM 无法在与使用事务存储引擎（例如）的表更新相同的语句或事务中） InnoDB 。

这种限制是由于对使用非事务性存储引擎的表的更新与对同一事务中使用事务存储引擎的表的更新混合的事实可能导致将多个GTID分配给同一事务。

当主设备和从设备使用不同的存储引擎用于同一个表的相应版本时，也会发生这样的问题，其中一个存储引擎是事务性的而另一个不是。 还要注意，定义为在非事务性表上运行的触发器可能是导致这些问题的原因。

在刚刚提到的任何一种情况下，事务和GTID之间的一对一对应关系被破坏，结果是基于GTID的复制无法正常运行。

CREATE TABLE ... SELECT语句。  CREATE TABLE ... SELECT 使用基于GTID的复制时不允许使用语句。 当 binlog_format 设置为STATEMENT时， CREATE TABLE ... SELECT 语句在二进制日志中记录为具有一个GTID的一个事务，但如果使用ROW格式，则该语句将记录为具有两个GTID的两个事务。 如果主服务器使用STATEMENT格式而从服务器使用ROW格式， CREATE TABLE ... SELECT 则从服务器 将无法正确处理事务，因此 GTID不允许使用 该 语句来阻止此情况。

临时表。  何时 binlog_format 设置为 STATEMENT ， CREATE TEMPORARY TABLE 并且 DROP TEMPORARY TABLE 当在服务器上使用GTID时（即，当 enforce_gtid_consistency 系统变量设置为 ON ） 时，不能在事务，过程，函数和触发器内使用语句 。 当GTID正在使用时，它们可以在这些上下文之外使用，前提是 autocommit=1 已设置。 从MySQL 8.0.13开始，何时 binlog_format 设置为 ROW 或 MIXED ， CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 在使用GTID时，允许在事务，过程，函数或触发器内部使用语句。 这些语句不会写入二进制日志，因此不会复制到从属语句。 使用基于行的复制意味着从属服务器保持同步，而无需复制临时表。 如果从事务中删除这些语句导致空事务，则事务不会写入二进制日志。

防止执行不受支持的语句。  要防止执行会导致基于GTID的复制失败的语句，必须 --enforce-gtid-consistency 在启用GTID时 使用该 选项 启动所有服务器 。 这会导致本节前面讨论的任何类型的语句失败并显示错误。

请注意， --enforce-gtid-consistency 仅在对语句进行二进制日志记录时才会生效。 如果在服务器上禁用了二进制日志记录，或者由于过滤器删除了语句而未将语句写入二进制日志，则不会对未记录的语句检查或强制执行GTID一致性。

有关启用GTID时其他所需启动选项的信息，请参见 第17.1.3.4节“使用GTID设置复制” 。

跳过交易。  sql_slave_skip_counter 使用GTID时不支持。 如果您需要跳过事务，请使用master的 gtid_executed 变量 值 ; 有关详细信息， 请参阅 注入空事务 。

忽略服务器。  CHANGE MASTER TO 使用GTID时，不推荐使用 该 语句 的IGNORE_SERVER_IDS选项 ，因为已经应用的事务会自动被忽略。 在启动基于GTID的复制之前，请检查并清除之前在相关服务器上设置的所有忽略的服务器ID列表。 SHOW SLAVE STATUS 可以为各个通道发出 的 语句显示已忽略的服务器ID列表（如果有）。 如果没有列表，则该 Replicate_Ignore_Server_Ids 字段为空。

GTID模式和mysqldump。  如果 目标服务器的二进制日志中没有GTID ，则可以将使用 mysqldump 创建的转储导入 到启用了GTID模式的MySQL服务器中。

GTID模式和mysql_upgrade。  在MySQL 8.0.16之前，当服务器运行时使用全局事务标识符（GTID）enabled（ gtid_mode=ON ）时，不要通过 mysql_upgrade 启用二进制日志记录 （该 --write-binlog 选项）。 从MySQL 8.0.16开始，服务器执行整个MySQL升级过程，但在升级过程中禁用二进制日志记录，因此没有问题。

MySQL包含一些内置（本机）函数，用于基于GTID的复制。 这些功能如下：

有关这些函数的详细信息，请参见 第12.18节“与全局事务标识符（GTID）一起使用的函数” 。

您可以定义自己的存储函数以使用GTID。 有关定义存储函数的信息，请参见 第24章， 存储对象 。 以下示例显示了可以基于内置 函数 GTID_SUBSET() 和 GTID_SUBTRACT() 函数 创建的一些有用的存储 函数。

请注意，在这些存储函数中，delimiter命令已用于将MySQL语句分隔符更改为垂直条，如下所示：

mysql>分隔符|

所有这些函数都将GTID集的字符串表示作为参数，因此GTID集在与它们一起使用时必须始终引用。

如果两个GTID集是相同的集，则此函数返回非零（true），即使它们没有以相同的方式格式化。

创建函数GTID_IS_EQUAL（gtid_set_1 LONGTEXT，gtid_set_2 LONGTEXT）
退货INT
  返回GTID_SUBSET（gtid_set_1，gtid_set_2）和GTID_SUBSET（gtid_set_2，gtid_set_1）|

如果两个GTID集不相交，则此函数返回非零值（true）。

创建函数GTID_IS_DISJOINT（gtid_set_1 LONGTEXT，gtid_set_2 LONGTEXT）
退货INT
  返回GTID_SUBSET（gtid_set_1，GTID_SUBTRACT（gtid_set_1，gtid_set_2））|

如果两个GTID集是不相交的，则此函数返回非零（true），并且 sum 是两个集合的并集。

创建函数GTID_IS_DISJOINT_UNION（gtid_set_1 LONGTEXT，gtid_set_2 LONGTEXT，总和LONGTEXT）
退货INT
  返回GTID_IS_EQUAL（GTID_SUBTRACT（sum，gtid_set_1），gtid_set_2）AND
         GTID_IS_EQUAL（GTID_SUBTRACT（sum，gtid_set_2），gtid_set_1）|

此函数以全部大写形式返回GTID集的规范化形式，没有空格且没有重复。 UUID按字母顺序排列，间隔按数字顺序排列。

创建功能GTID_NORMALIZE（g LONGTEXT）
退货长期
返回GTID_SUBTRACT（g，''）|

此函数返回两个GTID集的并集。

创建函数GTID_UNION（gtid_set_1 LONGTEXT，gtid_set_2 LONGTEXT）
退货长期
  返回GTID_NORMALIZE（CONCAT（gtid_set_1，'，'，gtid_set_2））|

此函数返回两个GTID集的交集。

创建函数GTID_INTERSECTION（gtid_set_1 LONGTEXT，gtid_set_2 LONGTEXT）
退货长期
  返回GTID_SUBTRACT（gtid_set_1，GTID_SUBTRACT（gtid_set_1，gtid_set_2））|

此函数返回两个GTID集之间的对称差异，即存在 gtid_set_1 但不 存在的GTID gtid_set_2 ，以及存在 gtid_set_2 但不 存在的GTID gtid_set_1 。

创建函数GTID_SYMMETRIC_DIFFERENCE（gtid_set_1 LONGTEXT，gtid_set_2 LONGTEXT）
退货长期
  返回GTID_SUBTRACT（CONCAT（gtid_set_1，'，'，gtid_set_2），GTID_INTERSECTION（gtid_set_1，gtid_set_2））|

此函数从GTID中删除指定原点的所有GTID，并返回剩余的GTID（如果有）。 UUID是发起事务的服务器使用的标识符，通常是 server_uuid 值。

创建函数GTID_SUBTRACT_UUID（gtid_set LONGTEXT，uuid TEXT）
退货长期
  返回GTID_SUBTRACT（gtid_set，CONCAT（UUID，'：1-'，（1 << 63） -  2））|

此函数反转先前列出的函数，以仅返回来自具有指定标识符（UUID）的服务器的GTID集中的那些GTID。

创建函数GTID_INTERSECTION_WITH_UUID（gtid_set LONGTEXT，uuid TEXT）
退货长期
  返回GTID_SUBTRACT（gtid_set，GTID_SUBTRACT_UUID（gtid_set，uuid））|

SELECT GTID_SUBSET（master_gtid_executed，slave_gtid_executed）

SELECT GTID_SUBTRACT（master_gtid_executed，slave_gtid_executed）

SELECT GTID_UNION（RECEIVED_TRANSACTION_SET，@@ GLOBAL.gtid_executed） 
    来自performance_schema.replication_connection_status 
    WHERE channel_name ='name';

SELECT GTID_SUBTRACT_UUID（@@ GLOBAL.gtid_executed，server_uuid_of_master）;

SELECT GTID_SUBTRACT_UUID（GTID_SUBTRACT_UUID（@@ GLOBAL.gtid_executed，
                                             server_uuid_of_master_1）
                                             server_uuid_of_master_2）;

SELECT GTID_INTERSECTION_WITH_UUID（@@ GLOBAL.gtid_executed，my_server_uuid）;

    $ master2_gtid_executed：=
      master2> SELECT @@ GLOBAL.gtid_executed;
    $ master2_server_uuid：=
      master2> SELECT @@ GLOBAL.server_uuid;
    $ slave_gtid_executed：=
      奴隶> SELECT @@ GLOBAL.gtid_executed;

SELECT GTID_SUBSET（GTID_INTERSECTION_WITH_UUID（$ master2_gtid_executed，
                                               $ master2_server_uuid）
                                               $ slave_gtid_executed）;

MySQL多源复制使复制从站可以同时从多个源接收事务。 多源复制可用于将多个服务器备份到单个服务器，合并表分片，以及将来自多个服务器的数据合并到单个服务器。 应用事务时，多源复制不会实现任何冲突检测或解决，如果需要，这些任务将留给应用程序。 在多源复制拓扑中，从属服务器为每个应从其接收事务的主服务器创建复制通道。 请参见 第17.2.3节“复制通道” 。 以下部分介绍如何设置多源复制。

本节提供有关如何为多源复制配置主站和从站以及如何启动，停止和重置多源从站的教程。

STOP SLAVE;
SET GLOBAL master_info_repository = 'TABLE';
SET GLOBAL relay_log_info_repository = 'TABLE';

CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='rpl', MASTER_PORT=3451, MASTER_PASSWORD='', \
MASTER_AUTO_POSITION = 1 FOR CHANNEL 'master-1';

CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='rpl', MASTER_PORT=3451, MASTER_PASSWORD='' \
MASTER_LOG_FILE='master1-bin.000006', MASTER_LOG_POS=628 FOR CHANNEL 'master-1';

要监视复制通道的状态，需要以下选项：

MySQL的> SELECT * FROM replication_connection_status\G;
*************************** 1。排******************** *******
CHANNEL_NAME：master1
团队名字：
SOURCE_UUID：046e41f8-a223-11e4-a975-0811960cc264
THREAD_ID：24
SERVICE_STATE：开
COUNT_RECEIVED_HEARTBEATS：0
LAST_HEARTBEAT_TIMESTAMP：0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET：046e41f8-a223-11e4-a975-0811960cc264：4-37
LAST_ERROR_NUMBER：0
LAST_ERROR_MESSAGE：
LAST_ERROR_TIMESTAMP：0000-00-00 00:00:00
*************************** 2.排******************** *******
CHANNEL_NAME：master2
团队名字：
SOURCE_UUID：7475e474-a223-11e4-a978-0811960cc264
THREAD_ID：26
SERVICE_STATE：开
COUNT_RECEIVED_HEARTBEATS：0
LAST_HEARTBEAT_TIMESTAMP：0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET：7475e474-a223-11e4-a978-0811960cc264：4-6
LAST_ERROR_NUMBER：0
LAST_ERROR_MESSAGE：
LAST_ERROR_TIMESTAMP：0000-00-00 00:00:00
2行（0.00秒）
	    

MySQL的> SELECT * FROM replication_connection_status WHERE CHANNEL_NAME='master1'\G
*************************** 1。排******************** *******
CHANNEL_NAME：master1
团队名字：
SOURCE_UUID：046e41f8-a223-11e4-a975-0811960cc264
THREAD_ID：24
SERVICE_STATE：开
COUNT_RECEIVED_HEARTBEATS：0
LAST_HEARTBEAT_TIMESTAMP：0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET：046e41f8-a223-11e4-a975-0811960cc264：4-37
LAST_ERROR_NUMBER：0
LAST_ERROR_MESSAGE：
LAST_ERROR_TIMESTAMP：0000-00-00 00:00:00
1排（0.00秒）

错误代码和消息提供有关多源复制拓扑中遇到的错误的信息。 这些错误代码和消息仅在启用多源复制时发出，并提供与生成错误的通道相关的信息。 例如：

从已经在运行 和 从机已经停止 已经替换 为信道的复制线程（一个或多个） channel_name 已经在运行 ，并 用于信道复制的线程（多个） channel_name 已停止 分别。

服务器日志消息也已更改，以指示日志消息与哪个通道相关。 这使得调试和跟踪更容易。

为了能够安全地配置在线服务器的复制模式，了解一些关键的复制概念非常重要。 本节介绍了这些概念，在尝试修改在线服务器的复制模式之前，它是必不可少的读物。

MySQL中可用的复制模式依赖于识别记录的事务的不同技术。 复制使用的事务类型如下：

当使用GTIDs您可以利用自动定位和自动故障转移的，以及使用 WAIT_FOR_EXECUTED_GTID_SET() ， session_track_gtids 和监控使用Performance模式表复制的事务。 启用GTID后，您无法使用 sql_slave_skip_counter ，而是使用空事务。

从运行MySQL先前版本的主服务器接收的中继日志中的事务可能根本不会出现任何特定事件，但在重放并记录在从属二进制日志中之后，它们前面会有一个 Anonymous_gtid_log_event 。

在线配置复制模式的能力意味着 gtid_mode 和 enforce_gtid_consistency 变量现在都是动态的，并且可以通过具有足以设置全局系统变量的特权的帐户从顶级语句设置。 请参见 第5.1.9.1节“系统变量权限” 。 在MySQL 5.6及更早版本中，这两个变量都只能在服务器启动时使用适当的选项进行配置，这意味着对复制模式的更改需要重新启动服务器。 在所有版本中 gtid_mode 都可以设置为 ON 或 OFF ，这与GTID是否用于识别交易相对应。 什么时候 gtid_mode=ON 无法复制匿名事务，并且 gtid_mode=OFF 只能 复制匿名事务 。 gtid_mode=OFF_PERMISSIVE 然后， 当允许复制的事务为GTID或匿名事务 时， 新 事务是匿名的。 当 gtid_mode=ON_PERMISSIVE 再 新 ，同时允许复制的事务事务使用GTIDs是要么GTID或匿名交易。 这意味着可以拥有一个复制拓扑，其中包含使用匿名和GTID事务的服务器。 例如，一个主人 gtid_mode=ON 可以复制到一个奴隶 gtid_mode=ON_PERMISSIVE 。 有效值 gtid_mode 如下并按此顺序：

重要的是要注意，状态 gtid_mode 只能根据上述顺序一次改变一步。 例如，如果 gtid_mode 当前设置为 OFF_PERMISSIVE ，则可以更改为 OFF 或 ON_PERMISSIVE 不更改 ON 。 这是为了确保服务器正确处理从在线匿名事务更改为GTID事务的过程。 当您在 gtid_mode=ON 和 之间切换时 gtid_mode=OFF ，GTID状态（换句话说，值 gtid_executed ）是持久的。 这可确保始终保留服务器应用的GTID集，而不管类型之间的更改如何 gtid_mode 。

无论当前选择哪个，与GTID相关的字段都会显示正确的信息 gtid_mode 。 这意味着，显示GTID组领域，如 gtid_executed ， gtid_purged ， RECEIVED_TRANSACTION_SET 在 replication_connection_status 性能架构表，的GTID相关的结果 SHOW SLAVE STATUS ，现在返回空字符串时，有没有存在GTIDs。 现在， 在未使用GTID事务时 ，将显示显示单个GTID的字段，例如 CURRENT_TRANSACTION 性能模式 replication_applier_status_by_worker 表 中的 字段 ANONYMOUS 。

从主服务器进行的复制 gtid_mode=ON 提供了使用自动定位的功能，使用该 CHANGE MASTER TO MASTER_AUTO_POSITION = 1; 语句进行 配置 。 正在使用的复制拓扑影响是否可以启用自动定位，因为此功能依赖于GTID并且与匿名事务不兼容。 如果启用了自动定位并且遇到匿名事务，则会生成错误。 强烈建议在启用自动定位之前确保拓扑中没有剩余匿名事务，请参见 第17.1.5.2节“在线启用GTID事务” 。

gtid_mode 主站和从站 的有效组合 和自动定位如下表所示，其中主站 gtid_mode 显示在水平上，而从 gtid_mode 站在垂直方向上。 每个条目的含义如下：

当前选择的 gtid_mode 也会影响 gtid_next 变量。 下表显示了服务器的不同价值观的行为 gtid_mode 和 gtid_next 。 每个条目的含义如下：

当二进制日志关闭并 gtid_next 设置 AUTOMATIC 为时，则不会生成GTID。 这与先前版本的行为一致。

本节介绍如何在已联机且使用匿名事务的服务器上启用GTID事务以及（可选）自动定位。 此过程不需要使服务器脱机并且适合在生产中使用。 但是，如果您在启用GTID事务时可以使服务器脱机，则该过程更容易。

在开始之前，请确保服务器满足以下前提条件：

以下程序可以随时暂停，之后可以恢复 原状， 或者通过跳转到 第17.1.5.3节“禁用GTID在线交易” 的相应步骤进行 撤销，这是禁用GTID 的在线程序。 这使得该过程具有容错能力，因为可以像往常一样处理可能出现在过程中间的任何不相关的问题，然后该过程在其停止的地方继续。

要启用GTID交易：