参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/sql-syntax-replication.html

可以使用本节中描述的语句通过SQL接口来控制复制。 语句分为控制主服务器的组，控制从属服务器的组以及可应用于任何复制服务器的组。

13.4.1 控制主服务的SQL 语句

除了这里描述的语句外，以下SHOW语句还用于复制中的主服务器。 有关这些语句的信息，请参见第13.7.5节“SHOW语法”。

• SHOW BINARY LOGS
• SHOW BINLOG EVENTS
• SHOW MASTER STATUS
• SHOW SLAVE HOSTS

13.4.1.1 PURGE BINARY LOGS 语法

PURGE { BINARY | MASTER } LOGS

{ TO 'log_name' | BEFORE datetime_expr }

二进制日志是一组包含由MySQL服务器进行的数据修改信息的文件。 该日志由一组二进制日志文件和一个索引文件组成（请参见第5.4.4节“二进制日志”）。

PURGE BINARY LOGS语句删除在log索引文件中指定的名称或日期之前的所有二进制日志文件。 BINARY和MASTER是同义词。 删除的日志文件也会从记录在索引文件中的列表中删除，以便给定的日志文件成为列表中的第一个。

如果服务器未使用--log-bin选项启动以启用二进制日志记录，则此语句不起作用。

例如：

PURGE BINARY LOGS TO 'mysql-bin.010';

PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

BEFORE变体的datetime_expr参数应计算为DATETIME值（'YYYY-MM-DD hh：mm：ss'格式中的值）。

这个语句可以安全的在slave复制时运行。 你不需要阻止他们。 如果您有一个当前正在读取要删除的日志文件之一的活动slave，则此语句不会删除正在使用的日志文件或晚于该日志文件的任何日志文件，但会删除任何较早的日志文件。 在这种情况下发出警告消息。 但是，如果slave未连接，而您恰好清除了尚未读取的某个日志文件，则从站在重新连接后将无法复制。

要安全地清除二进制日志文件，请遵循以下过程：

1.在每个slave服务器上，使用SHOW SLAVE STATUS来检查它正在读取的日志文件。

2.在主服务器上使用SHOW BINARY LOGS获得的二进制日志文件列表。

3.确定所有从站中最早的日志文件。 这是目标文件。 如果所有从站都是最新的，这是列表中的最后一个日志文件。

4.备份您即将删除的所有日志文件。 （这一步是可选的，但始终是可取的。）

5.清除所有日志文件，但不包括目标文件。

您还可以将expire_logs_days系统变量设置为在给定天数后自动过期二进制日志文件（请参见第5.1.7节“服务器系统变量”）。 如果您正在使用复制，则应该设置变量不低于您的slave可能落后于主人的最大天数。

PURGE BINARY LOGS TO 和PURGE BINARY LOGS BEFORE均失败，.index文件列出的二进制日志文件已通过其他方式（如在Linux上使用rm）从系统中移除。 （bug＃18199，bug＃18453）要处理此类错误，请手动编辑.index文件（这是一个简单的文本文件），以确保它只列出实际存在的二进制日志文件，然后再次运行失败的 PURGE BINARY LOGS 语句。

13.4.1.2 RESET MASTER 语法

RESET MASTER

删除索引文件中列出的所有二进制日志文件，将二进制日志索引文件重置为空，并创建一个新的二进制日志文件。

警告：

请谨慎使用此语句，以确保不会丢失二进制日志文件数据。

RESET MASTER还清除gtid_purged系统变量的值以及gtid_executed系统变量的全局值（但不是其会话值）; 也就是说，执行这个语句将这些值中的每一个设置为一个空字符串（''）。 在MySQL 5.7.5及更高版本中，该语句还清除mysql.gtid_executed表（请参阅mysql.gtid_executed表）。

重要

RESET MASTER的效果与2种关键方式中的PURGE BINARY LOGS的效果不同：

1.RESET MASTER删除索引文件中列出的所有二进制日志文件，只留下一个带有数字后缀.000001的单个空二进制日志文件，而编号不会由PURGE BINARY LOGS重置。

2.当任何复制从站正在运行时，不打算使用RESET MASTER。 在从站运行时使用RESET MASTER的行为未定义（因此不受支持），而在复制从站运行时可安全使用PURGE BINARY LOGS。

首次设置主设备和从设备时，RESET MASTER可以很有用，以便您可以验证设置，如下所示：

1.启动master 和 slave，并启动复制。

2.在主服务器上执行一些测试查询。

3.检查查询是否被复制到从站。

4.复制正确运行时，发出STOP SLAVE，然后在从站上发出RESET SLAVE，然后确认从站上不存在任何不需要的数据。

5.在master上发布RESET MASTER以清理测试查询。

验证设置后，重新设置主站和从站，并确保没有由测试生成的不需要的数据或二进制日志文件保留在主站或从站上，您可以启动从站并开始复制。

13.4.1.3 SET sql_log_bin 语法

SET sql_log_bin = {0|1}

sql_log_bin变量控制是否完成对二进制日志的记录。 默认值是1（做日志记录）。 要更改当前会话的日志记录，请更改此变量的会话值。 会话用户必须具有SUPER权限才能设置此变量。 将此变量设置为0，以便会话在临时禁用二进制日志记录的同时更改您不想复制到从属服务器的主服务器。

全局sql_log_bin变量是只读的，不能修改。 全局范围已被弃用，并将在未来的MySQL版本中被删除。

无法在事务或子查询中设置@@session.sql_log_bin。

13.4.2 SQL 语句控制slave 服务器

本节讨论用于管理从属复制服务器的语句。

除了这里描述的语句之外，SHOW SLAVE STATUS和SHOW RELAYLOG EVENTS也用于复制从站。

13.4.2.1 CHANGE MASTER TO 语法

CHANGE MASTER更改从属服务器用于连接到主服务器的参数，用于读取主二进制日志以及读取从属中继日志。 它还更新主信息和中继日志信息存储库的内容（请参见第16.2.4节“复制中继和状态日志”）。 CHANGE MASTER TO需要SUPER权限。

在MySQL 5.7.4之前，必须在发出此语句之前使用STOP SLAVE（必要时）停止从属复制线程。 在MySQL 5.7.4及更高版本中，您可以在正在运行的从站上执行CHANGE MASTER TO语句，而不必执行此操作，具体取决于从站SQL线程和从站I/O线程的状态。 本节稍后会提供管理此类使用的规则。

在使用多线程slave时（换句话说，slave_parallel_workers大于0），停止slave 会导致slave 中继日志执行的事务序列中出现“间隙”，而不管slave 是否有意停止。 当存在这种间隙时，发布CHANGE MASTER TO失败。 这种情况下的解决方案是发出START SLAVE UNTIL SQL_AFTER_MTS_GAPS确保间隙关闭。

可选的FOR CHANNEL通道子句使您能够命名该语句适用于哪个复制通道。 提供FOR CHANNEL通道子句将CHANGE MASTER TO语句应用于特定复制通道，并用于添加新通道或修改现有通道。 例如，要添加一个名为channel2的新通道：

CHANGE MASTER TO MASTER_HOST=host1, MASTER_PORT=3002 FORCHANNEL 'channel2'

如果没有子句被命名并且不存在额外的通道，则该语句适用于默认通道。

使用多个复制通道时，如果CHANGE MASTER TO语句未使用FOR CHANNEL通道子句命名通道，则会发生错误。

未指定的选项保留其值，除非在下面的讨论中指出。 因此，在大多数情况下，不需要指定不改变的选项。 例如，如果连接到您的MySQL主机的密码已更改，请发出以下语句以告知slave新密码：

CHANGE MASTER TO MASTER_PASSWORD='new3cret';

MASTER_HOST，MASTER_USER，MASTER_PASSWORD和MASTER_PORT向从站提供有关如何连接到其主站的信息：

• MASTER_HOST和MASTER_PORT是主控主机及其TCP / IP端口的主机名（或IP地址）。

注意：

复制不能使用Unix套接字文件。 您必须能够使用TCP / IP连接到主MySQL服务器。

如果指定了MASTER_HOST或MASTER_PORT选项，则从属设备认为主服务器与以前不同（即使选项值与当前值相同）。在这种情况下，master上旧二进制日志文件名和 位置被认为不再适用，所以如果你没有在语句中指定MASTER_LOG_FILE和MASTER_LOG_POS，那么MASTER_LOG_FILE =''和MASTER_LOG_POS = 4会默默地追加到它。

设置MASTER_HOST =''（即将其值显式设置为空字符串）与根本不设置MASTER_HOST不同。 从MySQL 5.5开始，尝试将MASTER_HOST设置为空字符串将失败并显示错误。 之前，将MASTER_HOST设置为空字符串，导致START SLAVE随后失败。 （bug＃28796）

对于换行（\ n或0x0A）字符检查用于MASTER_HOST和其他CHANGE MASTER TO选项的值; 在这些值中出现这些字符会导致语句在ER_MASTER_INFO时失败。 （bug＃11758581，bug＃50801）

• MASTER_USER和MASTER_PASSWORD是用于连接到主机的帐户的用户名和密码。

MASTER_USER不能设为空; 设置MASTER_USER =''或在为MASTER_PASSWORD设置值时未设置MASTER_USER会导致错误（Bug＃13427949）。

CHANGE MASTER TO语句中用于MySQL Replication从属帐户的密码长度限制为32个字符; 在MySQL 5.7.5之前，如果密码更长，则语句成功，但是任何多余的字符都会被自动截断。 在MySQL 5.7.5和更高版本中，尝试使用超过32个字符的密码会导致CHANGE MASTER TO失败。 （bug＃11752299，bug＃43439）

正在运行的CHANGE MASTER TO语句的文本（包括MASTER_USER和MASTER_PASSWORD的值）可以在并发SHOW PROCESSLIST语句的输出中看到。 （SHOW SLAVE语句的完整文本对SHOW PROCESSLIST也是可见的。）

MASTER_CONNECT_RETRY指定连接重试之间等待的秒数。 默认值是60。

MASTER_RETRY_COUNT限制重新连接尝试次数，并更新SHOW SLAVE STATUS输出中Master_Retry_Count列的值。 默认值为24 * 3600 = 86400. MASTER_RETRY_COUNT旨在替换旧的--master-retry-count服务器选项，现在是设置此限制的首选方法。 建议不要在新应用程序中依赖--master-retry-count，并且在从早于MySQL 5.6的版本升级时更新任何依赖它的现有应用程序，替代它们使用CHANGE MASTER TO ... MASTER_RETRY_COUNT。

MASTER_DELAY指定从站必须滞后多少秒。 从主设备收到的事件至少要比在主设备上执行的时间晚数秒才会执行。 缺省值为0.如果区间不是0到2的31次方-1范围内的非负整数，则会发生错误。

从MySQL 5.7开始，当从属SQL线程停止时，可以在正在运行的从属设备上执行使用MASTER_DELAY选项的CHANGE MASTER TO语句。

MASTER_BIND用于具有多个网络接口的复制从站，并确定选择哪个从站的网络接口连接到主站。

使用此选项配置的地址（如果有）可以在SHOW SLAVE STATUS的输出的Master_Bind列中看到。 如果您正在使用从属状态日志表（服务器以--master-info-repository = TABLE开头），则该值也可以被视为mysql.slave_master_info表的Master_bind列。

NDB集群还支持将复制从站绑定到特定网络接口的功能。

MASTER_HEARTBEAT_PERIOD设置复制心跳之间的时间间隔（以秒为单位）。 每当主站的二进制日志以事件更新时，下一次心跳的等待时间将重置。 interval是一个十进制值，范围为0到4294967秒，分辨率以毫秒为单位; 最小的非零值是0.001。 仅当二进制日志文件中没有未发送事件的时间超过间隔时，主节点才会发送心跳信号。

在MySQL 5.7.4之前，不包括MASTER_HEARTBEAT_PERIOD导致CHANGE MASTER TO将心跳周期（Slave_heartbeat_period）重置为默认值，并将Slave_received_heartbeats重置为0.（bug＃18185490）

如果您将主连接信息记录到表中，则MASTER_HEARTBEAT_PERIOD可以看作mysql.slave_master_info表的Heartbeat列的值。

将间隔设置为0会完全禁用心跳。 interval的缺省值等于slave_net_timeout的值除以2。

将@@global.slave_net_timeout设置为小于当前心跳间隔的值将导致发出警告。 在心跳间隔发出RESET SLAVE的效果是将其重置为默认值。

MASTER_LOG_FILE和MASTER_LOG_POS是下一次线程启动时从I / O线程应该从主服务器开始读取的坐标。 RELAY_LOG_FILE和RELAY_LOG_POS是下一次线程启动时从属SQL线程应从中继日志开始读取的坐标。 如果您指定MASTER_LOG_FILE或MASTER_LOG_POS中的任何一个，则无法指定RELAY_LOG_FILE或RELAY_LOG_POS。 如果您指定了MASTER_LOG_FILE或MASTER_LOG_POS中的任意一个，那么您也不能指定MASTER_AUTO_POSITION = 1（在本节后面介绍）。 如果未指定MASTER_LOG_FILE或MASTER_LOG_POS，则在发出CHANGE MASTER TO之前，从站使用从SQL SQL线程的最后一个坐标。 这可以确保在复制过程中不会出现中断，即使从属SQL线程比从属I / O线程晚，只需要更改（例如）要使用的密码时也是如此。

从MySQL 5.7中，当slave SQL线程停止时，可以在正在运行的slave 设备上执行采用RELAY_LOG_FILE，RELAY_LOG_POS或这两个选项的CHANGE MASTER TO语句。

如果MASTER_AUTO_POSITION = 1与CHANGE MASTER TO一起使用，则slave 尝试使用基于GTID的复制协议连接到主机。 从MySQL 5.7开始，只有在slave SQL和slave I/O线程都停止的情况下，该选项才可以被CHANGE MASTER TO使用。

当使用GTID时，从设备会通知主设备哪些事务它已经收到，执行或both。 要计算此集合，它会从SHOW SLAVE STATUS中读取gtid_executed的全局值和Retrieved_gtid_set列的值。 只有收到完整的事务时，最后传输的交易的GTID才会包含在Retrieved_gtid_set中。 从站计算以下集合：

UNION(@@global.gtid_executed, Retrieved_gtid_set)

在MySQL 5.7.5之前，即使事务仅被部分传输，最后传输的事务的GTID也包含在Retrieved_gtid_set中，并且从该集合中减去最后收到的GTID。 （bug＃17943188）因此，从站计算出以下集合：

UNION(@@global.gtid_executed, Retrieved_gtid_set -last_received_GTID)

这个集合作为初始握手的一部分发送给主节点，主节点发回它已经执行但不属于集合的所有事务。 如果任何这些事务已经从主服务器的二进制日志中清除，则主服务器将错误ER_MASTER_HAS_PURGED_REQUIRED_GTIDS发送给从服务器，并且复制不会启动。

当采用基于GTID的复制时，不使用由MASTER_LOG_FILE和MASTER_LOG_POS表示的坐标，而是使用全局事务标识符。 因此，将这些选项中的任何一个或两个与MASTER_AUTO_POSITION一起使用会导致错误。

您可以通过检查SHOW SLAVE STATUS的输出来查看复制是否在启用自动定位的情况下运行。 （Bug ＃15992220）

在发出CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1之前，还必须启用gtid_mode。否则，语句失败并显示错误。

要在使用GTID之后恢复到较早的基于文件的复制协议，可以发出指定MASTER_AUTO_POSITION = 0的新CHANGE MASTER TO语句，以及MASTER_LOG_FILE或MASTER_LOG_POS中的至少一个。

在MySQL 5.7.4之前，除非您指定RELAY_LOG_FILE或RELAY_LOG_POS，否则CHANGE MASTER删除所有中继日志文件并启动一个新文件。 在这种情况下，中继日志文件将保留; relay_log_purge全局变量默认设置为0.在MySQL 5.7.4和更高版本中，如果至少有一个从属SQL线程和从属I / O线程正在运行，则会保留中继日志; 如果两个线程都停止，则除非至少指定RELAY_LOG_FILE或RELAY_LOG_POS中的一个，否则将删除所有中继日志文件。

RELAY_LOG_FILE可以使用绝对或相对路径，并使用与MASTER_LOG_FILE相同的基本名称。 （bug＃12190）

IGNORE_SERVER_IDS采用逗号分隔的0个或更多服务器ID列表。 来自相应服务器的事件被忽略，除了日志轮转和删除事件，这些事件仍然记录在中继日志中。

在循环复制中，始发服务器通常作为其自身事件的终止符，以便它们不会多次应用。 因此，当环中的一台服务器被移除时，此选项在循环复制中非常有用。 假设您有4台服务器的循环复制设置，服务器ID为1,2,3和4，服务器3出现故障。 当通过开始从服务器2到服务器4的复制来弥补差距时，可以在服务器4上发出的CHANGE MASTER TO语句中包含IGNORE_SERVER_IDS =（3），以告诉它使用服务器2作为其主服务器而不是服务器3。 因此会导致它忽略并且不传播任何源于不再使用的服务器的语句。

如果在没有任何IGNORE_SERVER_IDS选项的情况下发出CHANGE MASTER TO语句，则保留任何现有列表。 要清除被忽略的服务器列表，有必须使用带有空列表的选项：

CHANGE MASTER TO IGNORE_SERVER_IDS = ();

在MySQL 5.7.5之前，RESET SLAVE ALL对服务器ID列表没有影响。 在MySQL 5.7.5和更高版本中，RESET SLAVE ALL清除IGNORE_SERVER_IDS。 （Bug＃18816897）

如果IGNORE_SERVER_IDS包含服务器自己的ID并且服务器启动时启用了--replicate-same-server-id选项，则会产生错误。

主信息库和SHOW SLAVE STATUS的输出提供当前被忽略的服务器列表。

调用CHANGE MASTER TO将使MASTER_HOST，MASTER_PORT，MASTER_LOG_FILE和MASTER_LOG_POS的先前值与执行前的从属状态的其他信息一起写入错误日志。

CHANGE MASTER TO导致正在进行的事务的隐式提交。

在MySQL 5.7.4和更高版本中，在发布任何CHANGE MASTER TO语句（以及之后的START SLAVE）之前，严格要求执行STOP SLAVE。 代替取决于slave是否停止，CHANGE MASTER TO的行为取决于（在MySQL 5.7.4及更高版本中）从属SQL线程和从属I / O线程的状态; 这些线程中的哪些被停止或正在运行现在确定可以或不可以在给定时间点与CHANGE MASTER TO语句一起使用的选项。 下面列出了做出这一决定的规则：

• 如果SQL线程停止，即使正在运行从I/O线程，也可以使用RELAY_LOG_FILE，RELAY_LOG_POS和MASTER_DELAY选项允许的任意组合执行CHANGE MASTER TO。 当I/O线程运行时，此语句不能使用其他选项。
• 如果I/O线程停止，则可以使用此语句的任何选项（在任何允许的组合中）执行CHANGE MASTER TO，除RELAY_LOG_FILE，RELAY_LOG_POS或MASTER_DELAY外，即使SQL线程正在运行。 当I/O线程运行时，这三个选项可能不会使用。
  
• 在发布使用MASTER_AUTO_POSITION = 1的CHANGE MASTER TO语句之前，必须停止SQL线程和I / O线程。
  

您可以使用SHOW SLAVE STATUS来检查从属SQL和I / O线程的当前状态。

如果您正在使用基于语句的复制和临时表，则在STOP SLAVE语句之后的CHANGE MASTER TO语句可能会在slave 上留下临时表。 从MySQL 5.7开始，每当发生这种情况，都会发出警告（ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO）。 在执行这种CHANGE MASTER TO语句之前，通过确保Slave_open_temp_tables系统状态变量的值等于0，可以避免出现这种情况。

CHANGE MASTER TO对于在拥有主设备快照并记录了与快照时间相对应的主二进制日志坐标时设置从设备非常有用。 将快照加载到从站以将其与主站同步后，可以在从站上运行CHANGE MASTER TO MASTER_LOG_FILE ='log_name'，MASTER_LOG_POS = log_pos以指定从站应该开始读取主二进制日志的坐标

以下示例更改从站使用的主服务器，并建立从站开始读取的主站二进制日志坐标。 当您想要设置从服务器来复制主服务器时，会使用它：

CHANGE MASTER TO MASTER_HOST='master2.example.com', MASTER_USER='replication', MASTER_PASSWORD='password', MASTER_PORT=3306, MASTER_LOG_FILE='master2-bin.001', MASTER_LOG_POS=4, MASTER_CONNECT_RETRY=10;

下一个示例显示了一个不太经常使用的操作。 当从站有中继日志文件时，它会用于您希望它由于某种原因再次执行。 为此，master不需要可达。 您只需使用CHANGE MASTER TO并启动SQL线程（START SLAVE SQL_THREAD）：

CHANGE MASTER TO RELAY_LOG_FILE='slave-relay-bin.006',RELAY_LOG_POS=4025;

您甚至可以在非复制设置中，使用独立的非slave服务器在崩溃后进行恢复。 假设你的服务器崩溃了，并且你从备份中恢复了它。 您想要重播服务器自己的二进制日志文件（不是中继日志文件，而是常规二进制日志文件），并将其命名为（例如）myhost-bin.*。 首先，在一些安全的地方制作这些二进制日志文件的备份副本，以防万一您没有完全按照以下步骤操作并意外让服务器清除二进制日志。 为了更加安全，请使用SET GLOBAL relay_log_purge = 0。 然后启动服务器而不使用--log-bin选项，而是使用--replicate-same-server-id，--relay-log = myhost-bin（使服务器相信这些常规二进制日志文件是中继 日志文件）和--skip-slave-start选项。 服务器启动后，发出以下语句：

CHANGE MASTER TO RELAY_LOG_FILE='myhost-bin.153',RELAY_LOG_POS=410, MASTER_HOST='some_dummy_string';

START SLAVE SQL_THREAD;

服务器读取并执行自己的二进制日志文件，从而实现崩溃恢复。 恢复完成后，运行STOP SLAVE，关闭服务器，清除master信息和中继日志信息存储库，然后使用其原始选项重新启动服务器。

指定MASTER_HOST选项（即使使用虚拟值）也是使服务器认为它是从服务器所必需的。

下表显示了字符串值选项的最大允许长度。

13.4.2.2 CHANGE REPLICATION FILTER 语法

CHANGE REPLICATION FILTER在slave上设置一个或多个复制过滤规则，就像使用复制过滤选项（如--replicate-do-db或--replicate-wild-ignore-table）启动slave mysqld一样。 与服务器选项不同，此语句不需要重新启动服务器即可生效，只需先使用STOP SLAVE SQL_THREAD停止从属SQL线程（然后再用START SLAVE SQL_THREAD重新启动）。 CHANGE REPLICATION FILTER需要SUPER权限。

以下列表显示CHANGE REPLICATION FILTER选项以及它们与--replicate- * server选项的关系：

• REPLICATE_DO_DB：包含基于数据库名称的更新。 相当于--replicate-do-db。
• REPLICATE_IGNORE_DB：根据数据库名称排除更新。 相当于--replicate-ignore-db。
• REPLICATE_DO_TABLE：包含基于表名称的更新。 相当于--replicate-do-table。
• REPLICATE_IGNORE_TABLE：根据表名排除更新。 相当于--replicate-ignore-table。
• REPLICATE_WILD_DO_TABLE：包含基于通配符模式匹配表名称的更新。 相当于--replicate-wild-do-table。
• REPLICATE_WILD_IGNORE_TABLE：根据通配符模式匹配表名排除更新。 相当于--replicate-wild-ignore-table。
• REPLICATE_REWRITE_DB：在从站上的新名称替换为主站上的指定数据库后，对从站执行更新。 相当于--replicate-rewrite-db。

REPLICATE_DO_DB和REPLICATE_IGNORE_DB过滤器的精确效果取决于基于语句的复制或基于行的复制是否有效。

通过用逗号分隔规则，可以在单个CHANGE REPLICATION FILTER语句中创建多个复制过滤规则，如下所示：

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (d1),REPLICATE_IGNORE_DB = (d2);

发出刚刚显示的语句相当于使用选项--replicate-do-db=d1

--replicate-ignore-db=d2启动从属mysqld。

如果多次指定了相同的过滤规则，则实际只使用最后一个这样的规则。 例如，这里显示的两条语句具有完全相同的效果，因为第一条语句中的第一条REPLICATE_DO_DB规则将被忽略：

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db1, db2),REPLICATE_DO_DB = (db3, db4);

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (db3,db4);

注意：

此行为与--replicate- *筛选器选项的行为不同，多次指定相同选项会导致创建多个筛选器规则。

不包含任何特殊字符的表和数据库的名称不需要引用。 与REPLICATION_WILD_TABLE和REPLICATION_WILD_IGNORE_TABLE一起使用的值是字符串表达式，可能包含（特殊）通配符，因此必须加引号。 这在以下示例语句中显示：

CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE =('db1.old%');

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE =('db1.new%', 'db2.new%');

用于REPLICATE_REWRITE_DB的值表示数据库名称对; 每个这样的值必须用括号括起来。 以下语句将主站上的数据库db1上发生的语句重写到从站上的数据库db2：

CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB = ((db1,db2));

刚才显示的语句包含两组括号，一个括号包含数据库名称对，另一个括号包含整个列表。 这在下面的示例中更容易看到，它创建两个rewrite-db规则，一个重写数据库dbA到dbB，一个重写数据库dbC到dbD：

CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB = ((dbA, dbB), (dbC, dbD));

此语句保留任何现有的复制过滤规则不变; 要取消设置给定类型的所有过滤器，请将过滤器的值设置为明确为空的列表，如以下示例所示，该过程将删除所有现有的REPLICATE_DO_DB和REPLICATE_IGNORE_DB规则：

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (),REPLICATE_IGNORE_DB = ();

以这种方式将过滤器设置为空将删除所有现有规则，不会创建任何新规则，并且不会在命令行或配置文件中使用--replicate- *选项恢复在mysqld启动时设置的任何规则。

REPLICATE_WILD_DO_TABLE和REPLICATE_WILD_IGNORE_TABLE使用的值必须采用格式db_name.tbl_name。 在使用MySQL 5.7.5之前，虽然在这些选项中使用不合格的值可能会导致错误的结果，但并未严格执行此操作（bug＃18095449）。

13.4.2.3 MASTER_POS_WAIT() 语法

SELECT MASTER_POS_WAIT('master_log_file', master_log_pos [,timeout][, channel])

这实际上是一个功能，而不是一个语句。 它用于确保从站读取和执行事件直到主站二进制日志中的给定位置。

13.4.2.4 reset slave

RESET SLAVE [ALL] [channel_option]

channel_option: FOR CHANNEL channel

RESET SLAVE使得slave忘记了在master的二进制日志中的复制位置。 此语句旨在用于干净启动：清除主信息和中继日志信息存储库，删除所有中继日志文件，并启动新的中继日志文件。 用MASTER_DELAY选项指定的CHANGE MASTER TO的复制延迟，它也重置为0。 RESET SLAVE不会更改gtid_executed或gtid_purged的值。 要使用RESET SLAVE，必须停止从属复制线程，因此在发出RESET SLAVE之前，在正在运行的从属设备使用STOP SLAVE。

注意：

所有中继日志文件都将被删除，即使它们尚未完全由从属SQL线程执行。 （如果您已发出STOP SLAVE语句或从机高负载，则这是从复制副本上可能存在的情况。）

可选的FOR CHANNEL通道子句使您能够命名该语句适用于哪个复制通道。 提供FOR CHANNEL通道子句将RESET SLAVE语句应用于特定的复制通道。 将FOR CHANNEL通道子句与ALL选项组合会删除指定的通道。 如果没有通道被命名并且不存在额外的通道，则该语句适用于默认通道。 当存在多个复制通道时，发出没有FOR CHANNEL通道子句的RESET SLAVE ALL语句将删除所有复制通道并仅重新创建默认通道。

RESET SLAVE不会更改保留在内存中的任何复制连接参数，例如主控主机，主端口，主用户或主密码。 这意味着START SLAVE可以在RESET SLAVE后不需要CHANGE MASTER TO语句而发布。

连接参数由RESET SLAVE ALL复位。 （RESET SLAVE，然后重启slave mysqld也是这样。）

RESET SLAVE会导致正在进行的事务的隐式提交

如果从属SQL线程在复制临时表的过程中停止，并且发出了RESET SLAVE，则这些复制的临时表将在从属设备上被删除

在MySQL 5.7.5之前，RESET SLAVE还具有重置心跳周期（Slave_heartbeat_period）和SSL_VERIFY_SERVER_CERT的效果。 这个问题已在MySQL 5.7.5及更高版本中修复。 （Bug＃18777899，Bug＃18778485）

在MySQL 5.7.5之前，RESET SLAVE ALL没有清除由CHANGE MASTER TO设置的IGNORE_SERVER_IDS列表。 在MySQL 5.7.5及更高版本中，语句清除了列表。 （Bug＃18816897）

注意

在NDB群集复制从属SQL节点上使用时，RESET SLAVE将清除mysql.ndb_apply_status表。 在使用此语句时，请记住ndb_apply_status使用NDB存储引擎，并由所有连接到从群集的SQL节点共享。

在执行RESET SLAVE之前，您可以通过发出SET GLOBAL @@ ndb_clear_apply_status = OFF来覆盖此行为，这会使slave在这种情况下清除ndb_apply_status表。

13.4.2.5 SET GLOBAL sql_slave_skip_counter 语法

SET GLOBAL sql_slave_skip_counter = N

这条语句跳过主站的下N个事件。 这对从语句引起的复制停止恢复很有用。

该语句仅在从属线程未运行时才有效。 否则，它会产生一个错误。

使用此语句时，了解二进制日志实际上组织为一组称为事件组的序列是很重要的。 每个事件组由一系列事件组成。

• 对于事务表，事件组对应于一个事务。
• 对于非事务性表，事件组对应于单个SQL语句。

注意：

单个事务可以包含对事务性和非事务性表的更改。

当您使用SET GLOBAL sql_slave_skip_counter跳过事件并且结果位于组的中间时，从站将继续跳过事件直到它到达组的末尾。 然后执行从下一个事件组开始。

13.4.2.6 START SLAVE 语法

不带thread_type选项的START SLAVE启动两个从属线程。 I/O线程从主服务器读取事件并将它们存储在中继日志中。 SQL线程从中继日志中读取事件并执行它们。 START SLAVE需要SUPER权限。

如果START SLAVE成功启动从属线程，则返回时不会出现任何错误。 但是，即使在这种情况下，也可能是slave线程启动，然后停止（例如，因为它们无法连接到主服务器或读取其二进制日志或其他问题）。 START SLAVE不会对此发出警告。 您必须检查从站的错误日志中是否存在由从属线程生成的错误消息，或者使用SHOW SLAVE STATUS检查它们是否满意地运行。

在MySQL 5.7中，START SLAVE会导致正在进行的事务的隐式提交。

在发布此语句之前，必须将gtid_next设置为AUTOMATIC。

可选的FOR CHANNEL通道子句使您能够命名该语句适用于哪个复制通道。 提供FOR CHANNEL通道子句将START SLAVE语句应用于特定的复制通道。 如果没有子句被命名并且不存在额外的通道，则该语句适用于默认通道。 如果START SLAVE语句在使用多个通道时没有定义通道，则该语句会为所有通道启动指定的线程。 该语句不适用于group_replication_recovery通道。

MySQL支持用START，SLAVE和USER，PASSWORD，DEFAULT_AUTH和PLUGIN_DIR选项进行可插入的用户密码认证，如下面的列表所述：

• USER: 用户名。不能设置为空或空字符串，或者如果使用PASSWORD则不设置。
• PASSWORD：密码
• DEFAULT_AULT：插件名称; 默认是MySQL本地认证。
• PLUGIN_DIR： 插件位置

除非还提供了IO_THREAD选项，否则指定USER，PASSWORD，DEFAULT_AUTH或PLUGIN_DIR时不能使用SQL_THREAD选项。

如果对任何这些选项使用不安全连接，服务器将发出警告以纯文本发送密码而不使用SSL / TLS是非常不安全的。

START SLAVE ... UNTIL支持两个用于全局事务标识符（GTID）的附加选项（请参见第16.1.3节“使用全局事务标识符进行复制”）。 其中的每个都将一个或多个全局事务标识符集gtid_set作为参数（有关更多信息，请参阅GTID集）。

当没有指定thread_type时，START SLAVE UNTIL SQL_BEFORE_GTIDS将导致从属SQL线程处理事务，直到它到达GTID在gtid_set中列出的第一个事务。 START SLAVE UNTIL SQL_AFTER_GTIDS导致从线程处理所有事务，直到两个线程处理完gtid_set中的最后一个事务为止。 换言之，START SLAVE UNTIL SQL_BEFORE_GTIDS会导致从属SQL线程处理在到达gtid_set中的第一个GTID之前发生的所有事务，并且START SLAVE UNTIL SQL_AFTER_GTIDS将导致从属线程处理所有事务，包括那些GTID位于gtid_set中的事务 ，直到每个人遇到一个其GTID不属于该集合的事务。 SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS均支持SQL_THREAD和IO_THREAD选项，尽管对它们使用IO_THREAD目前没有任何作用。

例如，START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56会导致从属SQL线程处理源自其server_uuid为3E11FA47-71CA-11E1-9E33-C80AA9429562的所有事务，直到遇到 该事务具有序号11; 然后停止而不处理此事务。 换句话说，直至并包括序列号为10的事务的所有事务都被处理。 另一方面，执行START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56会导致从属SQL线程获取刚刚从主服务器提到的所有事务，包括所有具有序列的事务 数字11到56，然后停止而不处理任何额外的事务; 也就是说，序列号为56的事务将是从属SQL线程获取的最后一个事务。

在MySQL 5.7.3之前，一旦指定的事务完成，SQL_AFTER_GTIDS并没有停止从服务器，而是一直等到收到另一个GTID事件（BUG＃14767986）。

在使用多线程从站时，在以下情况下，从中继日志执行的事务序列中可能存在间隔：

• 杀死协调器线程
• 在工作线程中发生错误之后
• mysqld意外关闭

使用START SLAVE UNTIL SQL_AFTER_MTS_GAPS语句使多线程从属工作线程运行，直到在中继日志中找不到更多的间隔，然后停止。 该语句可以采用SQL_THREAD选项，但语句的效果保持不变。 它对从I / O线程没有影响（并且不能与IO_THREAD选项一起使用）。

在多线程从站上发出START SLAVE，并在从中继日志执行的事务序列中存在差距时会生成警告。 在这种情况下，解决方案是使用START SLAVE UNTIL SQL_AFTER_MTS_GAPS，然后发出RESET SLAVE以删除任何剩余的中继日志。

要将发生故障的多线程从设备更改为单线程模式，可以按所示顺序发出以下一系列语句：

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;

SET @@GLOBAL.slave_parallel_workers = 0;

START SLAVE SQL_THREAD;

注意：

可以在SHOW PROCESSLIST的输出中查看正在运行的START SLAVE ...语句的全部文本，包括使用的任何USER或PASSWORD值。 对于正在运行的CHANGE MASTER TO语句的文本也是如此，包括它对MASTER_USER或MASTER_PASSWORD使用的任何值。

在I / O线程和SQL线程都启动后，START SLAVE向用户发送确认。 但是，I / O线程可能尚未连接。 由于这个原因，一个成功的START SLAVE会导致SHOW SLAVE STATUS显示Slave_SQL_Running = Yes，但这并不能保证Slave_IO_Running = Yes（因为只有在I / O线程正在运行并连接时Slave_IO_Running = Yes）。

您可以将IO_THREAD和SQL_THREAD选项添加到语句中，以命名启动哪个线程。 指定任何USER，PASSWORD，DEFAULT_AUTH或PLUGIN_DIR时，不允许使用SQL_THREAD选项，除非还提供了IO_THREAD选项。

可以添加UNTIL子句（在前面的语法中为until_option），以指定从属服务器应该启动并运行，直到SQL线程到达主二进制日志中的指定点，由MASTER_LOG_POS和MASTER_LOG_FILE选项指定或给定的点 从属中继日志，用RELAY_LOG_POS和RELAY_LOG_FILE选项指示。 当SQL线程到达指定的点时，它停止。 如果在语句中指定了SQL_THREAD选项，则它仅启动SQL线程。 否则，它会启动两个从线程。 如果SQL线程正在运行，则会忽略UNTIL子句并发出警告。 IO_THREAD选项不能使用UNTIL子句。

如本节前面所述，也可以使用START SLAVE UNTIL来使用SQL_BEFORE_GTIDS或SQL_AFTER_GTIDS选项之一指定相对于给定GTID或GTID集合的停止点。 当使用这些选项之一时，您可以指定SQL_THREAD，IO_THREAD，这两个选项或者都不指定。 如果只指定SQL_THREAD，则只有从属SQL线程受到该语句的影响; 如果只使用IO_THREAD，则只有从I / O受到影响。 如果使用了SQL_THREAD和IO_THREAD，或者两者都不使用，那么SQL和I / O线程都会受到该语句的影响。

除了同时使用SQL_AFTER_MTS_GAPS外，UNTIL子句不支持多线程从属。

对于UNTIL子句，您必须指定以下任一项：

• 日志文件名和该文件中的位置
• SQL_BEFORE_GTIDS或SQL_AFTER_GTIDS中的任一个
• SQL_AFTER_MTS_GAPS

不要混合使用主站和中继日志选项。 不要将日志文件选项与GTID选项混合使用。

任何UNTIL条件都在，不包含UNTIL子句的START SLAVE语句或服务器重新启动之后重置。

指定日志文件和位置时，即使只有SQL线程受此语句影响，也可以使用IO_THREAD选项和START SLAVE ... UNTIL。 在这种情况下，IO_THREAD选项将被忽略。 使用其中一个GTID选项（SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS）时，上述限制不适用; 如本节前面所述，GTID选项同时支持SQL_THREAD和IO_THREAD。

UNTIL子句可用于调试复制，或者让复制继续进行，直到您希望避免从复制事件的点之前。 例如，如果在主服务器上执行了不明智的DROP TABLE语句，则可以使用UNTIL来告诉从服务器执行到该点，但不会更远。 要查找事件是什么，请将mysqlbinlog用于主二进制日志或从属中继日志，或使用SHOW BINLOG EVENTS语句。

如果您正在使用UNTIL使分区中的从进程复制查询，建议您使用--skip-slave-start选项启动从服务器，以防止从服务器启动时SQL线程运行。 在选项文件中而不是命令行中使用此选项可能是最好的选择，这样意外的服务器重新启动不会导致它被遗忘。

SHOW SLAVE STATUS语句包括显示UNTIL条件当前值的输出字段。

在MySQL 5.7.5之前，该语句的失败导致从心跳周期被重置。 这个问题已在MySQL 5.7.5及更高版本中修复。 （错误＃18791604）

在非常旧的MySQL版本（在4.0.5之前）中，这个语句被称为SLAVE START。 该语法现在产生一个错误。

13.4.2.7 STOP SLAVE 语法

停止从线程。 STOP SLAVE需要SUPER权限。 建议的最佳做法是在停止从服务器之前在从服务器上执行STOP SLAVE（有关更多信息，请参见第5.1.15节“服务器关闭过程”）。

使用基于行的记录格式时：如果要复制使用非事务存储引擎的任何表（请参阅本部分后面的注释），在关闭从属服务器之前，应在从属系统上执行STOP SLAVE或STOP SLAVE SQL_THREAD。

与START SLAVE类似，此语句可以与IO_THREAD和SQL_THREAD选项一起使用，以命名线程。

STOP SLAVE会导致正在进行的事务的隐式提交。

在发布此语句之前，从MySQL 5.7开始，必须将gtid_next设置为AUTOMATIC（错误＃16062608）。

从MySQL 5.7开始，您可以通过设置rpl_stop_slave_timeout系统变量来控制STOP SLAVE在超时之前等待的时间。 这可以用来避免STOP SLAVE和其他从属SQL语句之间的死锁，这些SQL语句使用与从属设备不同的客户端连接。 当达到超时值时，发出客户端返回错误消息并停止等待，但STOP SLAVE指令保持有效。 一旦从属线程不再繁忙，就会执行STOP SLAVE语句并且slave停止。 （Bug＃16856735）

根据从属SQL和I / O线程的状态，从属运行时允许一些CHANGE MASTER TO语句。 但是，在这种情况下，在执行CHANGE MASTER TO之前使用STOP SLAVE仍然受支持。

可选的FOR CHANNEL通道子句使您能够命名该语句适用于哪个复制通道。 提供FOR CHANNEL通道子句将STOP SLAVE语句应用于特定的复制通道。 如果没有通道被命名并且不存在额外的通道，则该语句适用于默认通道。 如果STOP SLAVE语句在使用多个通道时未命名通道，则此语句停止所有通道的指定线程。 该语句不能与group_replication_recovery通道一起使用。

使用基于语句的复制时：在打开临时表时更改主控可能不安全。 这是为什么不建议临时表的基于语句的复制的原因之一。 您可以通过检查Slave_open_temp_tables的值来查明从站是否有临时表; 当使用基于语句的复制时，在执行CHANGE MASTER TO之前，该值应该为0。 如果从站上有任何临时表打开，在发出STOP SLAVE后发出CHANGE MASTER TO语句会导致ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO警告。

当使用多线程从站（slave_parallel_workers为非零值）时，从中继日志执行的事务序列中的任何间隙都将作为停止工作线程的一部分而关闭。 如果在执行STOP SLAVE语句时从站意外停止（例如由于工作线程中的错误或另一个发出KILL的线程），则来自中继日志的已执行事务序列可能会变得不一致。

如果当前复制事件组修改了一个或多个非事务表，则除非您为slave SQL线程发出KILL QUERY或KILL CONNECTION语句，否则STOP SLAVE将等待最多60秒以完成事件组。 如果事件组在超时后保持不完整，则会记录一条错误消息。

13.4.3 用于控制组复制的SQL语句

本节提供有关用于控制运行MySQL组复制插件的服务器的语句的信息。

13.4.3.1 START GROUP_REPLICATION 语法

START GROUP_REPLICATION

在此服务器实例上启动组复制。 该声明需要SUPER特权。 如果super_read_only = ON且成员应该作为主节点加入，则一旦组复制成功启动，super_read_only就会设置为OFF。

13.4.3.2 STOP GROUP_REPLICATION 语法

STOP GROUP_REPLICATION

停止组复制。 该声明需要SUPER特权。 一旦发出STOP GROUP_REPLICATION，成员就会设置为super_read_only = ON，这可确保在组复制停止时不会写入成员。

警告：

请谨慎使用此语句，因为它将该服务器实例从组中删除，这意味着它不再受组复制一致性保证机制的保护。 为了完全安全，请确保在发布此语句之前，您的应用程序不能再连接到实例，以避免任何陈旧读取的机会。