MySQL8 中文参考（八十）（1）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

原文：dev.mysql.com/doc/refman/8.0/en/replication-semisync-interface.html

19.4.10.2 配置半同步复制

当您为半同步复制安装源和复制品插件时（参见 Section 19.4.10.1，“安装半同步复制”），系统变量变得可用以控制插件行为。

要检查半同步复制状态变量的当前值，请使用 SHOW VARIABLES：

mysql> SHOW VARIABLES LIKE 'rpl_semi_sync%';

从 MySQL 8.0.26 开始，提供了源和复制品插件的新版本，这些版本在系统变量和状态变量中将“master”和“slave”替换为“source”和“replica”。如果安装新的 rpl_semi_sync_source 和 rpl_semi_sync_replica 插件，则新的系统变量和状态变量可用，但旧的则不可用。如果安装旧的 rpl_semi_sync_master 和 rpl_semi_sync_slave 插件，则旧的系统变量和状态变量可用，但新的则不可用。在一个实例中不能同时安装相关插件的新旧版本。

所有 rpl_semi_sync_*xxx* 系统变量在 Section 19.1.6.2，“复制源选项和变量”和 Section 19.1.6.3，“复制品服务器选项和变量”中有描述。一些关键的系统变量包括：

rpl_semi_sync_source_enabled 或 rpl_semi_sync_master_enabled

控制源服务器上是否启用半同步复制。要启用或禁用插件，请将此变量分别设置为 1 或 0。默认值为 0（关闭）。

rpl_semi_sync_replica_enabled 或 rpl_semi_sync_slave_enabled

控制复制品上是否启用半同步复制。

rpl_semi_sync_source_timeout 或 rpl_semi_sync_master_timeout

以毫秒为单位的值，控制源在提交时等待来自复制品的确认的超时时间，超时后将回滚到异步复制。默认值为 10000（10 秒）。

rpl_semi_sync_source_wait_for_replica_count 或 rpl_semi_sync_master_wait_for_slave_count

控制源在返回会话之前必须接收的每个事务的副本确认数。默认值为 1，意味着源只等待一个副本确认接收事务事件。

rpl_semi_sync_source_wait_point 或 rpl_semi_sync_master_wait_point 系统变量控制半同步源服务器在返回事务提交状态给客户端之前等待副本确认事务接收的时间点。这些值是允许的：

• AFTER_SYNC（默认）：源将每个事务写入其二进制日志和副本，并将二进制日志同步到磁盘。源在同步后等待副本确认事务接收。在接收到确认后，源将事务提交到存储引擎并返回结果给客户端，然后客户端可以继续。
  
• AFTER_COMMIT：源将每个事务写入其二进制日志和副本，同步二进制日志，并提交事务到存储引擎。源在提交后等待副本确认事务接收。在接收到确认后，源返回结果给客户端，然后客户端可以继续。
  

这些设置的复制特性如下所示：

• 使用 AFTER_SYNC，所有客户端在同一时间看到已提交的事务，即在副本确认并在源上提交到存储引擎之后。因此，所有客户端在源上看到相同的数据。
  在源故障的情况下，所有在源上提交的事务已被复制到副本（保存到其中继日志）。源的意外退出并故障转移到副本是无损的，因为副本是最新的。如上所述，在故障转移后不应再重用源。
  
• 使用 AFTER_COMMIT，发起事务的客户端只有在服务器提交到存储引擎并接收到副本确认后才会收到返回状态。在提交后和副本确认前，其他客户端可能在提交客户端之前看到已提交的事务。
  如果出现问题导致副本未处理事务，那么在源意外退出并故障转移到副本的情况下，这些客户端可能会看到相对于在源上看到的数据有所丢失。
  

从 MySQL 8.0.23 开始，您可以通过启用系统变量replication_sender_observe_commit_only和replication_optimize_for_static_plugin_config来提高半同步复制的性能，前者限制回调，后者添加共享锁并避免不必要的锁获取。这些设置在副本数量增加时非常有帮助，因为锁争用可能会降低性能。半同步复制源服务器还可以通过启用这些系统变量获得性能优势，因为它们使用与副本相同的锁定机制。

原文：dev.mysql.com/doc/refman/8.0/en/replication-semisync-monitoring.html

19.4.10.3 半同步复制监控

半同步复制的插件公开了许多状态变量，使您能够监视其操作。要检查状态变量的当前值，请使用 SHOW STATUS：

mysql> SHOW STATUS LIKE 'Rpl_semi_sync%';

从 MySQL 8.0.26 开始，提供了新版本的源和副本插件，这些插件在系统变量和状态变量中用“source”和“replica”替换了“master”和“slave”这些术语。如果安装了新的 rpl_semi_sync_source 和 rpl_semi_sync_replica 插件，则新的系统变量和状态变量可用，而旧的则不可用。如果安装了旧的 rpl_semi_sync_master 和 rpl_semi_sync_slave 插件，则旧的系统变量和状态变量可用，而新的则不可用。在一个实例中不能同时安装相关插件的新旧版本。

所有 Rpl_semi_sync_*xxx* 状态变量在 第 7.1.10 节，“服务器状态变量” 中有描述。一些示例包括：

• Rpl_semi_sync_source_clients 或 Rpl_semi_sync_master_clients
  连接到源服务器的半同步副本数量。
  
• Rpl_semi_sync_source_status 或 Rpl_semi_sync_master_status
  半同步复制当前是否在源服务器上运行。如果插件已启用且提交确认尚未发生，则值为 1。如果插件未启用或源由于提交确认超时而回退到异步复制，则值为 0。
  
• Rpl_semi_sync_source_no_tx 或 Rpl_semi_sync_master_no_tx
  未被副本成功确认的提交数量。
  
• Rpl_semi_sync_source_yes_tx 或 Rpl_semi_sync_master_yes_tx
  被副本成功确认的提交数量。
  
• Rpl_semi_sync_replica_status 或 Rpl_semi_sync_slave_status
  半同步复制当前是否在副本上运行。如果插件已启用且复制 I/O（接收器）线程正在运行，则为 1，否则为 0。
  

当源端由于提交阻塞超时或副本追赶而在异步或半同步复制之间切换时，它会适当地设置Rpl_semi_sync_source_status或Rpl_semi_sync_master_status状态变量的值。源端从半同步自动回退到异步复制意味着即使半同步复制实际上当前不可用，rpl_semi_sync_source_enabled或rpl_semi_sync_master_enabled系统变量在源端可能仍然具有值 1。您可以监视Rpl_semi_sync_source_status或Rpl_semi_sync_master_status状态变量来确定源端当前是在使用异步还是半同步复制。

19.4.11 延迟复制

原文：dev.mysql.com/doc/refman/8.0/en/replication-delayed.html

MySQL 支持延迟复制，使得副本服务器故意比源服务器晚至少指定的时间执行事务。本节描述了如何在副本上配置复制延迟以及如何监视复制延迟。

在 MySQL 8.0 中，延迟复制的方法取决于两个时间戳，immediate_commit_timestamp和original_commit_timestamp（参见  Replication Delay Timestamps）。如果复制拓扑中的所有服务器都运行 MySQL 8.0  或更高版本，则使用这些时间戳来测量延迟复制。如果即时源或副本中有任何一个不使用这些时间戳，则使用 MySQL 5.7 中的延迟复制实现（参见  Delayed Replication）。本节描述了所有使用这些时间戳的服务器之间的延迟复制。

默认复制延迟为 0 秒。使用CHANGE REPLICATION SOURCE TO SOURCE_DELAY=*N*语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO MASTER_DELAY=*N*语句（MySQL 8.0.23 之前）将延迟设置为*N秒。从源接收的事务直到比其在即时源上提交的时间晚至少N*秒才执行。延迟是按事务发生的（而不是像以前的 MySQL 版本中那样按事件发生），实际延迟仅对gtid_log_event或anonymous_gtid_log_event施加。事务中的其他事件总是在这些事件之后立即执行，而不会对它们施加任何等待时间。

注意

START REPLICA和STOP REPLICA立即生效并忽略任何延迟。RESET REPLICA将延迟重置为 0。

replication_applier_configuration性能模式表包含DESIRED_DELAY列，显示使用SOURCE_DELAY | MASTER_DELAY选项配置的延迟。replication_applier_status性能模式表包含REMAINING_DELAY列，显示剩余的延迟秒数。

延迟复制可用于几个目的：

• 用于防止源上用户错误。通过延迟，您可以将延迟副本回滚到错误发生之前的时间。
  
• 为了测试系统在出现延迟时的行为。例如，在一个应用程序中，延迟可能是由于副本上的大量负载而引起的。然而，很难生成这种负载水平。延迟复制可以模拟延迟，而无需模拟负载。它还可以用于调试与滞后副本相关的条件。
  
• 为了查看数据库在过去的样子，而无需重新加载备份。例如，通过配置一个延迟一周的副本，如果您需要查看数据库在最近几天开发之前的样子，可以检查延迟副本。
  

复制延迟时间戳

MySQL 8.0 提供了一种新的方法来测量复制拓扑中的延迟（也称为复制滞后），该方法依赖于写入二进制日志的每个事务（而不是每个事件）关联的 GTID 的以下时间戳。

• original_commit_timestamp: 事务被写入（提交）到原始来源二进制日志时距离时代的微秒数。
  
• immediate_commit_timestamp: 事务被写入（提交）到直接来源二进制日志时距离时代的微秒数。
  

mysqlbinlog的输出以两种格式显示这些时间戳，即从时代开始的微秒数和基于用户定义时区的TIMESTAMP格式，以便更易读。例如：

#170404 10:48:05 server id 1  end_log_pos 233 CRC32 0x016ce647     GTID    last_committed=0
\ sequence_number=1    original_committed_timestamp=1491299285661130    immediate_commit_timestamp=1491299285843771
# original_commit_timestamp=1491299285661130 (2017-04-04 10:48:05.661130 WEST)
# immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST)
 /*!80001 SET @@SESSION.original_commit_timestamp=1491299285661130*//*!*/;
   SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
# at 233

通常情况下，事务应用到的所有副本上的original_commit_timestamp始终相同。在源-副本复制中，事务在（原始）源二进制日志中的original_commit_timestamp始终与其immediate_commit_timestamp相同。在副本的中继日志中，事务的original_commit_timestamp和immediate_commit_timestamp与源二进制日志中的相同；而在其自己的二进制日志中，事务的immediate_commit_timestamp对应于副本提交事务的时间。

在群组复制设置中，当原始来源是群组的成员时，original_commit_timestamp在事务准备提交时生成。换句话说，当它在原始来源上执行完毕并且其写入集准备发送到群组的所有成员进行认证时。当原始来源是群组外的服务器时，original_commit_timestamp被保留。特定事务的相同original_commit_timestamp被复制到群组中的所有服务器，以及从成员复制的群组外的任何副本。从 MySQL 8.0.26 开始，事务的每个接收者还使用immediate_commit_timestamp在其二进制日志中存储本地提交时间。

视图更改事件，这是组复制独有的特殊情况。包含这些事件的交易由每个组成员生成，但共享相同的 GTID（因此，它们不是首先在源中执行，然后被复制到组中，而是组的所有成员执行并应用相同的交易）。在 MySQL 8.0.26 之前，这些交易的original_commit_timestamp设置为零，并且在可查看的输出中以这种方式显示。从 MySQL 8.0.26 开始，为了提高可观察性，组成员为与视图更改事件相关的交易设置本地时间戳值。

监视复制延迟

在以前的 MySQL 版本中监视复制延迟（滞后）最常见的方法之一是依赖于SHOW REPLICA STATUS输出中的Seconds_Behind_Master字段。然而，在使用比传统源-副本设置更复杂的复制拓扑时，如组复制时，此度量标准并不适用。在 MySQL 8 中添加immediate_commit_timestamp和original_commit_timestamp提供了关于复制延迟的更精细信息。在支持这些时间戳的拓扑中监视复制延迟的推荐方法是使用以下性能模式表。

• replication_connection_status：与源的连接的当前状态，提供连接线程排队到中继日志的最后一个和当前交易的信息。
  
• replication_applier_status_by_coordinator：仅在使用多线程副本时显示协调器线程的当前状态，提供协调器线程缓冲到工作线程队列的最后一个交易的信息，以及它当前正在缓冲的交易。
  
• replication_applier_status_by_worker：应用来自源的交易的线程（们）的当前状态，提供由复制 SQL 线程应用的交易的信息，或者在使用多线程副本时，每个工作线程应用的交易的信息。
  

使用这些表，您可以监视对应线程处理的最后一个交易和该线程当前正在处理的交易的信息。这些信息包括：

• 一个交易的 GTID
  
• 从副本的中继日志中检索的交易的original_commit_timestamp和immediate_commit_timestamp
  
• 线程开始处理交易的时间
  
• 对于最后处理的交易，线程完成处理的时间
  

除了性能模式表之外，SHOW REPLICA STATUS的输出还有三个字段显示：

• SQL_Delay: 一个非负整数，表示使用CHANGE REPLICATION SOURCE TO SOURCE_DELAY=*N*（从 MySQL 8.0.23 开始）或CHANGE MASTER TO MASTER_DELAY=N（在 MySQL 8.0.23 之前）配置的复制延迟，以秒为单位。
  
• SQL_Remaining_Delay: 当Replica_SQL_Running_State为Waiting until MASTER_DELAY seconds after master executed event时，此字段包含一个整数，表示延迟剩余的秒数。在其他时候，此字段为NULL。
  
• Replica_SQL_Running_State: 表示 SQL 线程状态的字符串（类似于Replica_IO_State）。该值与由SHOW PROCESSLIST显示的 SQL 线程的State值相同。
  

当复制 SQL 线程在执行事件之前等待延迟时间时，SHOW PROCESSLIST将其State值显示为Waiting until MASTER_DELAY seconds after master executed event。

19.5 复制笔记和技巧

原文：dev.mysql.com/doc/refman/8.0/en/replication-notes.html

19.5.1 复制功能和问题

19.5.2 MySQL 版本之间的复制兼容性

19.5.3 升级复制拓扑结构

19.5.4 复制故障排除

19.5.5 如何报告复制错误或问题

19.5.1 复制功能和问题

原文：dev.mysql.com/doc/refman/8.0/en/replication-features.html

19.5.1.1 复制和 AUTO_INCREMENT

19.5.1.2 复制和 BLACKHOLE 表

19.5.1.3 复制和字符集

19.5.1.4 复制和 CHECKSUM TABLE

19.5.1.5 创建服务器，修改服务器和删除服务器的复制

19.5.1.6 CREATE … IF NOT EXISTS 语句的复制

19.5.1.7 复制 CREATE TABLE … SELECT 语句

19.5.1.8 CURRENT_USER()的复制

19.5.1.9 源和副本上的不同表定义的复制

19.5.1.10 复制和 DIRECTORY 表选项

19.5.1.11 复制 DROP … IF EXISTS 语句

19.5.1.12 复制和浮点值

19.5.1.13 复制和 FLUSH

19.5.1.14 复制和系统函数

19.5.1.15 复制和分数秒支持

19.5.1.16 调用功能的复制

19.5.1.17 复制 JSON 文档

19.5.1.18 复制和 LIMIT

19.5.1.19 复制和 LOAD DATA

19.5.1.20 复制和 max_allowed_packet

19.5.1.21 复制和 MEMORY 表

19.5.1.22 复制 mysql 系统模式

19.5.1.23 复制和查询优化器

19.5.1.24 复制和分区

19.5.1.25 复制和 REPAIR TABLE

19.5.1.26 复制和保留字

19.5.1.27 复制和行搜索

19.5.1.28 复制和源或副本的关闭

19.5.1.29 复制过程中的副本错误

19.5.1.30 复制和服务器 SQL 模式

19.5.1.31 复制和临时表

19.5.1.32 复制重试和超时

19.5.1.33 复制和时区

19.5.1.34 复制和事务不一致性

19.5.1.35 复制和事务

19.5.1.36 复制和触发器

19.5.1.37 复制和 TRUNCATE TABLE

19.5.1.38 复制和用户名长度

19.5.1.39 复制和变量

19.5.1.40 复制和视图

以下各节提供了关于 MySQL 复制中支持和不支持的内容，以及在复制某些语句时可能发生的特定问题和情况的信息。

基于语句的复制取决于源和副本之间在 SQL 级别的兼容性。换句话说，成功的基于语句的复制要求源服务器和副本服务器都支持使用的任何 SQL  特性。如果您在源服务器上使用了仅在当前版本的 MySQL 中可用的功能，则无法复制到使用较早版本的 MySQL  的副本。这种不兼容性也可能发生在版本系列内以及版本之间。

如果您计划在 MySQL 8.0 和之前的 MySQL 版本系列之间使用基于语句的复制，建议查阅MySQL 参考手册对应早期版本系列的版本，以获取有关该系列复制特性的信息。

使用 MySQL 的基于语句的复制时，可能会出现复制存储过程或触发器的问题。您可以通过改用 MySQL  的基于行的复制来避免这些问题。有关问题的详细列表，请参阅第 27.7  节，“存储程序二进制日志记录”。有关基于行的日志记录和基于行的复制的更多信息，请参阅第 7.4.4.1 节，“二进制日志格式”，以及第  19.2.1 节，“复制格式”。

对于与InnoDB复制相关的其他信息，请参阅第 17.19 节，“InnoDB 和 MySQL 复制”。有关与 NDB Cluster 复制相关的信息，请参阅第 25.7 节，“NDB Cluster 复制”。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-auto-increment.html

19.5.1.1 复制和 AUTO_INCREMENT

基于语句的复制AUTO_INCREMENT、LAST_INSERT_ID()和TIMESTAMP值的执行受以下异常情况的影响：

• 调用触发器或导致AUTO_INCREMENT列更新的函数的语句在基于语句的复制中无法正确复制。这些语句被标记为不安全。（Bug #45677）
  
• 对于具有包含AUTO_INCREMENT列但不是这个复合主键的第一列的复合主键的表进行INSERT不适用于基于语句的日志记录或复制。这些语句被标记为不安全。（Bug #11754117, Bug #45670）
  这个问题不影响使用InnoDB存储引擎的表，因为InnoDB表的AUTO_INCREMENT列需要至少一个键，其中AUTO_INCREMENT列是唯一的或最左边的列。
  
• 向具有ALTER TABLE的表添加AUTO_INCREMENT列可能不会在副本和源上产生相同的行顺序。这是因为行编号的顺序取决于用于表的特定存储引擎以及插入行的顺序。如果在源和副本上具有相同的顺序很重要，则在分配AUTO_INCREMENT编号之前必须对行进行排序。假设您想向具有列col1和col2的表t1添加AUTO_INCREMENT列，以下语句将生成一个与t1相同但具有AUTO_INCREMENT列的新表t2：

CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY;
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;

• 重要提示
  为了保证源和副本的顺序相同，ORDER BY子句必须命名t1的所有列。
  刚刚给出的指令受到CREATE TABLE ... LIKE的限制：外键定义被忽略，DATA DIRECTORY和INDEX DIRECTORY表选项也被忽略。如果表定义包含任何这些特征，使用与创建t1相同的CREATE TABLE语句创建t2，但增加AUTO_INCREMENT列。
  无论用于创建和填充具有AUTO_INCREMENT列的副本的方法如何，最后一步是删除原始表，然后重命名副本：

DROP t1;
ALTER TABLE t2 RENAME t1;

• 另请参阅 Section B.3.6.1, “Problems with ALTER TABLE”。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-blackhole.html

19.5.1.2 复制和 BLACKHOLE 表

BLACKHOLE存储引擎接受数据但会丢弃它，不会存储。在执行二进制日志记录时，所有对这些表的插入操作都会被记录，无论使用的日志格式是什么。根据使用的基于语句或基于行的日志记录方式，更新和删除操作会有不同的处理方式。在基于语句的日志记录格式下，所有影响BLACKHOLE表的语句都会被记录，但它们的效果会被忽略。在使用基于行的日志记录时，对这些表的更新和删除操作会被简单地跳过，不会被写入二进制日志。每当发生这种情况时，都会记录一个警告。

出于这个原因，我们建议当您使用BLACKHOLE存储引擎复制表时，将binlog_format服务器变量设置为STATEMENT，而不是ROW或MIXED。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-charset.html

19.5.1.3 复制和字符集

在使用不同字符集的 MySQL 服务器之间进行复制时，以下内容适用：

• 如果源数据库具有与全局character_set_server值不同的字符集，则应设计CREATE TABLE语句，使其不会隐式依赖于数据库默认字符集。一个好的解决方法是在CREATE TABLE语句中明确指定字符集和校对规则。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-checksum-table.html

19.5.1.4 复制和 CHECKSUM TABLE

CHECKSUM TABLE 返回一个逐行计算的校验和，使用依赖于表行存储格式的方法。存储格式在 MySQL 版本之间不保证保持不变，因此在升级后校验和值可能会改变。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-create-alter-drop-server.html

19.5.1.5 复制CREATE SERVER、ALTER SERVER和DROP SERVER

CREATE SERVER、ALTER SERVER和DROP SERVER语句不管使用何种二进制日志格式，都不会被写入二进制日志中。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-create-if-not-exists.html

19.5.1.6 复制CREATE ... IF NOT EXISTS语句

当复制各种CREATE ... IF NOT EXISTS语句时，MySQL 会应用以下规则：

• 每个CREATE DATABASE IF NOT EXISTS语句都会被复制，无论源数据库是否已存在。
  
• 类似地，每个不带SELECT的CREATE TABLE IF NOT EXISTS语句都会被复制，无论源端表是否已存在。这包括CREATE TABLE IF NOT EXISTS ... LIKE。CREATE TABLE IF NOT EXISTS ... SELECT的复制遵循稍有不同的规则；更多信息请参见第 19.5.1.7 节，“复制CREATE TABLE ... SELECT语句”。
  
• CREATE EVENT IF NOT EXISTS始终会被复制，无论语句中指定的事件是否已存在于源端。
  
• 只有成功的CREATE USER语句才会被写入二进制日志。如果语句包含IF NOT EXISTS，则被视为成功，并在至少创建一个在语句中命名的用户时记录；在这种情况下，语句将被记录为原样；这包括对未创建的现有用户的引用。更多信息请参见创建用户二进制日志记录。
  
• (MySQL 8.0.29 及更高版本😃 CREATE PROCEDURE IF NOT EXISTS、CREATE FUNCTION IF NOT EXISTS或CREATE TRIGGER IF NOT EXISTS，如果成功，将完整写入二进制日志（包括IF NOT EXISTS子句），无论语句是否因对象（过程、函数或触发器）已存在而引发警告。
  

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-create-select.html

19.5.1.7 复制 CREATE TABLE … SELECT 语句

当复制CREATE TABLE ... SELECT语句时，MySQL 应用以下规则：

• CREATE TABLE ... SELECT总是执行隐式提交（第 15.3.3 节，“导致隐式提交的语句”）。
  
• 如果目标表不存在，则记录如下。无论是否存在IF NOT EXISTS都无关紧要。

• STATEMENT或MIXED格式：该语句按原样记录。
  
• ROW格式：该语句被记录为一个CREATE TABLE语句，后跟一系列插入行事件。
  在 MySQL 8.0.21 之前，该语句被记录为两个事务。从 MySQL 8.0.21 开始，在支持原子 DDL 的存储引擎上，它被记录为一个事务。更多信息，请参阅第 15.1.1 节，“原子数据定义语句支持”。
  

• 如果CREATE TABLE ... SELECT语句失败，则不会记录任何内容。这包括目标表存在且未使用IF NOT EXISTS的情况。
  
• 如果目标表存在且使用了IF NOT EXISTS，MySQL 8.0 会完全忽略该语句；不会插入任何内容或记录日志。
  

MySQL 8.0 不允许CREATE TABLE ... SELECT语句对除了该语句创建的表之外的其他表进行任何更改。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-current-user.html

19.5.1.8 CURRENT_USER() 的复制

以下语句支持使用CURRENT_USER()函数来代替受影响用户或定义者的名称，以及可能的主机：

• DROP USER
  
• RENAME USER
  
• GRANT
  
• REVOKE
  
• CREATE FUNCTION
  
• CREATE PROCEDURE
  
• CREATE TRIGGER
  
• CREATE EVENT
  
• CREATE VIEW
  
• ALTER EVENT
  
• ALTER VIEW
  
• SET PASSWORD
  

当启用二进制日志记录并且在这些语句中使用CURRENT_USER()或CURRENT_USER作为定义者时，MySQL   服务器确保在语句被复制时应用于源和副本上的相同用户。在某些情况下，例如更改密码的语句，函数引用在写入二进制日志之前会被展开，以便语句包含用户名称。对于所有其他情况，源上的当前用户名称会作为元数据被复制到副本上，并且副本会将语句应用于元数据中命名的当前用户，而不是副本上的当前用户。

原文：dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html

MySQL8 中文参考（八十）（2）https://developer.aliyun.com/article/1565888