Cassandra DB: Что в конечном счете контролирует фактор репликации?

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

И я указал кластер: 'MyCluster01' с тремя узлами в двух центрах обработки данных: DC1(узел1, узел2) в RAC1, DC2(узел3) в 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 status» вернула:

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 в рабочем состоянии; Ошибка тоже возникла.

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


cassandra consistency
person Martin Zang    schedule 13.04.2015    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

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

В отличие от этого, рассмотрим RF, равный 3, в кластере из 3 узлов. Такой кластер может выдержать отказ 1 или 2 узлов и по-прежнему поддерживать запросы ко всем своим данным.

Когда все ваши узлы запущены и работают, попробуйте выполнить следующую команду:

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

Это скажет вам, на каком узле находятся данные для ключа 5e6050f1-8075-4bc9-a072-5ef24d5391e5. Моя первая мысль заключается в том, что вы отбрасываете единственный узел, у которого есть этот ключ, а затем пытаетесь запросить его.

Моя вторая мысль перекликается с тем, что сказал Карло в своем ответе. Вы используете 2 контроллера домена, который на самом деле не поддерживается SimpleStrategy. Использование SimpleStrategy с несколькими контроллерами домена может привести к непредсказуемым результатам. Также с несколькими контроллерами домена вам нужно использовать NetworkTopologyStrategy и что-то другое, чем SimpleSnitch по умолчанию. В противном случае Cassandra может не найти нужный узел для завершения операции.

Прежде всего, пересоздайте пространство ключей и таблицу с помощью NetworkTopologyStrategy< /а>. Затем измените свой снитч (в cassandra.yaml) на сетевой снитч, перезапустите свои узлы и повторите это упражнение.

person Aaron    schedule 13.04.2015

arrow_upward
1
arrow_downward

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

person Carlo Bertuccini    schedule 13.04.2015