Cassandra DB: Что в конечном итоге контролирует «replication_factor»?

Question

Я хочу проверить и протестировать «replication_factor» и уровень согласованности ONE из Cassandra DB.

И я указал кластером: 'MyCluster01' с тремя узлами в центре двух данных: DC1 (node1, node2) в RAC1, DC2 (node3) в RAC2.

структура, как показано ниже:

[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 

Я получил эту запись.

Но когда я остановил узел1 и снова запросил в любом узле 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'} 

В то время как команда 'статус' nodetool вернулся:

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; Произошла ошибка.

Тогда в чем проблема, поскольку я думаю, что я уже удовлетворил уровень согласованности и где именно эта запись существует?

Answer 1

Что в конечном счете контролирует 'replication_factor'?

Чтобы ответить на вопрос, коэффициент репликации (RF) контролирует количество реплик каждого раздела данных, существующих в кластере или центре данных (DC). В вашем случае у вас есть 3 узла и RF 1. Это означает, что когда строка записывается в ваш кластер, он сохраняется только на одном узле. Это также означает, что ваш кластер не может противостоять сбою одного узла.

Напротив, рассмотрим RF 3 на кластере из 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 с несколькими контроллерами домена может привести к непредсказуемым результатам. Также с несколькими контроллерами домена вам необходимо использовать NetworkTopologyStrategy и что-то иное, чем значение по умолчанию SimpleSnitch. В противном случае Cassandra может не найти нужный узел для завершения операции.

Прежде всего, re-create your keyspace and table with the NetworkTopologyStrategy. Затем измените снитч (в cassandra.yaml) на сетевой снимок, перезагрузите узлы и повторите это упражнение снова.

Answer 2

NetworkTopologyStrategy следует использовать при тиражировании по нескольким постоянным токам.