本文介绍了升级Elasticsearch 1.4.1到2.0相同的配置失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我将我的旧配置目录升级并复制到新版本。我不在乎旧指数,所以开始新鲜。我从默认配置更改的唯一的东西是主机IP和群集名称。

  network.host:127.0.0.1 
cluster.name:elasticsearch_pat

我在我的开机机器上运行了一个单独的节点,具有自定义集群名字,所以我没有冲突。现在,当我启动ES,我得到连续的cluster / nodes / info错误,它抛出一个java.lang.IllegalStateException。

  [2015- 11-13 10:13:59,347] [WARN] [transport.netty] [Entropic Man]异常捕获在传输层[[id:0x6c3170dc,/127.0.0.1:61104 => /127.0.0.1:9300]],关闭连接
java.lang.IllegalStateException:消息未完全读取(request)for requestId [109],action [cluster / nodes / info],readerIndex [39] vs expected [ 57];在org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:120)上重新设置

在org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
在org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
在org.jboss.netty.channel.DefaultChannelPipeline $ DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
在org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
在org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
在org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
在org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
在org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
在org.jboss.netty.channel.DefaultChannelPipeline $ DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
在org .elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:75)
在org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
在org.jboss.netty .channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
在org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
在org.jboss.netty.channel.Channels .fireMessageReceived(Channels.java:255)
在org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
在org.jboss.netty.channel.socket .nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
在org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
在org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
在org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker。 java:178)
在org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
在org.jboss.netty.util.internal.DeadLockProofWorker $ 1.run(DeadLockProofWorker.java :42)
在java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
在java.util.concurrent.ThreadPoolExecutor $ Worker.run(ThreadPoolExecutor.java:615)
在java.lang.Thread.run(Thread.java:745)

当我检查_health与感觉,它是一个节点和一个数据节点是绿色的,这是正确的,因为我在本地主机上的开发机器上运行。



Elasticsearch现在需要身份验证?这是非常简单的配置,现在有点不够吗?



更新:此错误即将来临,因为另一个进程试图访问Elasticsearch。当我停止其他进程时,错误停止。该进程可能使用JDBC或其他在1.4.1之前提供的其他驱动程序,并从2.0中的二进制伪影中删除。

解决方案

@Val是正确的。当我从1.7.3升级到2.0时,还有其他客户端节点连接到此集群。这是精确的错误日志生成。



对我来说,您似乎正在运行应用程序(在localhost中查看您的端口),它仍然使用旧的弹性搜索API版本和创建一个1.4.1版本的客户端节点,它与升级节点冲突,这就是为什么你得到错误。


I upgraded and copied my old config dir to the new version. I don't care about the old indexes so started fresh. The only things I had changed from default config were the host ip and cluster name.

network.host: 127.0.0.1
cluster.name: elasticsearch_pat

I was running a single node on my dev machine with a custom cluster name so I'd have no conflict. Now when I launch ES I get continuous cluster/nodes/info error which throw a java.lang.IllegalStateException.

[2015-11-13 10:13:59,347][WARN ][transport.netty          ] [Entropic Man] exception caught on transport layer [[id: 0x6c3170dc, /127.0.0.1:61104 => /127.0.0.1:9300]], closing connection
java.lang.IllegalStateException: Message not fully read (request) for requestId [109], action [cluster/nodes/info], readerIndex [39] vs expected [57]; resetting
    at org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:120)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
    at org.elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:75)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

When I check _health with Sense, it is green with one node and one data node, which is correct since I'm running on a dev machine on localhost.

Does Elasticsearch now require authentication? Is this extremely simple config now somehow not sufficient?

Update: This error is coming because another process is trying to access Elasticsearch. When I stop the other process the error stops. The process may be using JDBC or some other driver that was provided before in 1.4.1 and is removed from the binary artifact in 2.0?????

解决方案

@Val is correct. When I did a upgrade from 1.7.3 to 2.0, there were still other client nodes connecting to this cluster. That was exact error log produced.

For me it seems that you're running your application(looking at your port in localhost) , which still uses old elasticsearch API version and creates a 1.4.1 version client node and it conflicts with upgraded node, that's why you're getting error.

这篇关于升级Elasticsearch 1.4.1到2.0相同的配置失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-23 08:00