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

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

是的，必须在源服务器和副本上启用网络。如果未启用网络，则副本无法连接到源服务器并传输二进制日志。验证 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。换句话说，系统在没有写入的情况下每秒可以执行 1200 次读取，平均写入速度是平均读取速度的两倍，并且这种关系是线性的。假设源和每个副本具有相同的容量，并且我们有一个源和 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 次且写入与读取之比为九比一的情况下，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 数据库中表的复制。

是的。

是的。