У меня проблемы с кластером кассандры с несколькими центрами обработки данных, 3 узлами для каждого центра обработки данных, 2 узлами для каждого центра обработки данных, выступающими в качестве начальных значений:
У меня есть пространство ключей X с ReplicationFactor 3, в котором имеется 3 копии в центре обработки данныхDC1 и 3 копии в центре обработки данных DC2 (KEYSPACE X WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3', 'DC2': '3'} AND durable_writes = true;)
Теперь, что я делаю (и, возможно, мне здесь чего-то не хватает), так это то, что я подключаюсь к каждому узлу в центре данных DC2 (скажем, node2A, node2B и node2C) и выполните следующие действия:
- cqlsh node2N
- согласованность всех
- выбор * из x.table;
и путем настройкисогласованность со ВСЕМ, я знаю, что должен получить ответ от каждого узла, 3 из которых принадлежат DC1 и 3 из DC2, всего 6 ответов.Но вместо этого я получаю 3 разных результата в каждом узле:
- node2A: запрос не выполняется с
Cannot achieve consistency level ALL info: {'required_replicas': 6, 'alive_replicas': 5, 'consistency': ALL} - node2B: запрос завершается успешно и возвращает данные таблицы
- node2C: запрос занимает 1-2 минуты, а затем возвращает
Coordinator node timed out waiting for replica nodes' responses. Operation timed out - received only 5 responses. info: {'received_responses': 5, 'required_responses': 6, 'consistency': ALL}
Причина, по которой я выполняю эти запросы в cqlsh, заключается в том, что одно из наших приложений работаетошибочно при запросе cassandra (говоря о таких вещах, как недостаточно реплик для QUORUM и т. д.), и я подозреваю, что у нас могут быть некоторые проблемы со связью между узлами.Либо сплетни рассказывают разные вещи разным узлам, либо что-то в этом роде.Связь работает от каждого узла к любому другому узлу (мы можем cqlsh, ssh и все остальное).
Может ли моя теория быть правильной, и у нас есть какое-то несоответствие в конфигурации?Если так, как я мог отладить эти ошибки?Есть ли способ узнать, какой узел не жив или не отвечает, чтобы я мог более внимательно изучить его коммуникации?Я пробовал с «отслеживанием по», но он работает только для успешных запросов, поэтому я получаю только трассировки в node2B (кстати, поведение не всегда одинаково на одном и том же узле, оно кажется случайным)
Если нет, мой тест на cqlsh действителен?Или я здесь упускаю какую-то жизненно важную часть головоломки Кассандры?
Большое спасибо заранее, я схожу с ума здесь ....
РЕДАКТИРОВАТЬ: По запросу, вот выводnodetool описать кластер.Я сделал это во всех 3 узлах DC2 и:
Cluster Information:
Name: Cassandra Cluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
19ada8a5-4688-3fa8-9479-e612388f67ee: [node2A, node2B, node1A, node1B, node1C, other IPs from other nodes (from other datacenters and keyspaces)]
Cluster Information:
Name: Cassandra Cluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
19ada8a5-4688-3fa8-9479-e612388f67ee: [node2A, node2B, node2C, node1A, node1B, node1C, other IPs from other nodes (from other datacenters and keyspaces)]
UNREACHABLE: [couple of IPs from other datacenter/keyspaces]
Cluster Information:
Name: Cassandra Cluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
19ada8a5-4688-3fa8-9479-e612388f67ee: [node2B, node2C, node1A, node1B, node1C, other IPs from other nodes (from other datacenters and keyspaces)]
UNREACHABLE: [node2A and other IPs]
Стоит отметить, что в узле 2A нет узла 2C, в узле 2B все 3появляются узлы, и в node2C у нас есть node2A как UNREACHABLE ...
Я чувствую, что это очень неправильно, как-то ...
Я только что выполнил "пространство ключей состояния nodetoolX", и эторезультаты:
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN node2A 67,78 MB 256 100,0% - RAC1
UN node2B 67,18 MB 256 100,0% - RAC1
?N node2C 67,11 MB 256 100,0% - RAC1
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN node2A 67,78 MB 256 100,0% - RAC1
UN node2B 67,18 MB 256 100,0% - RAC1
UN node2C 67,11 MB 256 100,0% - RAC1
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN node2A 67,78 MB 256 100,0% - RAC1
UN node2B 67,18 MB 256 100,0% - RAC1
UN node2C 67,11 MB 256 100,0% - RAC1
Теперь, почему node2A не знает состояние node2C (оно отображается как? И не былопоявиться в схеме описания описываемого кластера)?Но почему node2C, который жаловался на node2A как UNREACHABLE в описывающем кластере, знает, что node2A находится в состоянии Up согласно статусу?