Узлы Cassandra по-разному относятся к статусу работы и репликации. Как исправить?

У меня есть кластер Cassandra 2.0.1 из трех узлов и основного пространства ключей с коэффициентом репликации 3. Из-за случайной неправильной конфигурации одного дополнительного четвертого узла в кластере я попытался сначала исправить это с помощью ненужного «списания nodetool» ( на узле db2), прежде чем делать правильные действия с "nodetool removenode".

Теперь кажется, что узел db2, на котором было выполнено списание, видит один другой узел со статусом «Не работает», хотя другие думают, что все в порядке. Кроме того, когда я запускаю «кольцо nodetool» на всех узлах, db1 дает «Replicas: 2», где db2 и db3 имеют «Replicas: 3» в верхней части списка.

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

Обфусцированные выходные данные состояния nodetool ниже.

[db1 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns (effective)  Host ID                               Rack
UN  xx.xx.xx.99    30.38 MB   256     100.0%            cccccccc-cccc-cccc-cccc-cccccccccccc  rack1
UN  xx.xx.xx.122   28.93 MB   256     100.0%            aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa  rack1
UN  xx.xx.xx.123   29.59 MB   256     100.0%            bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb  rack1

[db2 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns (effective)  Host ID                               Rack
DN  xx.xx.xx.122   28.93 MB   256     100.0%            aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa  rack1
UN  xx.xx.xx.99    30.38 MB   256     100.0%            cccccccc-cccc-cccc-cccc-cccccccccccc  rack1
UN  xx.xx.xx.123   29.59 MB   256     100.0%            bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb  rack1

[db3 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns (effective)  Host ID                               Rack
UN  xx.xx.xx.122   28.93 MB   256     100.0%            aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa  rack1
UN  xx.xx.xx.99    30.38 MB   256     100.0%            cccccccc-cccc-cccc-cccc-cccccccccccc  rack1
UN  xx.xx.xx.123   29.59 MB   256     100.0%            bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb  rack1

cassandra cluster-computing nodetool cassandra-2.0
person Eemeli Kantola    schedule 06.11.2013    source источник
comment
Похоже, проблема волшебным образом разрешилась сама собой. Проблемный узел испытал некоторые (возможно, не связанные) проблемы с жестким диском, его пришлось перезагрузить, и он воспроизвел кучу журналов фиксации и, возможно, некоторые другие вещи автоматического восстановления. Но причины всего этого остаются неясными, хотя симптомы уже исчезли.   -  person Eemeli Kantola    schedule 18.11.2013
comment
Мы сталкиваемся с той же проблемой в производстве. У нас в кластере 10 узлов. Когда я запускаю nodetool status, одному узлу отображается DN, но когда я снова запускаю nodetool status, тот же узел отображается как UN. Это постоянная проблема. В чем может быть причина? Я уверен, что проблема не в жестком диске.   -  person abi_pat    schedule 13.08.2015

Ответы (1)


arrow_upward
4
arrow_downward

Аарон Мортон подробно описал, как он отладил аналогичную проблему.. Вы должны проверить состояние сплетен в вашем кластере.

  • Проверить состояние nodetool gossipinfo

  • Включить ведение журнала трассировки:

    log4j.logger.org.apache.cassandra.gms.Gossiper=TRACE log4j.logger.org.apache.cassandra.gms.FailureDetector=TRACE

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

person psanford    schedule 06.11.2013
comment
Спасибо, это подсказывает, как двигаться дальше. Но еще не решил проблему, потому что он не совсем такой, как у Аарона, который дополнительно включает Cassandra 1.x и, следовательно, не во всех отношениях применим к 2.0. - person Eemeli Kantola; 08.11.2013