Примечание. Мы наблюдаем эту проблему в нашем кластере Cassandra 2.1.12.1047 (DSE 4.8.4) с 6 узлами в 3 регионах (по 2 в каждом регионе).
Пытаясь недавно обновить схемы в нашем кластере, мы обнаружили, что обновления не работают. Мы подозревали, что один узел в кластере не принимает изменения.
При проверке таблицы system.peers одного из наших серверов в us-east-1 на наличие аномалии в ней была полная запись для хоста, которого не существует.
cassandra@cqlsh> SELECT peer, host_id FROM system.peers WHERE peer IN ('54.158.22.187', '54.196.90.253');
peer | host_id
---------------+--------------------------------------
54.158.22.187 | 8ebb7f2c-8f81-44af-814b-a537b84834e0
Поскольку этого хоста не существовало, я попытался удалить его с помощью nodetool removenode, но это не удалось error: Cannot remove self
-- StackTrace --
java.lang.UnsupportedOperationException: Cannot remove self
Мы знаем, что сервер .187 был внезапно остановлен несколько недель назад из-за проблемы с EC2.
У нас было много попыток сделать сервер работоспособным, но затем, в конце концов, просто отключили сервер, который сообщал об этом .187 хосте в system.peers, запустили nodetool removenode с одного из других серверов, а затем подключили новый сервер к сети.
Новый сервер подключился к сети и через час или около того, казалось, наверстал отставание в работе, необходимое для приведения его в соответствие с другими серверами (предположение, основанное исключительно на мониторинге ЦП).
Однако теперь все очень странно, потому что .187, о котором сообщается в таблицах system.peers, появляется, когда мы запускаем nodetool status с любого сервера в кластере, кроме нового, который мы только что подключили к сети.
$ nodetool status
Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
DN 54.158.22.187 ? 256 ? null r1
Datacenter: cassandra-ap-southeast-1-A
======================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 54.255.xx.xx 7.9 GB 256 ? a0c45f3f-8479-4046-b3c0-b2dd19f07b87 ap-southeast-1a
UN 54.255.xx.xx 8.2 GB 256 ? b91c5863-e1e1-4cb6-b9c1-0f24a33b4baf ap-southeast-1b
Datacenter: cassandra-eu-west-1-A
=================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 176.34.xx.xxx 8.51 GB 256 ? 30ff8d00-1ab6-4538-9c67-a49e9ad34672 eu-west-1b
UN 54.195.xx.xxx 8.4 GB 256 ? f00dfb85-6099-40fa-9eaa-cf1dce2f0cd7 eu-west-1c
Datacenter: cassandra-us-east-1-A
=================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 54.225.xx.xxx 8.17 GB 256 ? 0e0adf3d-4666-4aa4-ada7-4716e7c49ace us-east-1e
UN 54.224.xx.xxx 3.66 GB 256 ? 1f9c6bef-e479-49e8-a1ea-b1d0d68257c7 us-east-1d
Поскольку я не знаю способа удалить узел, у которого нет идентификатора хоста, я весьма озадачен.
Что я могу сделать, чтобы избавиться от этого мошеннического узла?
Примечание. Вот результат описания кластера.
$ nodetool describecluster
Cluster Information:
Name: XXX
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
d140bc9b-134c-3dbe-929f-7a84c2cd4532: [54.255.17.28, 176.34.207.151, 54.225.11.249, 54.195.174.72, 54.224.182.94, 54.255.64.1]
UNREACHABLE: [54.158.22.187]
