При репликации причинного кластера Neo4j происходит сбой с «Сброс соединения по пиру» - PullRequest
1 голос
/ 09 апреля 2019

Запуск трехузлового причинного кластера Neo4j (развернутого в кластере Kubernetes), кажется, у нашего лидера проблемы с репликацией транзакции для его последователей.Мы видим следующее сообщение об ошибке / предупреждение в debug.log:

2019-04-09 16:21:52.008+0000 WARN [o.n.c.c.t.TxPullRequestHandler] Streamed transactions [868842--868908] to /10.0.31.11:38968 Connection reset by peer
java.io.IOException: Connection reset by peer
        at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
        at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
        at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
        at sun.nio.ch.IOUtil.write(IOUtil.java:51)
        at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
        at io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:403)
        at io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:934)
        at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.forceFlush(AbstractNioChannel.java:367)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:639)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)
        at java.lang.Thread.run(Thread.java:748)
        at org.neo4j.helpers.NamedThreadFactory$2.run(NamedThreadFactory.java:110)

В нашем приложении мы, похоже, воспринимаем эту ошибку как:

Database not up to the requested version: 868969. Latest database version is 868967

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

Мы рассмотрели очевидные причины:

  • Пропускная способность сетипределы не достигнуты
  • Нет очевидных пиков для ЦП / памяти
  • Нет других исключений Neo4j (в частности, нет OOM)
  • Мы освободили / отскочили кластер и выполнили проверкупроверка базы данных (все они в порядке)
  • Мы настроили causal_clustering.pull_interval до 30 с, что, похоже, улучшает производительность, но не устраняет эту проблему
  • Мы удалили ресурсограничения на БД для устранения ошибок, которые могут вызывать удушение в Kubernetes (без достижения фактических ограничений ЦП), это также не помогло решить проблему
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...