Добавление нового узла в развертывание Cassandra

У меня есть базовое развертывание Cassandra, которое содержит единственный узел. Я хочу добавить второй узел к развертыванию, и я хочу, чтобы клиенты имели доступ к одним и тем же данным независимо от того, с каким узлом они разговаривают (т.е. внутри заданного пространства ключей, конкретный запрос должен давать одинаковый результат для любого node, если только нет недавних обновлений, которые еще не полностью распространены).

Мое пространство ключей имеет коэффициент репликации 2.

В любом случае, я выполнил инструкции здесь (хотя я не уверен, что я использую "виртуальный" узлов или нет ... Я должен делать то, что по умолчанию в Cassandra 2.1), и кажется, что узлы обмениваются данными друг с другом:

# nodetool status
Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens  Owns    Host ID                               Rack
UN  xxx.xxx.234.252  563.02 MB  1024    ?       xxxxxxxx-0b3e-4fd3-9e63-xxxxxxxxxxxx  RAC1
UN  xxx.xxx.194.188  923.45 KB  1024    ?       xxxxxxxx-84cb-4260-84df-xxxxxxxxxxxx  RAC2

Однако я на самом деле не вижу никаких доказательств распространения данных на новый узел. Например, его cfstats выглядит так:

Read Count: 290
Read Latency: 0.1124551724137931 ms.
Write Count: 35
Write Latency: 0.12919999999999998 ms.
Pending Flushes: 0
        Table: assetproperties
        SSTable count: 0
        Space used (live): 0
        Space used (total): 0
        Space used by snapshots (total): 0
        Off heap memory used (total): 0
        SSTable Compression Ratio: 0.0
        Number of keys (estimate): 34

... находясь на исходном узле, они выглядят так:

Read Count: 90
Read Latency: 1.674811111111111 ms.
Write Count: 0
Write Latency: NaN ms.
Pending Flushes: 0
        Table: assetproperties
        SSTable count: 3
        Space used (live): 305561510
        Space used (total): 305561510
        Space used by snapshots (total): 0
        Off heap memory used (total): 773076
        SSTable Compression Ratio: 0.22460684186840507
        Number of keys (estimate): 416712

И если я подключаюсь к новому узлу с помощью cqlsh , я получаю очень противоречивые результаты . Запросы о ключах, которые, как я знаю, присутствуют в наборе данных, не дают результатов или дают переменные результаты. Например, иногда возвращается строка с правильными данными, а иногда Кассандра сообщает мне, что нет строк, соответствующих запросу. Если я подключаюсь к исходному узлу, все работает как надо.

Неужели это просто побочный эффект «конечной последовательности» Кассандры? И если так, Примерно сколько времени потребуется, чтобы новый узел начал надежно возвращать полезные данные?

Или есть какие-то дополнительные шаги, которые необходимо выполнить вручную, чтобы новый узел работал более разумным / согласованным образом?

Я подозреваю, что мог бы получить лучшие результаты, если бы установил согласованность всех в cqlsh , но попытка сделать это дает мне следующую ошибку:

ReadTimeout: code=1200 [Coordinator node timed out waiting for replica nodes' responses] 
    message="Operation timed out - received only 1 responses." 
    info={'received_responses': 1, 'required_responses': 2, 
        'consistency': 'ALL'
    }

Может быть, потому что данные еще не были реплицированы на новый узел?

0
задан 19 January 2016 в 08:27
1 ответ

Думаю, я нашел ответ. Необходимо было запустить nodetool repair на исходном узле, чтобы новый узел работал правильно.

Запуск восстановления nodetool на новом узле может показаться более интуитивно правильным, но попытка сделать это просто привела к зависанию процесса восстановления без вывода журнала.

Один раз. процесс восстановления завершился, данные были постоянно доступны на новом узле, а также настройка согласованности , все в cqlsh начали работать правильно.

Я также получил кучу сообщений «Утерянное уведомление» при запуске nodetool repair . Однако те кажутся безвредными .

1
ответ дан 4 December 2019 в 16:43

Теги

Похожие вопросы