复制
A.14.1。 | 从站是否必须一直连接到主站? |
不,不是的。从站可能会停机或断开连接达数小时甚至几天,然后重新连接并追上更新。例如,您可以在拨号链接上建立主/从关系,该链接仅在短时间内临时打开。这意味着在任何给定的时间,除非采取一些特殊措施,否则都不能保证从机与主机同步。 为确保已断开连接的从属服务器可以发生追赶,您不得从主服务器中删除包含尚未复制到从属服务器的信息的二进制日志文件。仅当从属服务器能够从上次读取事件的位置继续读取二进制日志时,异步复制才能起作用。 | |
A.14.2。 | 我必须在主服务器和从服务器上启用网络才能启用复制吗? |
是的,必须在主站和从站上启用网络。如果未启用联网,则从站无法连接到主站,也无法传输二进制日志。验证是否 | |
A.14.3。 | 我怎么知道奴隶比主人晚?换句话说,我怎么知道从站复制的最后一条语句的日期? |
检查的 当从SQL线程执行从主线程读取的事件时,它将自己的时间修改为事件时间戳。(这就是为什么 | |
A.14.4。 | 如何强制主机阻止更新,直到从机赶上来? |
使用以下过程:
| |
A.14.5。 | 设置双向复制时应注意哪些问题? |
MySQL复制当前不支持主服务器和从服务器之间的任何锁定协议,以保证分布式(跨服务器)更新的原子性。换句话说,客户端A可以对协同主服务器1进行更新,与此同时,在客户端A传播给协同主服务器2之前,客户端B可以对协同主服务器2进行更新,从而对协同主服务器2进行更新。客户端A的工作与在协同主服务器1上所做的工作不同。因此,当客户端A的更新使其成为协同主服务器2时,即使在所有更新之后,它生成的表也与协同主服务器1的表不同来自共同主人2的消息也传播了。 您还应该认识到,就更新而言,双向复制实际上并不能显着提高性能(如果有的话)。每个服务器必须执行相同数量的更新,就像您要使用单个服务器一样。唯一的区别是锁争用要少一些,因为源于另一台服务器的更新是在一个从属线程中序列化的。即使是这种好处,也可能被网络延迟所抵消。 | |
A.14.6。 | 如何使用复制来提高系统性能? |
将一台服务器设置为主服务器,然后将所有写操作定向到该服务器。然后根据预算和机架空间配置尽可能多的从站,并在主站和从站之间分配读取值。您也可以使用该 | |
A.14.7。 | 我应该如何准备自己的应用程序中的客户端代码以使用性能增强复制? |
请参见将复制用作横向扩展解决方案的指南,“使用复制进行横向扩展”。 | |
A.14.8。 | MySQL复制何时,在什么程度上可以提高系统性能? |
MySQL复制对于处理频繁读取和不频繁写入的系统最为有益。从理论上讲,通过使用单主机/多从机设置,您可以通过添加更多从机来扩展系统,直到用尽网络带宽或更新负载增长到主机无法处理的程度。 为了确定在增加的收益开始趋于稳定之前可以使用多少个从站,以及可以提高站点性能的多少,您必须了解您的查询模式,并通过对读取和写入的吞吐量之间的关系进行基准测试来确定经验典型的主机和典型的从机。此处的示例显示了对假设系统的复制所能获得的相当简化的计算。令 假设系统负载由10%的写入和90%的读取组成,而我们通过基准测试确定
*
最后一个方程式表示从机的最大写入数 该分析得出以下结论:
这些计算假设网络带宽是无限的,而忽略了可能对您的系统很重要的其他因素。在许多情况下,您可能无法执行与刚刚显示的那样的计算,该计算无法准确预测如果添加
| |
A.14.9。 | 如何使用复制来提供冗余或高可用性? |
实施冗余的方式完全取决于您的应用程序和情况。高可用性解决方案(具有自动故障转移)需要主动监控以及自定义脚本或第三方工具,以提供从原始MySQL服务器到从属服务器的故障转移支持。 要手动处理该过程,您应该能够通过更改应用程序以与新服务器通信或将MySQL服务器的DNS从故障服务器更改为新服务器,来从发生故障的主服务器切换到预先配置的从属服务器。 有关更多信息和一些示例解决方案,请参见“故障转移期间切换主服务器”。 | |
A.14.10。 | 如何确定主服务器使用的是基于语句的还是基于行的二进制日志记录格式? |
检查 mysql> 示出的值将是一 | |
A.14.11。 | 如何告诉从站使用基于行的复制? |
从站自动知道要使用哪种格式。 | |
A.14.12。 | 如何防止 |
使用 | |
A.14.13。 | 复制是否可以在混合操作系统上工作(例如,主服务器在Linux上运行,而从服务器在OS X和Windows上运行)? |
是。 | |
A.14.14。 | 复制是否可以在混合硬件体系结构上工作(例如,主服务器在64位计算机上运行,而从服务器在32位计算机上运行)? |
是。 |