Непоследовательное состояние системы Кассандры.

Question

Мы работаем с 6 узлами Cassandra (3.11.2) кластера на Kubernetess.Недавно я заметил, что данные в таблице system.peers противоречивы.Тем не менее, данные в system.local вроде бы в порядке.nodetool describecluster также не сообщает о каких-либо проблемах.

Ниже вы найдете анонимный результат запросов system.peers и system.local.Я выполнил их, перенаправляя порт на один узел за раз (надеюсь, это позволяет пропустить политику балансировки нагрузки и получить прямой доступ к узлу)

Является ли это состояние таблицы system.peers вредным?Или, может быть, это ожидается?

SELECT peer, schema_version FROM system.peers

node 0
peer | schema_version
IP1 | schema2
IP2 | schema1
IP3 | schema1
IP4 | null
IP5 | schema1
IP6 | schema1
IP7 | schema1

node 1
peer | schema_version
IP8 | null
IP9 | schema1
IP3 | schema1
IP5 | schema1
IP6 | schema1
IP7 | schema1

node 2
peer | schema_version
IP11 | null
IP2 | schema1
IP9 | schema1
IP3 | schema1
IP4 | schema3
IP10 | null
IP5 | schema1
IP6 | schema1

node 3
peer | schema_version
IP12 | schema3
IP2 | schema1
IP9 | schema1
IP13 | null
IP3 | schema1
IP5 | schema1
IP7 | schema1

node 4
peer | schema_version
IP2 | schema1
IP9 | schema1
IP3 | schema1
IP6 | schema1
IP7 | schema1

node 5
peer | schema_version
IP8 | schema3
IP2 | schema1
IP9 | schema1
IP5 | schema1
IP6 | schema1
IP7 | schema1

SELECT key, broadcast_address, schema_version FROM system.local

node 0
key | broadcast_address | schema_version
local | IP9 | schema1

node 1
key | broadcast_address | schema_version
local | IP2 | schema1

node 2
key | broadcast_address | schema_version
local | IP7 | schema1

node 3
key | broadcast_address | schema_version
local | IP6 | schema1

node 4
key | broadcast_address | schema_version
local | IP5 | schema1

node 5
key | broadcast_address | schema_version
local | IP3 | schema1

nodetool describecluster

Cluster Information:
  Name: CLUSTER_NAME
  Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
  DynamicEndPointSnitch: enabled
  Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
  Schema versions:
    e718e690-d474-376e-8020-ed0eba5b6797: [IP5, IP9, IP3, IP2, IP6, IP7]

Answer 1

Это неожиданно, но известно, что это произошло, например: CASSANDRA-7122 , CASSANDRA-7531 .

Это может вызвать проблемы для другого клиентадрайверы (например, см. JAVA-852 и JAVA-2280 ), хотя большинство клиентских библиотек будут игнорировать подобные записи поврежденных узлов и регистрировать предупреждение, когда это произойдет.

Поскольку вы упоминаете Kubernetes, возможно ли, что вы часто меняете узлы?Интересно, есть ли скрытая ошибка в C *, из-за которой он не удаляет должным образом старые записи пиров.В прошлом были сообщения о проблемах, которые были закрыты с помощью COULD NOT REPRODUCE.

Если вы можете воспроизвести это довольно легко, было бы очень полезно для сообщества, если бы вы могли создать билет JIRA описание проблемы и как ее воспроизвести.В противном случае, если у вас нет времени, вы могли бы описать свои настройки kubernetes (то есть, используете ли вы оператор сообщества или что-то еще?) И объяснить некоторые операции, которые вы можете выполнять, которые могли бы способствовать этому (например, замена узлов) Я мог бы изучить это, когда у меня будет время.