Cassandra数据中心与簇环关系

Question

我有一个Cassandra集群，在两个数据中心中有8个节点，分别在DC1和DC2中有4-4个节点。

我创建了一个密钥空间：

CREATE KEYSPACE mykeyspace 
  WITH REPLICATION = { 
   'class' : 'NetworkTopologyStrategy', 
   'DC1' : 2,
   'DC2' : 2,
  };

据我所知，DC1和DC2都将拥有所有数据，换句话说，在整个DC1脱机的情况下，DC2将能够服务所有数据。

问题

我们是否应该说，基于先前的事实，DC1和DC2本身都是一个“完整的”环？(关于整个散列-2^63-1 .+2^63将由DC1上的节点表示，对于DC2也是如此)

我为什么要问这个？

我的答案是不，这仍然是一个集群，所以一个环，不管有两个节点子集，其中包含所有的数据。然而，许多图像和插图用两个“圆”表示两个数据中心中的节点，这意味着两个“环”一词。(显然不是两组)

例如，见：

DataStax:多个数据中心写入请求

PS:如果有可能的话，不要给画面带来一致的程度。我理解，节点间通信工作流取决于操作是写还是读，也取决于一致性级别。

取决于答案的实用问题：

在DC1 num_tokens: 256中表示所有节点，DC2 num_tokens: 32表示所有节点。如果8节点在一个令牌环中，则这些数字是相对的，但如果DC1和DC2是两个独立的令牌环，则这些数字(256和32)与彼此无关.

Answer 1

听着，如果你使用SimpleStrategy，它只是一个环。如果使用NetworkTopology，看起来就像两个或更多个环。您可以使用nodetool ring查看令牌与节点之间的关系，使用nodetool getendpoints keyspace table partition_key查看分区密钥的位置。

[root@ip-20-0-1-226 ~]# nodetool ring

Datacenter: dc1
==========
Address     Rack        Status State   Load            Owns                Token
                                                                           8037128101152694619
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              -9050061154907259251
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              -8877859671879922723
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              -8871087231721285506
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              -8594840449446657067
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              -2980375791196469732
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              -2899706862324328975
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              -2406342150306062345
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              -2029972788998320465
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              -1666526652028070649
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              1079561723841835665
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              1663305819374808009
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              4099186620247408174
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              5181974457141074579
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              6403842400328155928
20.0.1.226  rack2       Up     Normal  608.99 MiB      58.34%              6535209989509674611
20.0.1.50   rack1       Up     Normal  456.32 MiB      41.66%              8037128101152694619

[root@ip-20-0-1-44 ~]# nodetool ring

Datacenter: dc1
==========
Address     Rack        Status State   Load            Owns                Token
                                                                           8865515588426899552
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             -5830638745978850993
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             -4570936939416887314
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             -4234199013293852138
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             -3212848663801274832
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             -2683544040240894822
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             6070021776298348267
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             7319793018057117390
20.0.1.44   rack1       Up     Normal  337.81 MiB      100.00%             8865515588426899552

Datacenter: dc2
==========
Address     Rack        Status State   Load            Owns                Token
                                                                           7042359221330965349
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             -6507323776677663977
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             -2315356636250039239
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             -2097227748877766854
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             -630561501032529888
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             2580829093211157045
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             4687230732027490213
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             4817758060672762980
20.0.1.150  rack1       Up     Normal  323.66 MiB      100.00%             7042359221330965349

[root@ip-20-0-1-44 ~]# nodetool getendpoints qa eventsrawtest "host1","2019-03-29","service1"
20.0.1.150
20.0.1.44

CREATE KEYSPACE qa WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '1', 'dc2': '1'}  AND durable_writes = true;
CREATE TABLE eventsrawtest (
        host text,
        bucket_time text,
        service text,
        time timestamp,
        metric double,
        state text,
        PRIMARY KEY ((host, bucket_time, service), time)
  ) WITH CLUSTERING ORDER BY (time DESC)

Answer 2

简短的回答是:两个DC都有两个副本。然后为你的数据复制4个副本。

Cassandra非常聪明，能够理解您的拓扑结构并分发数据。

同样重要的是在机架之间分发数据(机架感知)，因为卡桑德拉将在每个机架上编写一个副本。然后，您将确保您的数据是分散的，并且您可以在不丢失数据的情况下释放多达6个节点(考虑所有包含上述复制因子的关键空间)。

DC1
- rack1
-- 2 nodes
- rack2
-- 2 nodes

DC2
- rack1
-- 2 nodes
- rack2
-- 2 nodes

最后，可以在DC之间拥有不同的num_tokens。它不会影响复制因素。如果您可以检查doc，建议使用一个较小的值。启动/Production.html