Question

A.14.1.

副本是否必须始终连接到源服务器？

Answer 1

不，副本不需要始终连接到源服务器。副本可以关闭或断开连接数小时或数天，然后重新连接并追赶更新。例如，您可以在拨号链路上设置源/副本关系，该链路仅间歇性地打开并保持短时间打开。这种情况的隐含意思是，除非您采取一些特殊措施，否则副本在任何给定时间点不保证与源服务器同步。

为了确保断开连接的副本可以追赶，源服务器不得删除包含尚未复制到副本的信息的二进制日志文件。异步复制只能在副本能够继续从上次读取事件的点继续读取二进制日志时工作。

Answer 2

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

Answer 3

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

当复制 SQL 线程执行从源服务器读取的事件时，它将自己的时间修改为事件时间戳。（这就是为什么 TIMESTAMP 能够正确复制的原因。）在 Time 列中，SHOW PROCESSLIST 输出中，显示的秒数是最后复制事件的时间戳和副本机器的实际时间之间的秒数。您可以使用它来确定最后复制事件的日期。请注意，如果您的副本与源服务器断开连接了一小时，然后重新连接，您可能会在 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);

Or from 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 上不同的表。因此，您不应该将两个服务器链式连接在一起，除非您确定您的更新可以在任何顺序下安全地发生，或者您在客户端代码中采取措施来处理乱序更新。

你也应该意识到双向复制实际上并不能提高性能很多（如果有的话），因为每个服务器都需要执行相同数量的更新，就像你在单个服务器上执行一样。唯一的区别是由于来自另一个服务器的更新被序列化在一个复制线程中，因此锁定争用减少了一些。即使这种好处也可能被网络延迟所抵消。

Answer 6

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

Answer 7

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

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 节，“混合二进制日志记录格式”。

Answer 11

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

Answer 12

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

A.14.1.	副本是否必须始终连接到源服务器？
	不，副本不需要始终连接到源服务器。副本可以关闭或断开连接数小时或数天，然后重新连接并追赶更新。例如，您可以在拨号链路上设置源/副本关系，该链路仅间歇性地打开并保持短时间打开。这种情况的隐含意思是，除非您采取一些特殊措施，否则副本在任何给定时间点不保证与源服务器同步。为了确保断开连接的副本可以追赶，源服务器不得删除包含尚未复制到副本的信息的二进制日志文件。异步复制只能在副本能够继续从上次读取事件的点继续读取二进制日志时工作。
A.14.2.	是否必须在源服务器和副本上启用网络以启用复制？
	是的，在源服务器和副本上必须启用网络。如果没有启用网络，副本无法连接到源服务器并传输二进制日志。请验证 `skip_networking` 系统变量未在服务器配置文件中启用。
A.14.3.	如何知道副本相比源服务器的延迟？换言之，如何知道副本最后复制的语句的日期？
	检查 `Seconds_Behind_Master` 列在 `SHOW REPLICA \| SLAVE STATUS` 输出中。请参阅第 19.1.7.1 节，“检查复制状态”。当复制 SQL 线程执行从源服务器读取的事件时，它将自己的时间修改为事件时间戳。（这就是为什么 `TIMESTAMP` 能够正确复制的原因。）在 `Time` 列中，`SHOW PROCESSLIST` 输出中，显示的秒数是最后复制事件的时间戳和副本机器的实际时间之间的秒数。您可以使用它来确定最后复制事件的日期。请注意，如果您的副本与源服务器断开连接了一小时，然后重新连接，您可能会在 `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); Or from 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 上不同的表。因此，您不应该将两个服务器链式连接在一起，除非您确定您的更新可以在任何顺序下安全地发生，或者您在客户端代码中采取措施来处理乱序更新。你也应该意识到双向复制实际上并不能提高性能很多（如果有的话），因为每个服务器都需要执行相同数量的更新，就像你在单个服务器上执行一样。唯一的区别是由于来自另一个服务器的更新被序列化在一个复制线程中，因此锁定争用减少了一些。即使这种好处也可能被网络延迟所抵消。
A.14.6.	如何使用复制来提高系统性能？
	将一个服务器设置为源服务器，并将所有写操作指向它。然后，配置尽可能多的副本，并将读取分布在源服务器和副本之间。你也可以使用 `--skip-innodb` 选项，启用 `low_priority_updates` 系统变量，并将 `delay_key_write` 系统变量设置为 `ALL`，以在副本端获得速度改进。在这种情况下，副本使用非事务 `MyISAM` 表而不是 `InnoDB` 表，以消除事务开销。
A.14.7.	我应该如何准备客户端代码，以便在自己的应用程序中使用性能增强的复制？
	请参阅使用复制作为扩展解决方案的指南，第 19.4.5 节，“使用复制进行扩展”。
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 节，“混合二进制日志记录格式”。
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.4 FAQ: 复制