Узлы Cassandra 3.0.5 не запускаются с ошибкой «IllegalStateException: требуется одна строка, найдено 2»

Я столкнулся с ужасной ситуацией на одном из моих кластеров cassandra. Версия кластера — 3.0.5. Я запускаю установку из 2 DC с близкими 30 узлами, 18 в одном DC и остальные в другом. Я сделал все возможное с моими знаниями, но все еще ищу ответы.

В последнее время у нас было несколько проблем, связанных с паузами GC, было выполнено несколько поворотов на jvm (MAX_HEAP_SIZE было изменено) на всех узлах, и кластер был готов к последовательному перезапуску, чтобы он вступил в силу.

1-й узел успешно прошел циклический перезапуск, но 2-й узел просто не вернулся после отключения. И ошибка ниже.

INFO  07:45:34 Initializing system_schema.keyspaces
INFO  07:45:34 Initializing system_schema.tables
INFO  07:45:34 Initializing system_schema.columns
INFO  07:45:34 Initializing system_schema.triggers
INFO  07:45:34 Initializing system_schema.dropped_columns
INFO  07:45:34 Initializing system_schema.views
INFO  07:45:34 Initializing system_schema.types
INFO  07:45:34 Initializing system_schema.functions
INFO  07:45:34 Initializing system_schema.aggregates
INFO  07:45:34 Initializing system_schema.indexes
Exception (java.lang.IllegalStateException) encountered during startup: One row required, 2 found
java.lang.IllegalStateException: One row required, 2 found
    at org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:84)
    at org.apache.cassandra.schema.SchemaKeyspace.fetchTable(SchemaKeyspace.java:948)
    at org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:938)
    at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:901)
    at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:878)
    at org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:866)
    at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134)
    at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124)
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:229)
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
    at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)

после запуска ремонта в кластере и, в частности, в системных пространствах ключей ошибка все еще сохранялась. Когда узел в конце концов не появился, я удалил его из кластера с помощью команды nodetool removenode из исправного узла.

Опять взяли на перезапуск еще одну ноду в том же кластере и датацентре, опять не завелась, с той же ошибкой.

Мне также не удалось войти в оболочку cqlsh с исправного узла с приведенной ниже ошибкой.

Connection error: ('Unable to connect to any servers', {'<<VM hostname>>': UnicodeDecodeError('utf8', '\x7f\x00\x00\x80C\x02', 3, 4, 'invalid start byte')})

Эта ошибка также была замечена на нескольких других узлах.

Connection error: ('Unable to connect to any servers', {'<<VM Hostname>>': ConnectionShutdown("'utf8' codec can't decode byte 0x80 in position 3: invalid start byte",)})

По сути, в кластере не работает ничего, кроме команд nodetool.

Когда я запустил nodetool для описания кластера, я увидел 5 разных версий схемы для разных узлов, а также увидел, что некоторые 9 узлов недоступны, ниже приведен результат.

./nodetool describecluster
Cluster Information:
    Name: Dummy cluster
    Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
    Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
    Schema versions:
        1590ea6a-8c19-342a-8269-204c64a12176: [9 nodes here]
        668d9efd-13c1-3fb3-9b89-7fc07d9ddf0b: [1 node here]
        d20dc0de-dd34-3183-b459-31e3feb8f118: [3 nodes here]
        3ec9610c-d241-3215-84f2-2413b8cad7d2: [7 nodes here]
        59adb24e-f3cd-3e02-97f0-5b395827453f: [1 node here]
        UNREACHABLE: [9 nodes unreachable]

Может ли кто-нибудь помочь понять, в чем может быть проблема, а также способ восстановить узлы? Я также пробовал игнорировать флаг несоответствия схемы в cassandra-env.sh/jvm.options, чтобы поднять узел, но это тоже не помогло.

Установка Apache Cassandra на Mac OS
Установка Apache Cassandra на Mac OS
Это краткое руководство по установке Apache Cassandra.
2
0
83
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Вас вполне может затронуть та же проблема, о которой сообщалось в CASSANDRA-11900 , которая в конечном итоге была исправлена ​​ CASSANDRA-12144 . Вы можете попробовать отключить узлы и перейти на более стабильную версию Cassandra 3.0, последняя доступная версия 3.0.28: https://www.apache.org/dyn/closer.lua/cassandra/3.0.28/ apache-cassandra-3.0.28-bin.tar.gz

Поскольку стек в журнале показывает, что при переносе таблиц system_schema возникли проблемы, если вы не можете запустить Cassandra с более новой версией, вы можете попробовать sstablescrub в более новой версии перед запуском.

Надеюсь, что с количеством узлов, недоступных, более новая версия поможет вам преодолеть это, и вы можете перезапустить кластер, начиная с исходных узлов, чтобы исправить версию схемы, в противном случае вам нужно будет сохранить вывод «nodetool ring» из узел в сети, затем удалите начальные значения токенов для узлов, которые находятся в несоответствующих версиях схемы, и пройдите процесс начальной загрузки узлов обратно в кластер и заполните созданные пользователем таблицы с помощью «обновления nodetool», затем, как только все будет назад, ремонт кластера. Эти шаги могут быть изложены, если дело дойдет до этого, но, надеюсь, обновление поможет вам пройти через это.

Спасибо Павел за ответ, я тоже так думал. У меня не получилось запустить даже с более высокой версии, в итоге пришлось восстанавливать весь кластер с начальными значениями токенов, но с парой часов простоя. Так много для высокой доступности :) в любом случае спасибо!

Nikhit Nair 22.11.2022 07:59

Судя по опубликованной вами трассировке стека, вы столкнулись с известной ошибкой, о которой сообщалось после обновления с Cassandra 2.x (2.1 или 2.2) до Cassandra 3.x.

Существует известная проблема захоронения диапазона в формате хранения C* 2.x, когда не гарантируется, что для раздела будет вставлено только одно захоронение диапазона. Это приводит к вставке нескольких строк в новый формат хранилища Cassandra 3.x.

Хотя это было очень актуально, вы не упомянули, что обновили свой кластер до Cassandra 3.0.5 с более старой версии. К сожалению, этого можно было бы избежать, если бы вы обновились до последней версии C* 3.0. Как Пол заявил в своем ответе, это было исправлено в C* 3.0.9 CASSANDRA-12144.

Cassandra 3.0.5 была выпущена 7 лет назад, так что это очень старая версия. Обходного пути для ошибки нет, и решение состоит в следующем:

  1. Начиная с начального узла, обновите двоичные файлы до последней версии C* 3.0.
  2. Для каждой затронутой таблицы (отметьте system.log) обновите SSTables с помощью:
$ sstableupgrade ks_name table_name
  1. Для каждой затронутой таблицы удалите повторяющиеся строки с помощью:
$ sstablescrub ks_name table_name
  1. Запустите Cassandra на узле.
  2. Повторите описанные выше шаги на следующем узле.

Повторяйте описанные выше шаги, пока не будут исправлены все узлы во всех контроллерах домена. Ваше здоровье!

Привет Эрик, спасибо за ответ. После бинарного обновления sstableupgrade и sstablescrub не работают. Оба дают мне сообщение ниже, вероятно, ошибка. Требуется одна строка, найдено 2. Вы видите какие-либо другие обходные пути ?? Спасибо

Nikhit Nair 27.11.2022 12:58

Другие вопросы по теме