Кассандра: удаление узла

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

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

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

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

Кроме того, документ Cassandra говорит:

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

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

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


cassandra database-administration nodetool
person keelar    schedule 15.08.2013    source источник

Ответы (1)


arrow_upward
15
arrow_downward

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

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

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

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

Обновление. Описанный выше процесс также работает для исходных узлов. В таком случае кластер по-прежнему может работать бесперебойно, не требуя перезагрузки. Когда вам нужно перезапустить кластер по другим причинам, обязательно обновите параметр 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. :

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

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

person keelar    schedule 15.08.2013