免费网站空间申请,怎样在门户网站做网络推广,域名注册信息怎么查,用html5做的商务网站1、集群环境及问题描述 集群版本#xff1a;6.8.X集群节点#xff1a;5节点#xff08;三个节点为主数据节点#xff0c;另外两个独立数据节点#xff09;。问题描述#xff1a;由于IP冲突#xff0c;修改了一台服务器的IP#xff0c;然后5台配置改了一下一次重启… 1、集群环境及问题描述 集群版本6.8.X集群节点5节点三个节点为主数据节点另外两个独立数据节点。问题描述由于IP冲突修改了一台服务器的IP然后5台配置改了一下一次重启能启动但是连不上后台各种报错。 2、问题讨论 节点换 IP 原因探讨宿主机服务器的IP地址和别的服务器IP 冲突所以要修改一台服务器的 IP地址。 不建议集群节点经常更换 IP原因如下 频繁更换 Elasticsearch 集群节点的 IP 地址可能会导致集群稳定性降低节点发现困难配置管理复杂化数据复制和恢复问题负载均衡配置困扰以及潜在的安全风险。因此为了保持集群的稳定性和安全性我们通常不建议频繁更改节点的 IP 地址。 还要考虑一个问题如果集群规模越大节点数越多换 IP 带来的服务不可用时间会越长。 由于这是 6.8.X 版本的集群每个节点的discovery.zen.ping.unicast.hosts 都要做修改就意味着所有集群都必须重启。所以节点越多重启后分配恢复时间越长服务不可用时间越长。尤其线上密集访问性业务要非常慎重。 以上是认知大前提。 3、问题排查 但上述更换节点 ip 已成为板上钉钉的事实接下里只能想办法修改 IP、修改各个节点配置后想办法让集群启动起来。 这里先敲定排查思路让问题尽可能的最小化。否则五个节点的日志会看得“眼花缭乱”。 昨晚我敲定的排查思路如下 从node1、node2、node3三个主数据节点入手看为什么不能组建成集群也就是说数据节点先不加入集群仅node1、node2、node3三个节点看能否组建成集群、选主成功 核心点找到和定位到当前节点不能组建成集群的原因 核心排查过程记录和梳理如下 3.1 逐个节点启动对任何日志猫腻都不放过。 发现了昨天的ip配置错误问题。 [2023-07-15T23:46:02,908][WARN ][o.e.d.z.UnicastZenPing ] [node-1] failed to resolve host [10.14.2·30.41:9300]
java.net.UnknownHostException: 10.14.2¡¤30.
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[?:1.8.0_291]
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929) ~[?:1.8.0_291]
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324) ~[?:1.8.0_291]
at java.net.InetAddress.getAllByName0(InetAddress.java:1277) ~[?:1.8.0_291]
at java.net.InetAddress.getAllByName(InetAddress.java:1193) ~[?:1.8.0_291]
at java.net.InetAddress.getAllByName(InetAddress.java:1127) ~[?:1.8.0_291] 这是修改 IP 地址的误操作肯定得修改否则会有大量报错信息。IP地址不对后面无从谈起。 3.2 在head插件等辅助工具不可用时借助命令行排查节点是否加入集群。 大前提只有集群构建成功后head插件才能使用只有集群是非红色状态黄色或者最好绿色状态kibana 才能正确访问。 而我们的节点是无法构建成功集群的所以无法使用 kibana、head插件等工具排查问题。但部分命令行的原始方式还是可以用的。 本质是通过如下命令看看节点是否构成了集群。 GET http://IP:端口/_cat/nodes 通过 postman 工具排查如下所示出现了“master_not_discovered_exception”异常也就是不能发现主节点。 对比看一下正确的情况下面就是两个节点已构成一个集群mdi的含义分别是master节点、data节点、ingest节点类型。 低版本叫节点类型8.X 版本叫节点角色。 这里还有一个细节如果集群 uuid 是“_na_” 只代表启动了但是还未选主成功 如果选主成功后大致应该是下面的样子所有节点的uuid 是一致的这个非常重要。 3.3 中间环节的多次异常差点被带跑偏。 如下日志我一直以为是网络问题。 排查了防火墙ping 命令挨个验证都没有问题。 org.elasticsearch.transport.ConnectTransportException: [node-1][10.14.XXX.XX:9300] handshake_timeout[30s]
at org.elasticsearch.transport.TransportHandshaker.lambda$sendHandshake$1(TransportHandshaker.java:77) ~[elasticsearch-6.8.12.jar:6.8.12]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:681) [elasticsearch-6.8.12.jar:6.8.12]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_291]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_291]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291]
[2023-07-16T00:58:53,697][WARN ][o.e.t.TcpTransport ] [node-2] exception caught on transport layer [Netty4TcpChannel{localAddress/10.14.XXX.yy:60218, remoteAddress/10.14.xxx.zz:9300}], closing connection
java.io.IOException: 远程主机强迫关闭了一个现有的连接。
at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?]
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) ~[?:?]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[?:?]
at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[?:?]
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378) ~[?:?]
at io.netty.buffer.PooledHeapByteBuf.setBytes(PooledHeapByteBuf.java:261) ~[netty-buffer-4.1.32.Final.jar:4.1.32.Final]
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132) ~[netty-buffer-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:347) ~[netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:656) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:556) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:510) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:470) [netty-transport-4.1.32.Final.jar:4.1.32.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909) [netty-common-4.1.32.Final.jar:4.1.32.Final]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291] 后面想其实还是内存不足导致的节点下线这应该是两个节点一个掉线后另外一个节点的连锁反应。 期间还发现了各个节点日期不一致问题通过手动对齐时间方式进行了时间一致性对齐。还将discovery.zen.ping_timeout 的值由 3s 调整到 100s。 discovery.zen.ping_timeout 是 Elasticsearch 集群设置中的一个参数它决定了节点在考虑其他节点“不可达”之前应等待 ping 响应的时间。这个设置对于集群节点之间的通信和集群的稳定性非常重要。如果设置 discovery.zen.ping_timeout 为 3 秒3s这意味着每个节点在将另一个节点视为离线之前将等待其响应 3 秒。如果网络条件较差或者Elasticsearch 集群负载很大可能会导致超时使得节点错误地认为其他节点已离线。这可能会引起不必要的重新选举和节点重新平衡从而影响集群性能和稳定性。 3.4 我一直想回避但这是根源所在。 反复排查发现如下日志就是根源内存溢出了。 [2023-07-16T00:52:39,878][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][153] overhead, spent [985ms] collecting in the last [1s]
[2023-07-16T00:52:44,238][INFO ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][154] overhead, spent [1.6s] collecting in the last [4.3s]
[2023-07-16T00:52:44,253][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [node-2] fatal error in thread [elasticsearch[node-2][generic][T#1]], exiting
java.lang.OutOfMemoryError: Java heap space
at org.apache.lucene.util.fst.FST.init(FST.java:342) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
at org.apache.lucene.util.fst.FST.init(FST.java:274) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
at org.apache.lucene.codecs.blocktree.FieldReader.init(FieldReader.java:91) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
at org.apache.lucene.codecs.blocktree.BlockTreeTermsReader.init(BlockTreeTermsReader.java:202) ~[lucene-core-7.7.3.jar:7.7.3 1a0d2a901dfec93676b0fe8be425101ceb754b85 - noble - 2020-04-21 10:31:55]
2023-07-16T00:51:59,263][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][124] overhead, spent [875ms] collecting in the last [1.1s]
[2023-07-16T00:52:00,826][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][125] overhead, spent [1s] collecting in the last [1.5s]
[2023-07-16T00:52:01,920][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][126] overhead, spent [938ms] collecting in the last [1s]
[2023-07-16T00:52:03,811][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][127] overhead, spent [1.1s] collecting in the last [1.8s]
[2023-07-16T00:52:06,639][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][129] overhead, spent [1s] collecting in the last [1.8s]
[2023-07-16T00:52:08,264][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][130] overhead, spent [1.2s] collecting in the last [1.6s]
[2023-07-16T00:52:09,468][WARN ][o.e.m.j.JvmGcMonitorService] [node-2] [gc][131] overhead, spent [1s] collecting in the last [1.1s] 什么原因导致的呢堆内存设置的不合理。 可是 jvm.options 明明已经改动了呢都是官方建议值。 但是在日志排查的时候我看到了下面的日志。 [node-2] JVM arguments [-Xms1g, -Xmx1g, -XX:UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction75 服务启动方式我把jvm.options 改成了 128GB了但是还是显示1GB这就是问题根源。 256 GB内存几乎没有怎么用。 后面改成了elasticsearch.bat 的启动方式后就搞定了。 更进一步讲以windows 服务启动的时候集群的配置 jvm.options 没有读到导致的上面的内存问题及各种报错 最终集群启动ok集群健康状态为绿色。 4、小结 类似问题没有更快的策略只能逐个节点逐个日志进行排查。上述问题累计排查耗时大于 6 个小时以上只有一点点排查才能发现问题所在。 欢迎就类似问题留言讨论交流。 推荐阅读 全网首发从 0 到 1 Elasticsearch 8.X 通关视频重磅 | 死磕 Elasticsearch 8.X 方法论认知清单如何系统的学习 Elasticsearch 2023做点事 更短时间更快习得更多干货 和全球 近2000 Elastic 爱好者一起精进 大模型时代抢先一步学习进阶干货
