Запуск трехузлового причинного кластера 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 (без достижения фактических ограничений ЦП), это также не помогло решить проблему