Question

A.14.1。

副本必须一直连接到源吗？

Answer 1

不，不是的。副本可能会关闭或保持断开连接数小时甚至数天，然后重新连接并赶上更新。例如，您可以通过拨号链接设置源/副本关系，其中该链接只是偶尔和短时间。这意味着，在任何给定时间，副本都不能保证与源同步，除非您采取一些特殊措施。

为确保已断开连接的副本可以发生追赶，您不得从源中删除包含尚未复制到副本的信息的二进制日志文件。仅当副本能够从上次读取事件的位置继续读取二进制日志时，异步复制才能工作。

Answer 2

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

Answer 3

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

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

Answer 4

使用以下过程：

在源上，执行以下语句：
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
```
SHOW记录语句输出中的复制坐标（当前二进制日志文件名和位置）。
在副本上，发出以下语句，其中 SOURCE_POS_WAIT()or 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 有可能对协同源 1 进行更新，同时，在它传播到协同源 2 之前，客户端 B 可以对协同源 2 进行更新，从而更新客户端 A 的工作方式与它在共同源 1 上的工作方式不同。因此，当客户端 A 的更新使其成为共同源 2 时，它生成的表与您在共同源 1 上的表不同，即使在所有更新之后也是如此来自共同来源 2 的内容也已传播。

您还应该意识到，就更新而言，双向复制实际上并没有提高多少性能（如果有的话）。每个服务器必须执行相同数量的更新，就像您让单个服务器执行的操作一样。唯一的区别是锁争用稍微少一些，因为源自另一台服务器的更新在一个复制线程中序列化。即使是这种好处也可能会被网络延迟所抵消。

Answer 6

将一台服务器设置为源并将所有写入定向到它。然后根据预算和机架空间配置尽可能多的副本，并在源和副本之间分配读取。您还可以使用该 --skip-innodb 选项启动副本，启用 low_priority_updates系统变量，并将 delay_key_write系统变量设置为ALL以提高副本端的速度。在这种情况下，副本使用非事务 MyISAM性表而不是 InnoDB表来通过消除事务性开销来提高速度。

Answer 7

请参阅使用复制作为横向扩展解决方案的指南，第 16.3.4 节，“将复制用于横向扩展”。

Answer 8

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

要确定在增加的好处开始趋于平稳之前您可以使用多少个副本，以及您可以将站点的性能提高多少，您必须了解您的查询模式，并通过对读取和写入的吞吐量之间的关系进行基准测试来凭经验确定一个典型的来源和一个典型的副本。此处的示例显示了一个相当简单的计算，即您可以通过复制为一个假设的系统获得什么。让reads和 writes分别表示每秒读取和写入的次数。

假设系统负载由 10% 的写入和 90% 的读取组成，我们通过基准测试确定 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 次，并且每次写入的比率为 9 次读取。

该分析得出以下结论：

如果N= 0（这意味着我们没有复制），我们的系统每秒可以处理大约 1200/11 = 109 次写入。
如果N= 1，我们每秒最多写入 184 次。
如果N= 8，我们每秒最多写入 400 次。
如果N= 17，我们每秒最多写入 480 次。
最终，随着N接近无穷大（我们的预算为负无穷大），我们可以非常接近每秒 600 次写入，将系统吞吐量提高约 5.5 倍。然而，只有八台服务器，我们将其增加了近四倍。

这些计算假设网络带宽无限大，并忽略了可能对您的系统很重要的其他几个因素。在许多情况下，您可能无法执行与刚才显示的计算类似的计算，该计算无法准确预测添加N 副本后系统上发生的情况。但是，回答以下问题应该可以帮助您确定复制是否可以提高系统性能以及提高多少：

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

Answer 9

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

要手动处理该过程，您应该能够从故障源切换到预配置的副本，方法是更改您的应用程序以与新服务器通信，或者通过将 MySQL 服务器的 DNS 从故障服务器调整到新服务器。

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

Answer 10

检查 binlog_format系统变量的值：

mysql> SHOW VARIABLES LIKE 'binlog_format';

显示的值始终是STATEMENT、 ROW或之一MIXED。对于 MIXED模式，默认情况下使用基于语句的日志记录，但复制在某些情况下会自动切换到基于行的日志记录，例如不安全的语句。有关何时可能发生这种情况的信息，请参阅第 5.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`。请参阅第 16.1.7.1 节，“检查复制状态”。当复制 SQL 线程执行从源读取的事件时，它会将自己的时间修改为事件时间戳。（这就是`TIMESTAMP`复制良好的原因。）在`Time`输出的列中`SHOW PROCESSLIST`，复制 SQL 线程显示的秒数是上次复制事件的时间戳与副本机器的实际时间之间的秒数。您可以使用它来确定上次复制事件的日期。请注意，如果您的副本已与源断开连接一小时，然后重新连接，您可能会立即看到较大 `Time`的值，例如复制 SQL 线程的 3600`SHOW PROCESSLIST`. 这是因为副本正在执行一小时前的语句。请参阅第 16.2.3 节，“复制线程”。
A.14.4.	我如何强制源阻止更新，直到副本赶上？
	使用以下过程：在源上，执行以下语句： `mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;` `SHOW`记录语句输出中的复制坐标（当前二进制日志文件名和位置）。在副本上，发出以下语句，其中 `SOURCE_POS_WAIT()`or `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 有可能对协同源 1 进行更新，同时，在它传播到协同源 2 之前，客户端 B 可以对协同源 2 进行更新，从而更新客户端 A 的工作方式与它在共同源 1 上的工作方式不同。因此，当客户端 A 的更新使其成为共同源 2 时，它生成的表与您在共同源 1 上的表不同，即使在所有更新之后也是如此来自共同来源 2 的内容也已传播。您还应该意识到，就更新而言，双向复制实际上并没有提高多少性能（如果有的话）。每个服务器必须执行相同数量的更新，就像您让单个服务器执行的操作一样。唯一的区别是锁争用稍微少一些，因为源自另一台服务器的更新在一个复制线程中序列化。即使是这种好处也可能会被网络延迟所抵消。
A.14.6.	如何使用复制来提高系统性能？
	将一台服务器设置为源并将所有写入定向到它。然后根据预算和机架空间配置尽可能多的副本，并在源和副本之间分配读取。您还可以使用该 `--skip-innodb` 选项启动副本，启用 `low_priority_updates`系统变量，并将 `delay_key_write`系统变量设置为`ALL`以提高副本端的速度。在这种情况下，副本使用非事务 `MyISAM`性表而不是 `InnoDB`表来通过消除事务性开销来提高速度。
A.14.7。	我应该怎么做才能在我自己的应用程序中准备客户端代码以使用性能增强复制？
	请参阅使用复制作为横向扩展解决方案的指南，第 16.3.4 节，“将复制用于横向扩展”。
A.14.8。	MySQL 复制何时以及在多大程度上可以提高我的系统性能？
	MySQL 复制对于处理频繁读取和不频繁写入的系统最有利。理论上，通过使用单源/多副本设置，您可以通过添加更多副本来扩展系统，直到您用完网络带宽，或者您的更新负载增长到源无法处理的程度。要确定在增加的好处开始趋于平稳之前您可以使用多少个副本，以及您可以将站点的性能提高多少，您必须了解您的查询模式，并通过对读取和写入的吞吐量之间的关系进行基准测试来凭经验确定一个典型的来源和一个典型的副本。此处的示例显示了一个相当简单的计算，即您可以通过复制为一个假设的系统获得什么。让`reads`和 `writes`分别表示每秒读取和写入的次数。假设系统负载由 10% 的写入和 90% 的读取组成，我们通过基准测试确定 `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 次，并且每次写入的比率为 9 次读取。该分析得出以下结论：如果`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 从故障服务器调整到新服务器。有关更多信息和一些示例解决方案，请参阅第 16.3.7 节，“在故障转移期间切换源”。
A.14.10。	如何判断复制源服务器使用的是基于语句还是基于行的二进制日志记录格式？
	检查 `binlog_format`系统变量的值： `mysql> SHOW VARIABLES LIKE 'binlog_format';` 显示的值始终是`STATEMENT`、 `ROW`或之一`MIXED`。对于 `MIXED`模式，默认情况下使用基于语句的日志记录，但复制在某些情况下会自动切换到基于行的日志记录，例如不安全的语句。有关何时可能发生这种情况的信息，请参阅第 5.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 5.7 FAQ：复制