Назад | Перейти на главную страницу

Добавление нового узла в развертывание 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 Я получаю очень противоречивые результаты. Запросы о ключах, которые, как я знаю, присутствуют в наборе данных, не дают результатов или дают переменные результаты. Например, иногда возвращается строка с правильными данными, а иногда Кассандра сообщает мне, что нет строк, соответствующих запросу. Если я подключаюсь к исходному узлу, все работает как надо.

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

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

Я подозреваю, что могу добиться лучших результатов, если установлю consistency all в 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'
    }

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

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

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

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

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