Cassandra DB:'replication_factor'最终控制了什么?

时间:2015-04-13 12:47:43

标签: cassandra consistency

我想验证并测试' replication_factor'和Cassandra DB的一致性级别。

我指定了一个群集:' MyCluster01'在两个数据中心有三个节点:RAC1中的DC1(node1,node2),RAC2中的DC2(node3)

结构如下所示:

[root@localhost ~]# nodetool status
Datacenter: DC1
===============
Status=Up/Down |/ State=Normal/Leaving/Joining/Moving

--  Address        Load       Tokens  Owns    Host ID                               Rack

UN  10.0.0.62  409.11 KB  256     ?       59bf9a73-45cc-4f9b-a14a-a27de7b19246  RAC1

UN  10.0.0.61  408.93 KB  256     ?       b0cdac31-ca73-452a-9cee-4ed9d9a20622  RAC1
Datacenter: DC2
===============
Status=Up/Down |/ State=Normal/Leaving/Joining/Moving

--  Address        Load       Tokens  Owns    Host ID                               Rack

UN  10.0.0.63  336.34 KB  256     ?       70537e0a-edff-4f48-b5db-44f623ec6066  RAC2

然后,我创建了一个键空间和表格,如下所示:

CREATE KEYSPACE my_check1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'};
create table replica_test(id uuid PRIMARY KEY);

    After I inserted one record into that table: 
insert into replica_test(id) values (uuid());
select * from replica_test;
 id
--------------------------------------
 5e6050f1-8075-4bc9-a072-5ef24d5391e5

我得到了那个记录。

但当我停止node1 并在节点2和节点3中再次查询时, 没有查询成功。

select * from replica_test;

Traceback (most recent call last):   File "/usr/bin/cqlsh", line 997,
in perform_simple_statement
    rows = self.session.execute(statement, trace=self.tracing_enabled)   File
"/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.3.post.zip/cassandra-driver-2.1.3.post/cassandra/cluster.py",
line 1337, in execute
    result = future.result(timeout)   File "/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.3.post.zip/cassandra-driver-2.1.3.post/cassandra/cluster.py",
line 2861, in result
    raise self._final_exception Unavailable: code=1000 [Unavailable exception] message="Cannot achieve consistency level ONE"
info={'required_replicas': 1, 'alive_replicas': 0, 'consistency':
'ONE'}

虽然节点工具状态为'命令返回:

UN  10.0.0.62  409.11 KB  256     ?       59bf9a73-45cc-4f9b-a14a-a27de7b19246  RAC1

DN  10.0.0.61  408.93 KB  256     ?       b0cdac31-ca73-452a-9cee-4ed9d9a20622  RAC1

UN  10.0.0.63  336.34 KB  256     ?       70537e0a-edff-4f48-b5db-44f623ec6066  RAC2

当我尝试停止节点2时,保持节点1和3活着;或者停止节点3,使节点1和2保持活动状态;也发生了错误。

那么问题是什么,因为我认为我已经满足了一致性水平,这个记录究竟存在于哪里?

2 个答案:

答案 0 :(得分:4)

  

最终做什么' replication_factor'控制?

要直接回答问题,复制因子(RF)控制群集或数据中心(DC)中存在的每个数据分区的副本数。在您的情况下,您有3个节点,RF为1.这意味着当一行写入您的群集时,它只存储在一个节点上。这也意味着您的群集无法承受单个节点的故障。

相反,在3节点集群上考虑RF为3。这样的集群可以承受1或2个节点的故障,并且仍然能够支持对其所有数据的查询。

启动并运行所有节点后,请尝试以下命令:

nodetool getendpoints my_check1 replica_test 5e6050f1-8075-4bc9-a072-5ef24d5391e5

这将告诉您密钥5e6050f1-8075-4bc9-a072-5ef24d5391e5的数据驻留在哪个节点上。我的第一个想法是,你是丢弃唯一拥有此密钥的节点,然后尝试查询它。

我的第二个想法与卡罗在回答中所说的相呼应。您正在使用2个DC,which is really not supported with the SimpleStrategy。将SimpleStrategy与多个DC一起使用可能会产生不可预测的结果。此外,对于多个DC,您需要使用NetworkTopologyStrategy和默认SimpleSnitch以外的其他内容。否则,Cassandra可能无法找到完成操作的正确节点。

首先,re-create your keyspace and table with the NetworkTopologyStrategy。然后将您的告警(在cassandra.yaml中)更改为网络感知的小报,重新启动您的节点,然后再次尝试此练习。

答案 1 :(得分:1)

在跨多个DC复制时应使用

NetworkTopologyStrategy