Nam*_*pta 3 cassandra datastax scylla
前天,我使用下面的命令在5节点Cassandra集群中的一个节点上为单个表发出了完整的顺序修复.
nodetool repair -full -seq -tr <keyspace> <table> > <logfile>
现在,发出命令的节点已正确修复,可以从下面的命令中获取
nodetool cfstats -H <keyspace.columnFamily>
然而,对于其他节点,不能说同样的,因为我得到了修复%的随机值,显着更小.
我不确定这里发生了什么,看起来像是为密钥空间修复的唯一节点,列系列是发出修复命令的节点.对此处可能发生的事情或如何正确调查问题的猜测
谢谢 !
你说你的集群有5个节点,但没有你用于表的复制因子(RF) - 我假设你使用了常见的RF = 3.当RF = 3时,每个数据在五个节点上复制3次.
您遗漏的关键点是,在这样的设置中,每个特定节点都不包含所有数据.它包含多少总数据？让我们做一些简单的数学运算:如果插入表中的实际数据量是X,那么集群存储的数据总量是3*X(因为RF = 3,每个数据有三个副本).该总数分布在5个节点上,因此每个节点将保持(3*X)/ 5,即3/5*X.
当您在一个特定节点上开始修复时,它仅修复此节点所具有的数据,即我们刚刚计算的数据,即总数据的3/5.此修复对此节点保存的每个数据执行的操作是,将此数据与其他副本保留的副本进行比较,修复不一致并修复所有这些副本.这意味着当修复结束时,在我们修复的节点中,所有数据都被修复了.但对于其他节点,并非所有数据都被修复 - 只是与启动此修复的节点相交的部分.这个交叉点应该大约是3/5*3/5或36%的数据(当然一切都是随机分布的,所以你可能得到的数字接近36%,但不是36%).
正如您现在可能意识到的那样,这意味着"nodetool repair"不是群集范围的操作.如果在一个节点上启动它,则只保证修复一个节点上的所有数据,并且可以在其他节点上修复较少的数据.因此,您必须分别在每个节点上运行修复.
现在您可能会问:既然修复节点1也修复了节点2的36%,那么修复节点2也不是浪费,因为我们已经完成了36%的工作吗？实际上,这是一种浪费.所以Cassandra有一个修复选项"-pr"("主要范围"),它确保每个数据的3个副本中只有一个会修复它.RF = 3时,"nodetool repair -pr"将比没有"-pr"快三倍; 您仍然需要在每个节点上单独运行它,并且当所有节点完成后,您的数据将在所有节点上100%修复.
所有这些都相当不方便,并且在长时间维修期间也难以从瞬态故障中恢复.这就是为什么两个商业Cassandra产品 - 来自Datastax和ScyllaDB - 提供了一个单独的修复工具,比"nodetool修复"更方便,确保整个集群以最有效的方式进行修复,并从瞬态问题中恢复从一开始就重做冗长的修复过程.