Cassandra: Удаление узла

Question

Я хотел бы удалить узел из моего кластера Cassandra и выполнить следующие два связанных вопроса (here и here) и Cassandra document. Но я все еще не совсем уверен в точном процессе.

Мой первый вопрос: Правильно ли удалить узел из кластера Cassandra?

1. decommission узел, который хотел бы удалить.
2. removetoken узел, который я только что снял с эксплуатации.

Если вышеуказанный процесс является правильным, то как я могу сказать, что процесс снятия с эксплуатации завершен, чтобы я мог перейти ко второму шагу? или всегда безопасно делать шаг 2 сразу после шага 1?

Кроме того, Cassandra document говорит:

Вы можете взять узел из кластера с nodetool снятия с эксплуатации на живой узел, или nodetool removetoken (на любой другой машине), чтобы удалить мертвый. Это назначит диапазоны, которые старый узел отвечал за другим узлам, и реплицировать соответствующие данные там. Если используется дезактивация , данные будут поступать с выведенного из эксплуатации узла . Если используется removeetoken, данные будут передаваться из оставшихся реплик.

Данные не удаляются автоматически из выведенного из строя узла, , поэтому, если вы хотите вернуть узел обратно в другой токен на кольце, его следует удалить вручную.

Означает ли это, что выведенный из эксплуатации узел является мертвым узлом? Кроме того, поскольку данные не удаляются автоматически из выведенного из строя узла, как я могу узнать, когда можно безопасно удалить данные из выведенного из эксплуатации узла (то есть, как узнать, когда потоковая передача данных завершена?)

Answer 1

Удаление узла из кластера Cassandra должны быть следующие шаги (в Cassandra v1.2.8):

1. вывода из эксплуатации целевой узел с помощью nodetool decommission.
2. После завершения потоковой передачи данных из выведенного из эксплуатации узла вручную удалите данные из выведенного из строя узла (необязательно).

Из документов:

nodetool decommission - Decommission the *node I am connecting to* 

Update: Вышеописанный процесс также работает для семенных узлов. В этом случае кластер все еще может работать бесперебойно, не требуя перезапуска. Когда вам нужно перезапустить кластер по другим причинам, обязательно обновите параметр seeds, указанный в cassandra.yaml для всех узлов.

---

вывод из эксплуатации целевого узла

При запуске вывода из эксплуатации, то списан узел будет обозначена как первый leaving (помеченный как L). В следующем примере мы удалим node-76:

> nodetool -host node-76 decommission 
> nodetool status 

Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address Load  Tokens Owns Host ID        Rack 
UN node-70 9.79 GB 256  8.3% e0a7fb7a-06f8-4f8b-882d-c60bff51328a 155 
UN node-80 8.9 GB  256  9.2% 43dfc22e-b838-4b0b-9b20-66a048f73d5f 155 
UN node-72 9.47 GB 256  9.2% 75ebf2a9-e83c-4206-9814-3685e5fa0ab5 155 
UN node-71 9.48 GB 256  9.5% cdbfafef-4bfb-4b11-9fb8-27757b0caa47 155 
UN node-91 8.05 GB 256  8.4% 6711f8a7-d398-4f93-bd73-47c8325746c3 155 
UN node-78 9.11 GB 256  9.4% c82ace5f-9b90-4f5c-9d86-0fbfb7ac2911 155 
UL node-76 8.36 GB 256  9.5% 15d74e9e-2791-4056-a341-c02f6614b8ae 155 
UN node-73 9.36 GB 256  8.9% c1dfab95-d476-4274-acac-cf6630375566 155 
UN node-75 8.93 GB 256  8.2% 8789d89d-2db8-4ddf-bc2d-60ba5edfd0ad 155 
UN node-74 8.91 GB 256  9.6% 581fd5bc-20d2-4528-b15d-7475eb2bf5af 155 
UN node-79 9.71 GB 256  9.9% 8e192e01-e8eb-4425-9c18-60279b9046ff 155 

Когда списанный узел помечается как leaving, она потоковые данные в других живых узлов. После того, как потоковое будет завершен, узел не будет наблюдаться от кольцевой структуры, и данные, принадлежащие другим узлам увеличится:

Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
-- Address Load  Tokens Owns Host ID        Rack 
UN node-70 9.79 GB 256  9.3% e0a7fb7a-06f8-4f8b-882d-c60bff51328a 155 
UN node-80 8.92 GB 256  9.6% 43dfc22e-b838-4b0b-9b20-66a048f73d5f 155 
UN node-72 9.47 GB 256  10.2% 75ebf2a9-e83c-4206-9814-3685e5fa0ab5 155 
UN node-71 9.69 GB 256  10.6% cdbfafef-4bfb-4b11-9fb8-27757b0caa47 155 
UN node-91 8.05 GB 256  9.1% 6711f8a7-d398-4f93-bd73-47c8325746c3 155 
UN node-78 9.11 GB 256  10.5% c82ace5f-9b90-4f5c-9d86-0fbfb7ac2911 155 
UN node-73 9.36 GB 256  9.7% c1dfab95-d476-4274-acac-cf6630375566 155 
UN node-75 9.01 GB 256  9.5% 8789d89d-2db8-4ddf-bc2d-60ba5edfd0ad 155 
UN node-74 8.91 GB 256  10.5% 581fd5bc-20d2-4528-b15d-7475eb2bf5af 155 
UN node-79 9.71 GB 256  11.0% 8e192e01-e8eb-4425-9c18-60279b9046ff 155 

---

Удаление оставшихся данных вручную

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

Данные отсутствуют автоматически удаляется из выведенного из строя узла, , поэтому, если вы хотите вернуть узел обратно на другой токен на ринге, его следует удалить вручную.

Это может быть сделано путем удаления данных, хранящихся в data_file_directories, commitlog_directory и saved_caches_directory, указанный в файле cassandra.yaml в списанной узле.