Как избавиться от узла, который отображается как ноль после замены? - PullRequest
Новая
       15

Как избавиться от узла, который отображается как ноль после замены?

0 голосов
/ 27 марта 2019

У меня был кластер из 3 узлов (Cassandra 3.9);один узел сдох.Я построил новый узел с нуля и «заменил» мертвый узел, используя информацию с этой страницы https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsReplaceNode.html. Выглядело, как будто замена прошла нормально.

Я добавил еще два узла для усиления кластера.

Прошло несколько дней, и мертвый узел все еще виден и помечен как "вниз" на 3 из 5 узлов в nodetool status: 

--  Address       Load       Tokens       Owns (effective)  Host ID                               Rack
UN  192.168.1.9   16 GiB     256          35.0%             76223d4c-9d9f-417f-be27-cebb791cddcc  rack1
UN  192.168.1.12  16.09 GiB  256          34.0%             719601e2-54a6-440e-a379-c9cf2dc20564  rack1
UN  192.168.1.14  14.16 GiB  256          32.6%             d8017a03-7e4e-47b7-89b9-cd9ec472d74f  rack1
UN  192.168.1.17  15.4 GiB   256          34.1%             fa238b21-1db1-47dc-bfb7-beedc6c9967a  rack1
DN  192.168.1.18  24.3 GiB   256          33.7%             null                                  rack1
UN  192.168.1.22  19.06 GiB  256          30.7%             09d24557-4e98-44c3-8c9d-53c4c31066e1  rack1

Его идентификатор хоста равен нулю, поэтомуЯ не могу использовать nodetool removenode.Более того, nodetool assassinate 192.168.1.18 завершается с: 

error: null
-- StackTrace --
java.lang.NullPointerException

И в system.log: 

INFO  [RMI TCP Connection(16)-127.0.0.1] 2019-03-27 17:39:38,595 Gossiper.java:585 - Sleeping for 30000ms to ensure /192.168.1.18 does not change
INFO  [CompactionExecutor:547] 2019-03-27 17:39:38,669 AutoSavingCache.java:393 - Saved KeyCache (27316 items) in 163 ms
INFO  [IndexSummaryManager:1] 2019-03-27 17:40:03,620 IndexSummaryRedistribution.java:75 - Redistributing index summaries
INFO  [RMI TCP Connection(16)-127.0.0.1] 2019-03-27 17:40:08,597 Gossiper.java:1029 - InetAddress /192.168.1.18 is now DOWN
INFO  [RMI TCP Connection(16)-127.0.0.1] 2019-03-27 17:40:08,599 StorageService.java:2324 - Removing tokens [-1061369577393671924,...]

В system.peers мертвый узел показывает и имеет тот же идентификатор, что и замещающий узел:

cqlsh> select peer, host_id from system.peers;

 peer         | host_id
--------------+--------------------------------------
 192.168.1.18 | 09d24557-4e98-44c3-8c9d-53c4c31066e1
 192.168.1.22 | 09d24557-4e98-44c3-8c9d-53c4c31066e1
  192.168.1.9 | 76223d4c-9d9f-417f-be27-cebb791cddcc
 192.168.1.14 | d8017a03-7e4e-47b7-89b9-cd9ec472d74f
 192.168.1.12 | 719601e2-54a6-440e-a379-c9cf2dc20564

Мертвый узел и замещающий узел имеют разные токены в system.peers.

Поэтому мои вопросы:

  • Не могли бы вы объяснить, что не так?
  • Как это исправить и избавиться от этого мертвого узла?

1 Ответ

0 голосов
/ 28 марта 2019

Из system.peers вы получили идентификатор хоста, поэтому вы можете попробовать nodetool removenode / assassinate с идентификатором хоста. 

 peer         | host_id
 --------------+--------------------------------------
  192.168.1.18 | 09d24557-4e98-44c3-8c9d-53c4c31066e1
...