Сбой операторов Cassandra INSERT и UPDATE - неожиданное исключение - PullRequest
0 голосов
/ 28 ноября 2018

Недавно я получил следующую ошибку в файлах system.log как на моем производственном, так и на демонстрационном кластерах.Каждый кластер имеет 2 узла и коэффициент репликации равен 2. Насколько мне известно, изменений не было.Я не могу понять, в чем причина ошибки.Это приводит к сбою операторов INSERT и UPDATE.

[SharedPool-Worker-27] ERROR org.apache.cassandra.transport.Message - Unexpected exception during request; channel = [id: 0xeb429d31, /14.0.0.1:34495 => /14.0.0.2:9042]                
    java.lang.AssertionError: -2146739295
    at org.apache.cassandra.db.BufferExpiringCell.<init>(BufferExpiringCell.java:46) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.db.BufferExpiringCell.<init>(BufferExpiringCell.java:39) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.db.AbstractCell.create(AbstractCell.java:176) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.UpdateParameters.makeColumn(UpdateParameters.java:65) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.Constants$Setter.execute(Constants.java:314) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:110) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.statements.UpdateStatement.addUpdateForKey(UpdateStatement.java:57) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:708) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:495) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:481) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:493) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:138) ~[apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439) [apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335) [apache-cassandra-2.1.10.jar:2.1.10]
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final]
    at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final]
    at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_45]
    at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) [apache-cassandra-2.1.10.jar:2.1.10]
    at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-2.1.10.jar:2.1.10]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]

Это асинхронные запросы.На стороне клиента я также вижу сбой в будущем. Я использую cassandra-2.1.10. Я еще не выполнил повторный перезапуск узлов, но не думаю, что это решит проблему..

Также заметил, что, похоже, неудачные вставки / обновления происходят после нескольких успешных вставок / обновлений.Сами заявления запроса (форматирование) в порядке.Буду признателен за любую помощь.

ОБНОВЛЕНИЕ: Я изучил исходный код Кассандры.Он содержит следующее:

assert timeToLive > 0 : timeToLive;
assert localExpirationTime > 0 : localExpirationTime;

Похоже, что он не работает на втором утверждении assert.Таблица имеет значение TTL, установленное в ее свойствах на 1728000 секунд.В инструкциях вставки / обновления не указывается ttl.Поэтому я не понимаю, почему некоторые утверждения не выполняются в этом утверждении.

РЕДАКТИРОВАТЬ: в клиентских приложениях я вижу следующие сообщения об ошибках:

Клиент 1подключается к кластеру 1:

16:36:01.102 [New I/O worker #64] WARN  - /14.0.0.2:9042 replied with server error (java.lang.AssertionError: -2146571535), trying next host

Клиент 2 подключается к кластеру 2:

16:30:01.302 [cluster1-nio-worker-7] WARN  - /14.0.0.4:9042 replied with server error (java.lang.AssertionError: -2146571895), defuncting connection.

Я полагаю, что происходит, когда происходят вышеуказанные ошибки, клиент сбрасывает соединение и переподключается.В это время другие асинхронные запросы не выполняются.

1 Ответ

0 голосов
/ 03 декабря 2018

В одной из таблиц значение default_time_to_live было установлено примерно на 19 лет.Причиной проблемы была 2038 отметка времени .Даже если само значение ttl в каждой ячейке равно количеству оставшихся секунд, кажется, что Кассандра внутренне пытается преобразовать время истечения в метку времени.Таким образом, текущая временная метка + ttl (19+) лет = временная метка после 19 января 2038 года. Это вызывало переполнение и отрицательное число, наблюдаемое в исключении, показанном выше.Уменьшение значения ttl по умолчанию для таблицы исправило проблему, из-за которой ошибка утверждения не произошла.

Это выглядело как несколько ошибок утверждения, что приводило бы к сбросу соединений и, в то же время, к другим сбоям записи.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...