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

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

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

检查Seconds_Behind_Master输出中的列显示REPLICA | SLAVE STATUS。看到第17.1.7.1节，“检查复制状态”。

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

使用以下程序:

MySQL Replication目前不支持源和副本之间的任何锁定协议，以保证分布式（交叉服务器）更新的原子性。换句话说，客户端A可以使更新成为共同源1，并且在此期间，在传播到Co-Source 2之前，客户端B可以对具有更新的CO-Source 2进行更新客户端的工作与CO-Source 1不同1.因此，当客户端A的更新使其成为共源2时，它会产生与您在CO-Source 1中拥有的表不同的表，即使在所有更新之后来自共源2也传播。这意味着您不应该以双向复制关系将两个服务器一起连锁，除非您确定您的更新可以在任何顺序中安全地发生，或者除非您在客户端代码中以某种方式处理错误订购的更新。

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

将一台服务器设置为源服务器，并将所有写操作都指向它。然后，根据您的预算和rackspace配置尽可能多的副本，并在源和副本之间分发读取。控件还可以启动副本——skip-innodb选项，启用low_priority_updates.系统变量，并设置delay_key_write系统变量到全部在副本结束时获取速度改进。在这种情况下，副本使用非横向MyISAM表而不是桌子InnoDB通过消除事务开销来获得更多速度的表。

请参阅使用复制作为扩展解决方案的指南，第17.4.5节“使用缩放的复制”。

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

确定多少副本可以使用增加的好处开始之前水平,多少你可以提高你的网站的性能,你必须知道你的查询模式,确定基准测试吞吐量之间的关系经验的读和写在一个典型的源和一个典型的复制品。这里的示例显示了一个相当简化的计算，可以通过复制假设的系统得到什么。让读和写道分别表示每秒读取和写入的数量。

假设系统负载由10%的写和90%的读组成，我们已经通过基准测试确定了这一点读1200是2 *吗写道。换句话说，系统在不写操作的情况下每秒可以执行1200次读操作，平均写操作的速度是平均读操作的两倍，并且两者之间的关系是线性的。假设源和每个副本具有相同的容量，并且我们有一个源和N副本。然后我们为每个服务器(源或副本):

读= 1200 - 2 *写道

读= 9 *写道/ (N+ 1)(读被分割，但写被复制到所有副本)

9 *写道/ (N+ 1) + 2 *写道= 1200

写道= 1200 /(2 + 9/(N+ 1））

最后一个方程表示最大写入次数N副本，给定最大可能的每秒1200读速率和9读/写的比率。

该分析得出以下结论:

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

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

为了手动处理这个过程，你应该能够通过改变你的应用程序来与新的服务器对话，或者通过调整MySQL服务器的DNS从失败的服务器到新的服务器来从一个失败的源切换到一个预先配置的副本。

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

检查binlog_format.系统变量：

mysql> SHOW VARIABLES LIKE 'binlog_format';

所显示的值始终为之一声明,排,或混合。为混合模式下，默认使用基于语句的日志记录，但在某些条件下(比如不安全的语句)，复制会自动切换到基于行的日志记录。有关何时可能发生这种情况的信息，请参见第5.4.4.3节“混合二进制日志格式”。

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

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

是的。

是的。