
跨集群数据镜像
|
127
这种方案非常复杂,我认为并不值得投入额外的时间。在索引还没有出现之前,或许可
以考虑使用这种方案。但在今天,我倾向于将集群升级到新版本,并使用基于时间戳的
解决方案,而不是进行偏移量映射,更何况偏移量映射并不能覆盖所有的失效备援场景。
3.
在失效备援之后
假设失效备援进行得很顺利,灾备集群也运行得很正常,现在需要对主集群做一些改动,
比如把它变成灾备集群。
如果能够通过简单地改变镜像进程的方向,让它将数据从新的主集群镜像到旧的主集群上
面,事情就完美了!不过,这里还存在两个问题。
•
怎么知道该从哪里开始镜像?我们同样需要解决与镜像程序里的消费者相关的问题。而
且不要忘了,所有的解决方案都有可能出现重复数据或者丢失数据,或者两者兼有。
•
之前讨论过,旧的主集群可能会有一些数据没有被镜像到灾备集群上,如果在这个时
候把新的数据镜像回来,那么历史遗留数据还会继续存在,两个集群的数据就会出现
不一致。
基于上述的考虑,最简单的解决方案是清理旧的主集群,删掉所有的数据和偏移量,然后
从新的主集群上把数据镜像回来,这样可以保证两个集群的数据是一致的。
4.
关于集群发现
在设计灾备集群时,需要考虑一个很重要的问题,就是在发生失效备援之后,应用程序
需要知道如何与灾备集群发起通信。不建议把主集群的主机地址硬编码在生产者和消费
者的配置属性文件里。大多数组织为此创建了
DNS
别名,将其指向主集群,一旦发生紧
急情况,可以将其指向灾备集群。有些组织则使用服务发现工具,比如
Zookeeper
、
Etcd