我们有三个区域用于cassandra集群,每个集群有2个节点,共6个 . 然后我们又添加了3个区域,现在我们在集群中有12个cassandra节点 . 添加节点后,我们更新了复制因子并启动了nodetool修复 . 但是这个命令已经挂了48个多小时还没完成 . 当我们查看日志1或2时,AntiEntropySessions仍在等待,因为某些CF未完全同步 . 所有AntiEntropySessions都成功地从所有节点的所有节点获取merkle树 . 但是有些维修不知道某些节点没有为某些节点完成,因此它会导致挂起的AntiEntropySessions并且修复处于挂起状态 .
我们正在使用Cassandra 1.1.12 . 我们现在无法升级Cassandra . 我们已重新启动节点并再次启动修复,但它仍然挂起 . 我们观察到一个CF在初始3个区域中频繁读写,这些区域在修复过程中处于活动状态,并且在所有时间都未能完全同步 .
是否有必要在运行修复时不应该在任何CF中进行任何读/写操作?或者建议我这里有什么问题?
1 回答
Cassandra 1.1很老,所以很难记住确切的问题,但是流式传输存在问题,可能会挂起 . 有些原因是如果读取超时或连接被重置 . 虽然你已经过了1.1.11但是你可以尝试进行子修复 .
尝试找到一个适当的令牌范围,您可以在一小时内修复(继续运行越来越小的范围,直到您可以完成它),设置几个小时的超时 . 期望一些修复失败(超时),所以只需重试它们直到它们完成 . 如果你在多次重试之后无法获得它继续使该子范围变小,但即使这样,如果你有一个非常宽的分区(可以检查
nodetool cfstats
)会使它变得更糟,它可能会有问题 .一旦完成修复,就像疯了一样升级 .