Question

A.14.1.

副本是否必须始终连接到源?

Answer 1

不，副本不需要始终连接到源。副本可以关闭或断开连接数小时或数天，然后重新连接并追赶更新。例如，您可以在间歇性连接的拨号链路上设置源/副本关系，在这种情况下，链路仅在短时间内打开。

要确保断开连接的副本可以追赶，请不要从源中删除包含尚未复制到副本的信息的二进制日志文件。异步复制只能在副本可以继续从最后读取事件的点继续读取二进制日志的情况下工作。

Answer 2

是的，在源和副本上必须启用网络。如果没有启用网络，副本无法连接到源并传输二进制日志。请验证在服务器配置文件中没有启用skip_networking系统变量。

Answer 3

检查SHOW REPLICA | SLAVE STATUS输出中的Seconds_Behind_Master列。请参阅第 19.1.7.1 节，“检查复制状态”。

当复制 SQL 线程执行从源读取的事件时，它将自己的时间修改为事件时间戳。（这就是为什么TIMESTAMP可以正确复制的原因。）在SHOW PROCESSLIST输出的Time列中，显示的秒数是最后复制事件的时间戳和副本机器的实际时间之间的秒数。您可以使用此信息来确定最后复制事件的日期。请注意，如果您的副本与源断开连接了一小时，然后重新连接，您可能会在SHOW PROCESSLIST中看到大约 3600 的Time值。这是因为副本正在执行一小时前的语句。请参阅第 19.2.3 节，“复制线程”。

Answer 4

使用以下过程：

在源上执行以下语句：
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
```
从 SHOW 语句的输出中记录复制坐标（当前二进制日志文件名和位置）。
在副本上发出以下语句，其中 SOURCE_POS_WAIT() 或 MASTER_POS_WAIT() 函数的参数是前一步骤中获得的复制坐标值：
```
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);

从 MySQL 8.0.26 开始：
mysql> SELECT SOURCE_POS_WAIT('log_name', log_pos);
```
SELECT 语句将阻塞，直到副本达到指定的日志文件和位置。在那时，副本与源同步，语句将返回。
在源上发出以下语句，以启用源继续处理更新：
```
mysql> UNLOCK TABLES;
```

Answer 5

MySQL 复制当前不支持源和副本之间的锁定协议，以保证分布式（跨服务器）更新的原子性。换言之，客户端 A 可以在 co-source 1 上进行更新，而在更新传播到 co-source 2 之前，客户端 B 可以在 co-source 2 上进行更新，使得客户端 A 的更新在 co-source 2 上工作方式不同于在 co-source 1 上。因此，当客户端 A 的更新到达 co-source 2 时，它将生成与 co-source 1 上不同的表，即使所有来自 co-source 2 的更新也已经传播。因此，您不应该将两个服务器链式连接到双向复制关系中，除非您确定您的更新可以安全地以任何顺序发生，或者您在客户端代码中处理了乱序更新。

您还应该意识到，双向复制实际上并不会很大地提高性能（如果有的话）。每个服务器都必须执行相同数量的更新，就像单个服务器那样。唯一的区别是，来自另一个服务器的更新将被序列化到一个复制线程中。甚至这种好处也可能被网络延迟所抵消。

Answer 6

将一个服务器设置为源，并将所有写入指令发送到该服务器。然后，配置尽可能多的副本，并将读取分布在源和副本之间。您也可以使用 --skip-innodb 选项启动副本，启用 low_priority_updates 系统变量，并将 delay_key_write 系统变量设置为 ALL，以在副本端获得速度改进。在这种情况下，副本使用非事务性的 MyISAM 表而不是 InnoDB 表，以通过消除事务开销来获得更多速度。

Answer 7

请参阅使用复制作为扩展解决方案的指南：第 19.4.5 节，“使用 Replication 作为扩展解决方案”。

Answer 8

MySQL 复制对频繁读取和不频繁写入的系统最有益处。在理论上，使用单源/多副本设置，您可以通过添加更多副本来扩展系统，直到您耗尽网络带宽或更新负载增长到源无法处理的程度。

要确定您可以使用多少副本之前，性能改善开始平稳，并且您可以通过 benchmarking 来确定读取和写入的关系，了解您的查询模式。

例如，假设系统负载由 10% 的写入和 90% 的读取组成，我们通过 benchmarking 确定 reads 是 1200 - 2 * writes。也就是说，系统可以每秒处理 1,200 次读取，而不进行写入，平均写入速度是平均读取速度的两倍，关系是线性的。

假设源和每个副本具有相同的容量，我们有一个源和 N 个副本。那么，对于每个服务器（源或副本），我们有：

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (读取被分配，但写入被复制到所有副本)

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

最后一个等式表明了对于 N 个副本的最大写入次数，给定每秒 1,200 次的最大读取率和九次读取对一次写入的比例。

这个分析得出了以下结论：

如果 N = 0（这意味着我们没有复制），我们的系统可以处理大约 1200/11 = 109 次写入每秒。
如果 N = 1，我们可以达到 184 次写入每秒。
如果 N = 8，我们可以达到 400 次写入每秒。
如果 N = 17，我们可以达到 480 次写入每秒。
最终，当 N 接近无穷大时（我们的预算接近负无穷大），我们可以达到近似 600 次写入每秒，系统吞吐量增加了约 5.5 倍。但是，只需要八个服务器，我们就可以将吞吐量增加近四倍。

这些计算假设了无限的网络带宽，并忽略了可能对您的系统产生影响的其他因素。在许多情况下，您可能无法进行类似于上述计算，以准确预测添加 N 个副本对您的系统性能的影响。

但是，回答以下问题可以帮助您决定是否可以通过复制来提高系统性能：

您的系统的读写比率是多少？
如果减少读取，一个服务器可以处理多少更多的写入负载？
您有多少个副本的网络带宽可用？

Answer 9

您如何实现冗余完全取决于您的应用程序和情况。高可用性解决方案（具有自动故障转移）需要活动监控和自定义脚本或第三方工具来提供从原始 MySQL 服务器到副本的故障转移支持。

要手动处理过程，您需要能够从失败的源服务器切换到预配置的副本，通过更改应用程序以与新服务器通信或调整 MySQL 服务器的 DNS 从失败的服务器到新服务器。

有关更多信息和一些示例解决方案，请参阅第 19.4.8 节，“故障转移期间切换源”。

Answer 10

检查 binlog_format 系统变量的值：

mysql> SHOW VARIABLES LIKE 'binlog_format';

显示的值始终是 STATEMENT、ROW 或 MIXED。对于 MIXED 模式，默认情况下使用基于语句的日志记录，但是在某些情况下，例如不安全的语句，复制将自动切换到基于行的日志记录。有关何时可能发生这种情况的信息，请参阅第 7.4.4.3 节，“Mixed Binary Logging Format”。

Answer 11

副本自动知道使用哪种格式。

Answer 12

使用 --replicate-wild-ignore-table=mysql.% 选项启动服务器，以忽略 mysql 数据库中的表的复制。

A.14.1.	副本是否必须始终连接到源?
	不，副本不需要始终连接到源。副本可以关闭或断开连接数小时或数天，然后重新连接并追赶更新。例如，您可以在间歇性连接的拨号链路上设置源/副本关系，在这种情况下，链路仅在短时间内打开。要确保断开连接的副本可以追赶，请不要从源中删除包含尚未复制到副本的信息的二进制日志文件。异步复制只能在副本可以继续从最后读取事件的点继续读取二进制日志的情况下工作。
A.14.2.	是否必须在源和副本上启用网络以启用复制？
	是的，在源和副本上必须启用网络。如果没有启用网络，副本无法连接到源并传输二进制日志。请验证在服务器配置文件中没有启用`skip_networking`系统变量。
A.14.3.	如何知道副本相比源的延迟？换言之，如何知道副本最后复制的语句的日期？
	检查`SHOW REPLICA \| SLAVE STATUS`输出中的`Seconds_Behind_Master`列。请参阅第 19.1.7.1 节，“检查复制状态”。当复制 SQL 线程执行从源读取的事件时，它将自己的时间修改为事件时间戳。（这就是为什么`TIMESTAMP`可以正确复制的原因。）在`SHOW PROCESSLIST`输出的`Time`列中，显示的秒数是最后复制事件的时间戳和副本机器的实际时间之间的秒数。您可以使用此信息来确定最后复制事件的日期。请注意，如果您的副本与源断开连接了一小时，然后重新连接，您可能会在`SHOW PROCESSLIST`中看到大约 3600 的`Time`值。这是因为副本正在执行一小时前的语句。请参阅第 19.2.3 节，“复制线程”。
A.14.4.	如何强制源等待副本追赶更新？
	使用以下过程：在源上执行以下语句： `mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;` 从 SHOW 语句的输出中记录复制坐标（当前二进制日志文件名和位置）。在副本上发出以下语句，其中 SOURCE_POS_WAIT() 或 MASTER_POS_WAIT() 函数的参数是前一步骤中获得的复制坐标值： `mysql> SELECT MASTER_POS_WAIT('log_name', log_pos); 从 MySQL 8.0.26 开始： mysql> SELECT SOURCE_POS_WAIT('log_name', log_pos);` SELECT 语句将阻塞，直到副本达到指定的日志文件和位置。在那时，副本与源同步，语句将返回。在源上发出以下语句，以启用源继续处理更新： `mysql> UNLOCK TABLES;`
A.14.5.	在设置双向复制时，我应该注意什么问题？
	MySQL 复制当前不支持源和副本之间的锁定协议，以保证分布式（跨服务器）更新的原子性。换言之，客户端 A 可以在 co-source 1 上进行更新，而在更新传播到 co-source 2 之前，客户端 B 可以在 co-source 2 上进行更新，使得客户端 A 的更新在 co-source 2 上工作方式不同于在 co-source 1 上。因此，当客户端 A 的更新到达 co-source 2 时，它将生成与 co-source 1 上不同的表，即使所有来自 co-source 2 的更新也已经传播。因此，您不应该将两个服务器链式连接到双向复制关系中，除非您确定您的更新可以安全地以任何顺序发生，或者您在客户端代码中处理了乱序更新。您还应该意识到，双向复制实际上并不会很大地提高性能（如果有的话）。每个服务器都必须执行相同数量的更新，就像单个服务器那样。唯一的区别是，来自另一个服务器的更新将被序列化到一个复制线程中。甚至这种好处也可能被网络延迟所抵消。
A.14.6.	我如何使用复制来提高系统性能？
	将一个服务器设置为源，并将所有写入指令发送到该服务器。然后，配置尽可能多的副本，并将读取分布在源和副本之间。您也可以使用 `--skip-innodb` 选项启动副本，启用 `low_priority_updates` 系统变量，并将 `delay_key_write` 系统变量设置为 `ALL`，以在副本端获得速度改进。在这种情况下，副本使用非事务性的 `MyISAM` 表而不是 `InnoDB` 表，以通过消除事务开销来获得更多速度。
A.14.7.	我需要在自己的应用程序中做什么来准备使用性能增强的复制？
	请参阅使用复制作为扩展解决方案的指南：第 19.4.5 节，“使用 Replication 作为扩展解决方案”。
A.14.8.	MySQL 复制何时和如何提高我的系统性能？
	MySQL 复制对频繁读取和不频繁写入的系统最有益处。在理论上，使用单源/多副本设置，您可以通过添加更多副本来扩展系统，直到您耗尽网络带宽或更新负载增长到源无法处理的程度。要确定您可以使用多少副本之前，性能改善开始平稳，并且您可以通过 benchmarking 来确定读取和写入的关系，了解您的查询模式。例如，假设系统负载由 10% 的写入和 90% 的读取组成，我们通过 benchmarking 确定 `reads` 是 1200 - 2 * `writes`。也就是说，系统可以每秒处理 1,200 次读取，而不进行写入，平均写入速度是平均读取速度的两倍，关系是线性的。假设源和每个副本具有相同的容量，我们有一个源和 `N` 个副本。那么，对于每个服务器（源或副本），我们有： `reads` = 1200 - 2 * `writes` `reads` = 9 * `writes` / (`N` + 1) (读取被分配，但写入被复制到所有副本) 9 * `writes` / (`N` + 1) + 2 * `writes` = 1200 `writes` = 1200 / (2 + 9/(`N` + 1)) 最后一个等式表明了对于 `N` 个副本的最大写入次数，给定每秒 1,200 次的最大读取率和九次读取对一次写入的比例。这个分析得出了以下结论：如果 `N` = 0（这意味着我们没有复制），我们的系统可以处理大约 1200/11 = 109 次写入每秒。如果 `N` = 1，我们可以达到 184 次写入每秒。如果 `N` = 8，我们可以达到 400 次写入每秒。如果 `N` = 17，我们可以达到 480 次写入每秒。最终，当 `N` 接近无穷大时（我们的预算接近负无穷大），我们可以达到近似 600 次写入每秒，系统吞吐量增加了约 5.5 倍。但是，只需要八个服务器，我们就可以将吞吐量增加近四倍。这些计算假设了无限的网络带宽，并忽略了可能对您的系统产生影响的其他因素。在许多情况下，您可能无法进行类似于上述计算，以准确预测添加 `N` 个副本对您的系统性能的影响。但是，回答以下问题可以帮助您决定是否可以通过复制来提高系统性能：您的系统的读写比率是多少？如果减少读取，一个服务器可以处理多少更多的写入负载？您有多少个副本的网络带宽可用？
A.14.9.	如何使用复制来提供冗余或高可用性？
	您如何实现冗余完全取决于您的应用程序和情况。高可用性解决方案（具有自动故障转移）需要活动监控和自定义脚本或第三方工具来提供从原始 MySQL 服务器到副本的故障转移支持。要手动处理过程，您需要能够从失败的源服务器切换到预配置的副本，通过更改应用程序以与新服务器通信或调整 MySQL 服务器的 DNS 从失败的服务器到新服务器。有关更多信息和一些示例解决方案，请参阅第 19.4.8 节，“故障转移期间切换源”。
A.14.10.	我如何知道复制源服务器是否使用基于语句的或基于行的二进制日志格式？
	检查 `binlog_format` 系统变量的值： `mysql> SHOW VARIABLES LIKE 'binlog_format';` 显示的值始终是 `STATEMENT`、`ROW` 或 `MIXED`。对于 `MIXED` 模式，默认情况下使用基于语句的日志记录，但是在某些情况下，例如不安全的语句，复制将自动切换到基于行的日志记录。有关何时可能发生这种情况的信息，请参阅第 7.4.4.3 节，“Mixed Binary Logging Format”。
A.14.11.	如何告诉副本使用基于行的复制？
	副本自动知道使用哪种格式。
A.14.12.	如何防止 `GRANT` 和 `REVOKE` 语句复制到副本机器？
	使用 `--replicate-wild-ignore-table=mysql.%` 选项启动服务器，以忽略 mysql 数据库中的表的复制。
A.14.13.	复制是否可以在混合操作系统上工作（例如，源服务器运行在 Linux 上，而副本运行在 macOS 和 Windows 上）？
	是的。
A.14.14.	复制是否可以在混合硬件架构上工作（例如，源服务器运行在 64 位机器上，而副本运行在 32 位机器上）？
	是的。

A.14 MySQL 8.3 FAQ: Replication