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

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

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

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

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

请使用以下步骤：

MySQL 复制当前不支持源和副本之间的任何锁定协议来保证分布式（跨服务器）更新的原子性。换句话说，客户端 A 可以对共源 1 进行更新，同时，在它传播到共源 2 之前，客户端 B 可以对共源 2 进行更新，这使得客户端 A 的更新工作方式与其在共源 1 上的工作方式不同。因此，当客户端 A 的更新到达共源 2 时，它会生成与共源 1 上不同的表，即使来自共源 2 的所有更新也已传播之后也是如此。这意味着您不应该将两台服务器链接在一起形成双向复制关系，除非您确定您的更新可以按任何顺序安全地进行，或者除非您在客户端代码中以某种方式处理乱序更新。

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

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

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

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))

最后一个等式表示在每秒最大可能读取速率为 1,200 次和每写入 9 次读取的比率下，N 个副本的最大写入次数。

此分析得出以下结论

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

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

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

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

检查 binlog_format 系统变量的值

mysql> SHOW VARIABLES LIKE 'binlog_format';

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

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

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

是的。

是的。