我们一直想知道为什么我们的一个集群显示分析节点拥有数据。为了便于阅读，我编辑了IP、令牌和主机ID
% nodetool status
Datacenter: Cassandra
=====================
Status=Up/Down|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns Host ID Token Rack
UN 172.32.x.x 46.83 GB 18.5% someguid 0 rack1
UN 172.32.x.x 60.26 GB 33.3% anotherguid ranbignumber rack1
UN 172.32.x.x 63.51 GB 14.8% anothergui ranbignumber rack1
Datacenter: Analytics
=====================
Status=Up/Down|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns Host ID Token Rack
UN 172.32.x.x 28.91 GB 0.0% someguid 100 rack1
UN 172.32.x.a 30.41 GB 33.3% someguid ranbignumber rack1
UN 172.32.x.x 17.46 GB 0.0% someguid ranbignumber rack1那么，ip为172.32.x.a的分析节点是否实际拥有数据？如果是，我们需要备份吗？停用节点是否也会将数据移回相应的节点？
这是我从数据中心分析中的上述nodetool状态中引用的节点：
UN 172.32.x.a 30.41 GB 33.3% someguid ranbignumber rack1再次回答问题（更新后的答案如下）。
我们需要备份这个节点吗？回答：是的
这个节点应该有数据吗？答：是的，否则分析性能将受到影响。
如果不应该有数据，nodetool是否会将数据移回其他节点？回答：没有复制策略可以驱动这一点
以下是的更新 % nodetool status our_important_keyspace ```
Datacenter: Cassandra
Status Address Load Owns (effective)
UN 2 63.16 GB 81.5%
UN 1 47.21 GB 33.3%
UN 3 59.87 GB 85.2%
Datacenter: Analytics
Status Address Load Owns (effective)
UN 3 17.74 GB 33.3%
UN 2 30.62 GB 33.3%
UN 1 29.21 GB 33.3%
今天备份分析-真棒的答案，并可能节省了我们一吨的痛苦。
1条答案
按热度按时间vsaztqbk1#
您需要做的第一件事是使用存储数据的键空间运行nodetool status或dsetool ring。这将向您显示由该键空间的复制策略指定的所有权。您现在看到的很可能是由原始令牌值设置的所有权。如果您的密钥空间被命名为“重要的\u数据”，您将运行“nodetool status important \u data”。
密钥空间上的复制策略是确定哪些节点负责集群中的数据的关键。在任何情况下，多dc群集都应该使用networktopologystrategy，该策略允许指定每个数据中心中应该有多少数据副本。例如，如果您想确保数据在cassandra集群中复制两次，而在analytics集群中只复制一次，那么可以使用类似于{cassandra'：2，'analytics'：1}的网络拓扑策略。这意味着每一个数据段都要在集群范围内复制3次。如果您真的不想将数据复制到analytics节点（这将不利于分析性能），可以设置'analytics:0或者把这句话都省略掉。
您的备份策略应该始终备份至少一个完整的数据副本，但最简单的方法是只备份一个数据中心中的每个节点或至少每个节点（因为您可以从中引导其他节点）
只有当您希望通过复制策略删除该节点时，该节点才会有数据，在这种情况下，在删除该节点时，您将需要停用该节点，就像在群集中删除任何节点一样。大多数用户确实发现在他们的分析数据中心中有副本很有用，因为这样可以在使用各种分析工具时更快地访问。