
复制管理和维护
|
223
多源复制
虽然保持复制拓扑简单很重要,但在某些情况下,还是需要使用更高级的功能来处理一
次性需求的。例如,你建立了一个全新的视频上传和观看网站,现在变得很流行。早期
设计决策之一是将有关视频的数据和有关用户的数据分离到两个单独的数据库集群中。
随着业务的成长,有一些数据查询需要将它们重新合并在一起。这时,可以通过多源复
制来完成此操作,以将两个数据集聚集到一个副本中,如图
9-10
所示。
图9-10:多源复制
此功能建立在被称为
复制通道
的概念之上。在前面的示例中,需要使用第三个
MySQL
集群节点。这个新的第三个集群节点将创建两个复制通道 :一个用于视频数据,一个用
于用户数据。一旦加载并复制了数据,你可能需要一个非常短暂的停机时间,在此期间
先停止对两个源服务器的写入,并推送应用代码以切换到新的组合数据库进行读写操作。
至此,你已将两个数据库合并为一个了。
在继续下面的讲解之前,有一个重要的限制需要了解 :不能将一个副本配置为对同一个
源多次使用多源复制。
这种拓扑结构非常适合特殊使用的情况,我们非常不建议长期运行这种架构。暂时使用
它来合并数据是一个可接受的场景,最终目标是回到之前建议的两种架构之一。
复制管理和维护
在数据量很小而且写入负载一致的时候,通常不太需要经常查看复制延迟或者复制中断
相关的问题。但随着数据量的增加,相关的管理和维护工作也会随之而来。
复制监控
复制增加了
MySQL
监控的复杂性。虽然复制实际上同时在源和副本上工作,但大部
分工作都是在副本上完成的,这也是经常发生问题的地方 ...