A.14 MySQL 5.7 常见问题：复制

在以下部分中，我们提供有关 MySQL 复制最常见问题的答案。


**A.14.1. **		从机必须始终连接到主机吗？
不，不是。从站可能会停机或断开连接达数小时甚至几天，然后重新连接并追上更新。例如，您可以在拨号链接上构建主/从关系，该链接仅在短时间内临时打开。这意味着在任何给定的时间，除非采取某些特殊措施，否则都不能保证从机与主机同步。
为确保已断开连接的从属服务器可以发生追赶，您不得从主服务器中删除包含尚未复制到从属服务器的信息的二进制日志文件。仅当从属服务器能够从上次读取事件的位置 continue 读取二进制日志时，异步复制才能起作用。

**A.14.2. **		我必须在主服务器和从服务器上启用网络才能启用复制吗？
是的，必须在主服务器和从服务器上启用网络连接。如果未启用联网，则从站无法连接到主站，也无法传输二进制日志。验证是否在任一服务器的配置文件中都启用了skip_networking系统变量。

**A.14.3. **		我如何知道从属设备与主设备的比较时间？换句话说，我怎么知道从站复制的最后一条语句的日期？
在显示从站状态的输出中检查Seconds_Behind_Master列。参见第 16.1.7.1 节“检查复制状态”。
当从 SQL 线程执行从主线程读取的事件时，它将自己的时间修改为事件时间戳。 (这就是为什么TIMESTAMP被很好地复制的原因。)在SHOW PROCESSLIST的输出的Time列中，从属 SQL 线程显示的秒数是上次复制事件的时间戳与从属时间之间的秒数。机。您可以使用它来确定上次复制事件的日期。请注意，如果您的从属服务器已与主服务器断开连接一小时，然后重新连接，您可能会立即看到较大的Time值，例如SHOW PROCESSLIST中的从属 SQL 线程的 3600.这是因为从服务器正在执行一个小时的语句。参见第 16.2.2 节“复制实现的详细信息”。

**A.14.4. **		如何强制主机阻止更新，直到从机赶上？
使用以下过程：
在主服务器上，执行以下语句：
mysql>带有读取锁的刷新 table；
mysql>显示主状态；
从SHOW语句的输出中记录复制坐标(当前的二进制日志文件名和位置)。
在从属服务器上，发出以下语句，其中MASTER_POS_WAIT()函数的参数是在上一步中获得的复制坐标值：
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);
SELECT语句将阻塞，直到从站到达指定的日志文件和位置为止。此时，从服务器与主服务器同步，并且语句返回。
在主机上，发出以下语句以使主机能够再次开始处理更新：
mysql> UNLOCK TABLES;

**A.14.5. **		设置双向复制时应注意哪些问题？
MySQL 复制当前不支持主服务器和从服务器之间的任何锁定协议，以保证分布式(跨服务器)更新的原子性。换句话说，Client 端 A 可以对协同主服务器 1 进行更新，与此同时，在 Client 端 A 传播到协同主服务器 2 之前，Client 端 B 可以对协同主服务器 2 进行更新，从而对协同主服务器 2 进行更新。Client 端 A 的工作与在协同主服务器 1 上所做的工作不同。因此，当 Client 端 A 的更新使其成为协同主服务器 2 时，即使在所有更新之后，它生成的 table 也与协同主服务器 1 的 table 不同来自共同主人 2 的消息也传播了。这意味着除非您确定可以安全地以任何 Sequences 进行更新，或者除非您在 Client 端代码中以某种方式处理了错误排列的更新，否则不要将两个服务器以双向复制关系链接在一起。
您还应该认识到，就更新而言，双向复制实际上并不能显着提高性能(如果有的话)。每个服务器必须执行相同数量的更新，就像您要使用单个服务器一样。唯一的区别是锁争用要少一些，因为源于另一台服务器的更新是在一个从属线程中序列化的。即使这样的好处也可能被网络延迟所抵消。

**A.14.6. **		我如何使用复制来提高系统性能？
将一台服务器设置为主服务器，然后将所有写入操作定向到该服务器。然后根据预算和机架空间配置尽可能多的从站，并在主站和从站之间分配读取值。您也可以使用--skip-innodb选项启动从站，启用low_priority_updates系统变量，并将delay_key_write系统变量设置为ALL以提高从站端的速度。在这种情况下，从属服务器使用非事务处理的MyISAMtable 而不是InnoDBtable 来消除事务开销，从而提高了速度。

**A.14.7. **		我应该怎么做才能在自己的应用程序中准备 Client 端代码以使用增强性能的复制？
请参阅将复制用作横向扩展解决方案的指南第 16.3.4 节“使用复制进行横向扩展”。

**A.14.8. **		MySQL 复制何时，在多大程度上可以提高系统性能？
MySQL 复制对于处理频繁读取和不频繁写入的系统最为有益。从理论上讲，通过使用单主机/多从机设置，您可以通过添加更多从机来扩展系统，直到用尽网络带宽或更新负载增长到主机无法处理的程度。
要确定在增加的收益开始趋于稳定之前可以使用多少个从站，以及可以提高站点的性能，您必须了解您的查询模式，并通过对读取和写入的吞吐量之间的关系进行基准测试来确定经验典型的主机和典型的从机。此处的示例显示了对假设系统的复制可以得到的相当简化的计算。令reads和writes分别 table 示每秒的读取和写入次数。
假设系统负载由 10％的写入和 90％的读取组成，并且我们已通过基准测试确定reads为 1200-2 * writes。换句话说，该系统每秒可以进行 1200 次读取而无需写入，平均写入速度是平均读取速度的两倍，并且该关系是线性的。假设主机和每个从机具有相同的容量，并且我们有一个主机和* N 从机。然后，对于每个服务器(主服务器或从服务器)，我们都有：
reads = 1200-2 * writes
reads = 9 * writes /( N * 1)(读取被拆分，但写入被复制到所有从站)
9 * writes /(* N * 1)2 * writes = 1200
writes = 1200 /(2 9 /(* N * 1))
最后一个方程式 table 示* N 从站的最大写入数，给定最大可能的读取速率为每秒 1200，并且每次写入的比率为九次读取。
该分析得出以下结论：
如果 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数据库中 table 的复制。

**A.14.13. **		复制是否可以在混合 os 上工作(例如，主服务器在 Linux 上运行，而从服务器在 OS X 和 Windows 上运行)？
Yes.

** A.14.14. *		复制是否可以在混合硬件体系结构上工作(例如，主服务器在 64 位计算机上运行，而从服务器在 32 位计算机上运行)？
Yes.
Name MySql 中文文档
Version
Language
Badge
Last Updated 2021-07-03T12:24:35