在构建一个大型应用时,有意让服务器不被充分使用, 这应该是一种聪明并且划算的方式,尤其在使用复制的时候。有多余容量的服务器可以更好地处理负载尖峰,也有更多能力处理慢速查询和维护工作( 如0PTIMIZE TABLE操作),并且能够更好地跟上复制。
试图同时向主-主拓扑结构的两个节点写入来减少复制问题通常是不划算的。分配给每台机器的读负载应该低于50%,否则,如果某台服务器失效,就没有足够的容量了。如果两台服务器都能够独立处理负载,就用不着担心复制的问题了。注: 如果复制线程总是在运行,你可以使用服务器的uptime来代替CONNECTED_TIME的一半。
构建冗余容量也是实现高可用性的最佳方式之一, 当然还有别的方式, 例如,当错误发生时让应用在降级模式下运行,后续会介绍更多的细节。
复制管理和维护
配置复制一般来说不会是需要经常做的工作,除非有很多服务器。但是一旦配置了复制,监控和管理复制拓扑应该成为一项目常工作,不管有多少服务器。
这些工作应该尽量自动化,但不一定需要自己写工具来实现:在后续我们讨论了几个MySQL工具,其中许多都拥有内建的监控复制的能力或插件。