Я столкнулся с ужасной ситуацией на одном из моих кластеров 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, чтобы поднять узел, но это тоже не помогло.
Вас вполне может затронуть та же проблема, о которой сообщалось в 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», затем, как только все будет назад, ремонт кластера. Эти шаги могут быть изложены, если дело дойдет до этого, но, надеюсь, обновление поможет вам пройти через это.
Судя по опубликованной вами трассировке стека, вы столкнулись с известной ошибкой, о которой сообщалось после обновления с 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 лет назад, так что это очень старая версия. Обходного пути для ошибки нет, и решение состоит в следующем:
system.log
) обновите SSTables с помощью:$ sstableupgrade ks_name table_name
$ sstablescrub ks_name table_name
Повторяйте описанные выше шаги, пока не будут исправлены все узлы во всех контроллерах домена. Ваше здоровье!
Привет Эрик, спасибо за ответ. После бинарного обновления sstableupgrade и sstablescrub не работают. Оба дают мне сообщение ниже, вероятно, ошибка. Требуется одна строка, найдено 2. Вы видите какие-либо другие обходные пути ?? Спасибо
Спасибо Павел за ответ, я тоже так думал. У меня не получилось запустить даже с более высокой версии, в итоге пришлось восстанавливать весь кластер с начальными значениями токенов, но с парой часов простоя. Так много для высокой доступности :) в любом случае спасибо!