координатор removenode, и данные его подсказок будут потеряны - PullRequest
0 голосов
/ 14 декабря 2018

В кластере четыре узла.Предположим, что это узлы A, B, C, D. Включена подсказка передачи обслуживания.

1) Создайте пространство ключей с RF = 2 и создайте таблицу.

2) Создайте узел B, Cdown (nodetool stopdaemon),

3) войти в узел A с помощью cqlsh , установить CONSISTENCY ANY, вставить в строку (предположим, что строка будет сохранена в узлах B и C).Строка была успешно вставлена, несмотря на то, что узел B, C был недоступен, поскольку уровень согласованности ЛЮБ.координатор (узел A) написал подсказки.

4) выключил узел A (stoptoeemon nodetool), затем удалил узел A (removenode nodetool $ {nodeA_hostId})

5) сделал узел B,C вернуться (запуск nodetool)

6) войти в любой узел B, C, D. и выполнить оператор выбора с ключом разделения вставленной строки.Но нет никаких данных, которые вставили строку на шаге 3.

Эти шаги приводят к потере данных (на шаге 3 была вставлена ​​строка).

Есть ли проблемы с шагами, которые я выполнил выше??

Если да, как справиться с этой ситуацией 101

с нетерпением ждем вашего ответа, спасибо.

Ответы [ 2 ]

0 голосов
/ 14 декабря 2018

CONSISTENCY.ANY приведет к потере данных во многих сценариях.Это может быть так просто, как белый медведь срывает сервер со стены, как только запись ACKd для клиента (еще даже не применена к одному коммитлогу).Это для записей, которые эквивалентны тому, чтобы быть в порядке с durable_writes=false, где задержка в клиенте важнее, чем фактическое хранение данных.

Если вы хотите гарантировать отсутствие потери данных, установите RF не менее 3 ииспользуйте кворум, тогда любая запись, которую вы получите, может быть уверена, что она переживет отказ одного узла.RF = 2 может работать с кворумом, но это эквивалент CL.ALL, что означает, что любой сбой узла, gc или сбой приведет к потере доступности.

Важно понимать, что подсказки не о гарантированной доставке, простовозможно сокращение времени конвергенции, когда данные становятся противоречивыми.Ремонт в gc_grace_seconds по-прежнему необходим для предотвращения потери данных.Если вы используете слабую согласованность, долговечность и низкую репликацию, вы открываете себя для потери данных.

0 голосов
/ 14 декабря 2018

Поскольку removenode не передает данные с узла, который будет удален.это говорит кластеру, что я выхожу из кластера и уравновешиваю существующий кластер.Пожалуйста, обратитесь https://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsRemoveNode.html

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...