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

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

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

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

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

使用以下步骤：

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 上不同的表，即使所有来自 co-source 2 的更新也已经传播。因此，除非您确定更新可以安全地以任何顺序发生，否则您不应该将两个服务器链式连接在双向复制关系中，或者您需要在客户端代码中处理mis-ordered 更新。

您还应该意识到，双向复制实际上并不会对性能产生很大的改善（如果有的话）。每个服务器都需要执行相同数量的更新，就像单个服务器那样。唯一的区别是，来自另一个服务器的更新将在一个复制线程中序列化。这一点可能会被网络延迟所抵消。

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

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

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 个副本对系统性能的影响。然而，回答以下问题可以帮助您决定是否可以通过复制来提高系统性能：

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

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

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

检查 binlog_format 系统变量的值：

mysql> 显示 VARIABLES LIKE 'binlog_format';

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

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

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

是的。

是的。