cassandra如何处理新节点（令牌如何重新分配）？_Cassandra

cassandra如何处理新节点（令牌如何重新分配）？

cassandra

cassandra如何处理新节点（令牌如何重新分配）？,cassandra,Cassandra,我最近开始为一个新项目探索卡桑德拉。以下是我对卡桑德拉的理解，这是基于网上的众多博客 Cassandra C*是AP CAP定理，即它具有高可用性和分区容错性 C*是逻辑环拓扑。不是在真正的网络意义上，因为所有节点都可以相互通信，而是在数据复制意义上，数据被复制到相邻节点 C*使用3分区算法将分区键映射到大约-2^63到2^63的整数范围每个节点负责启用几个范围的Vnodes，即。节点1:[2^63到-2^61]，[2^31到2^33]。。。。节点2:[2^61-1到2^59]，[2^33

我最近开始为一个新项目探索卡桑德拉。以下是我对卡桑德拉的理解，这是基于网上的众多博客

Cassandra C*是AP CAP定理，即它具有高可用性和分区容错性 C*是逻辑环拓扑。不是在真正的网络意义上，因为所有节点都可以相互通信，而是在数据复制意义上，数据被复制到相邻节点 C*使用3分区算法将分区键映射到大约-2^63到2^63的整数范围每个节点负责启用几个范围的Vnodes，即。节点1:[2^63到-2^61]，[2^31到2^33]。。。。节点2:[2^61-1到2^59]，[2^33+1到2^35]。。。。现在我的问题是，假设我创建了一个有3个节点且RF=2的集群，那么

在这种情况下，我相信我在这里使用了正确的术语-2^63到2^63将均匀分布在这3个节点中？如果我在这个正在运行的集群中添加另一个节点，会发生什么？我的假设是，C*将重新平衡环，因为它使用一致的散列，因此-2^63到2^63的范围将被重新分配，相应的数据将被复制到新节点。在进行修复之前，不会删除从现有节点复制的数据？当一个节点发生故障时会发生什么？C*是否通过重新分配令牌和移动数据来重新平衡环？令牌是分区键的一个花哨的词吗？分区范围到底意味着什么？就像分区范围1=-2^63到-2^61，分区范围2=-2^61+1到-2^59，依此类推。在闲聊时，人们实际上分享了哪些信息？

很抱歉，如果这些问题看起来很基本，但我花了很长时间，但找不到明确的答案。

我将尝试用简单的方式解释

Cassandra提供了一种简单的配置方法，所有配置都在Cassandra.yaml中完成。您还可以浏览以获得集群中分区的一些图片

让我们从基础开始，现在只使用一个节点，而不是使用三个节点。使用cassandra的默认配置，我们可以在cassandra.yaml文件中获得以下值

num_tokens: 1
initial_token: 0

这意味着只有一个节点，所有分区都将驻留在这一节点上。现在，虚拟节点的概念是，简单地说，cassandra将令牌划分为多个范围，即使没有物理节点。现在，介绍如何在配置文件cassandra.yaml中启用虚拟节点功能。答案是num_标记值

num_tokens: 128
#initial_token: 0

此配置生成128个令牌范围，例如0-10、11-20、20-30等等。保留初始标记的值，这意味着我们希望cassandra能够决定初始标记的值，而无需担心

现在，让我们在集群中添加另一个节点。下面是新节点的简单配置。考虑到第一个节点IP为127.0.0.1，第二个节点IP为127.0.0.2，为简单起见。

num_tokens: 128
#initial_token: 0
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
      - seeds: "127.0.0.1, 127.0.0.2"

我们刚刚在集群中添加了一个新节点，节点1将作为种子节点。num_标记值为128，表示128个标记范围。初始令牌的值被注释，这意味着cassandra将决定初始令牌和范围。数据传输将在新节点加入集群后立即开始

对于第三个节点，配置应如下所示-

num_tokens: 128
#initial_token: 0
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
      - seeds: "127.0.0.1, 127.0.0.2, 127.0.0.3"

因此，第三个节点将共享来自node1的少量令牌范围和来自node2的少量令牌范围

我希望，到目前为止，我们已经得到了问题1和问题2的答案。让我们转到下两个问题

当一个节点宕机时，暗示切换有助于Cassandra保持一致性。剩余2个节点中的任何一个都会保留应该写入已关闭节点的数据提示。一旦节点启动，这些提示将被重放，数据将被写入目标节点。没有必要进行重新划分或重新平衡之类的花哨事情。提示存储在可在cassandra.yaml文件中配置的目录中。默认情况下，将存储3小时的提示，这意味着缺陷节点应在3小时内出现。该值也可在cassandra.yaml文件中配置

hinted_handoff_enabled: true
max_hint_window_in_ms: 10800000 # 3 hours
hints_directory: /home/ubuntu/node1/data/hints

Murruil3Partitioner使用分区键列计算散列，让我们平静下来。还有其他的实践者，比如RandomPartitioner和ByteOrderedPartitioner

下面是八卦信息的输出示例- 您可以浏览下面协议数据中的每个字段

        ubuntu@ds201-node1:~$ ./node1/bin/nodetool gossipinfo
    /127.0.0.1
      generation:1621506507  -- the tiem at this node is boot strapped.
      heartbeat:2323
      STATUS:28:NORMAL,-1316314773810616606 -----status of the node , NORMAL,LEFT,LEAVING,REMOVED,REMOVING.....
      LOAD:2295:110299.0                    -- Disk space usage
      SCHEMA:64:c5c6bdbd-5916-347a-ab5b-21813ab9d135  -- Changes if schema changes
      DC:37:Cassandra                       --- data center of the NODE
      RACK:18:rack1                         --- Rack of the within the datacenter 
      RELEASE_VERSION:4:4.0.0.2284
      NATIVE_TRANSPORT_ADDRESS:3:127.0.0.1
      X_11_PADDING:2307:{"dse_version":"6.0.0","workloads":"Cassandra","workload":"Cassandra","active":"true","server_id":"08-00-27-32-1E-DD","graph":false,"health":0.3}
      NET_VERSION:1:256
      HOST_ID:2:ebd0627a-2491-40d8-ba37-e82a31a95688
      NATIVE_TRANSPORT_READY:66:true
      NATIVE_TRANSPORT_PORT:6:9041
      NATIVE_TRANSPORT_PORT_SSL:7:9041
      STORAGE_PORT:8:7000
      STORAGE_PORT_SSL:9:7001
      JMX_PORT:10:7199
      TOKENS:27:<hidden>

Gossip是在集群中传播数据的广播协议。在cassandra集群中，没有人是高手，同龄人在他们之间传播数据，这有助于他们维护最新信息。节点之间使用gossip协议进行随机通信这种随机性有一些标准。流言只传播节点元数据，而不传播客户端数据

希望这能消除一些疑问。

我将尝试用简单的方式解释

Cassandra提供了一种简单的配置方法，所有配置都在Cassandra.yaml中完成。你也可以通过这张照片集群中的分区

让我们从基础开始，现在只使用一个节点，而不是使用三个节点。使用cassandra的默认配置，我们可以在cassandra.yaml文件中获得以下值

num_tokens: 1
initial_token: 0

num_tokens: 128
#initial_token: 0

此配置生成128个令牌范围，例如0-10、11-20、20-30等等。保留初始标记的值，这意味着我们希望cassandra能够决定初始标记的值，而无需担心

现在，让我们在集群中添加另一个节点。下面是新节点的简单配置。考虑到第一个节点IP为127.0.0.1，第二个节点IP为127.0.0.2，为简单起见。

num_tokens: 128
#initial_token: 0
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
      - seeds: "127.0.0.1, 127.0.0.2"

对于第三个节点，配置应如下所示-

num_tokens: 128
#initial_token: 0
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
      - seeds: "127.0.0.1, 127.0.0.2, 127.0.0.3"

因此，第三个节点将共享来自node1的少量令牌范围和来自node2的少量令牌范围

我希望，到目前为止，我们已经得到了问题1和问题2的答案。让我们转到下两个问题

hinted_handoff_enabled: true
max_hint_window_in_ms: 10800000 # 3 hours
hints_directory: /home/ubuntu/node1/data/hints

Murruil3Partitioner使用分区键列计算散列，让我们平静下来。还有其他的实践者，比如RandomPartitioner和ByteOrderedPartitioner

下面是八卦信息的输出示例- 您可以浏览下面协议数据中的每个字段

        ubuntu@ds201-node1:~$ ./node1/bin/nodetool gossipinfo
    /127.0.0.1
      generation:1621506507  -- the tiem at this node is boot strapped.
      heartbeat:2323
      STATUS:28:NORMAL,-1316314773810616606 -----status of the node , NORMAL,LEFT,LEAVING,REMOVED,REMOVING.....
      LOAD:2295:110299.0                    -- Disk space usage
      SCHEMA:64:c5c6bdbd-5916-347a-ab5b-21813ab9d135  -- Changes if schema changes
      DC:37:Cassandra                       --- data center of the NODE
      RACK:18:rack1                         --- Rack of the within the datacenter 
      RELEASE_VERSION:4:4.0.0.2284
      NATIVE_TRANSPORT_ADDRESS:3:127.0.0.1
      X_11_PADDING:2307:{"dse_version":"6.0.0","workloads":"Cassandra","workload":"Cassandra","active":"true","server_id":"08-00-27-32-1E-DD","graph":false,"health":0.3}
      NET_VERSION:1:256
      HOST_ID:2:ebd0627a-2491-40d8-ba37-e82a31a95688
      NATIVE_TRANSPORT_READY:66:true
      NATIVE_TRANSPORT_PORT:6:9041
      NATIVE_TRANSPORT_PORT_SSL:7:9041
      STORAGE_PORT:8:7000
      STORAGE_PORT_SSL:9:7001
      JMX_PORT:10:7199
      TOKENS:27:<hidden>

希望这能消除一些疑问。

提供更多深度：

令牌范围分配确实有一个随机分量，所以它不是完全均匀的。但是，如果您使用allocate_tokens_for_keyspace，则新的令牌分配算法将接管，并基于指定keyspace的复制因子RF优化未来的范围分配

这里是nodetool环的六行缩写输出，来自一个使用num_令牌=16构建的3节点集群。请注意，范围实际上是定义的起始令牌哈希，一直到下一个起始令牌减1为止：

10.0.0.1  -6595849996054463311
10.0.0.2  -5923426258674511018
10.0.0.2  -5194860430157391004
10.0.0.2  -4076256821118426122
10.0.0.2  -3750110785943336998
10.0.0.3  -3045824679140675270

观察添加第四个节点时发生的情况：

10.0.0.1  -6595849996054463311
10.0.0.2  -5923426258674511018
10.0.0.4  -5711305561631524277
10.0.0.2  -5194860430157391004
10.0.0.4  -4831174780910733952
10.0.0.2  -4076256821118426122
10.0.0.2  -3750110785943336998
10.0.0.4  -3659290179273062522
10.0.0.3  -3045824679140675270

请注意，三个原始节点中每个节点的起始令牌范围保持不变。但在这种特殊情况下，10.0.0.2的范围被平分，后一半被分配到10.0.0.4

请注意，一旦流式传输完成，10.0.0.4上这些范围内的数据仍在10.0.0.2上。如果新节点的引导过程失败，这是出于设计考虑的。一旦情况稳定，您可以通过在原来的三个节点上运行nodetool清理来清除这些数据

当一个节点发生故障时会发生什么？C*是否通过重新分配令牌和移动数据来重新平衡环

当运行nodetool removenode时会发生这种情况。但是，对于一个简单的下行节点，提示存储在其余节点上，一旦下行节点返回，提示将被重播。

提供额外的深度：

10.0.0.1  -6595849996054463311
10.0.0.2  -5923426258674511018
10.0.0.2  -5194860430157391004
10.0.0.2  -4076256821118426122
10.0.0.2  -3750110785943336998
10.0.0.3  -3045824679140675270

观察添加第四个节点时发生的情况：

10.0.0.1  -6595849996054463311
10.0.0.2  -5923426258674511018
10.0.0.4  -5711305561631524277
10.0.0.2  -5194860430157391004
10.0.0.4  -4831174780910733952
10.0.0.2  -4076256821118426122
10.0.0.2  -3750110785943336998
10.0.0.4  -3659290179273062522
10.0.0.3  -3045824679140675270

请注意，三个原始节点中每个节点的起始令牌范围保持不变。但是在在特殊情况下，10.0.0.2上的范围被平分，后半部分被指定为10.0.0.4

当一个节点发生故障时会发生什么？C*是否通过重新分配令牌和移动数据来重新平衡环

当运行nodetool removenode时会发生这种情况。但是对于一个简单的下降节点，提示存储在剩余的节点上，一旦下降节点返回，提示将被重播。

我发现了一些有用的问题，但这些问题并不能完全回答我的问题。就像这里的这个[0]谈到了再平衡，但我仍然不明白C*是否重新分配了范围？[0]：请每个问题只问一个问题。我发现了一些关于SO的有用Q/a，但这些并不能肯定地回答我的问题。就像这里的这个[0]谈到了再平衡，但我仍然不明白C*是否重新分配了范围？[0]：请每个问题只问一个问题。