Вот наш контекст.У нас был кластер ES 5.6.2 с 23 узлами (3M + 20D).В этом кластере около половины индексов были созданы до того, как мы перешли на 5.6.2, а другая половина - после этой миграции.Чтобы воспользоваться новыми функциями и идти в ногу с новыми выпусками, мы решили:
- разделить этот кластер на две части, оставив более старые индексы (созданные в ES 2) в 5.6.2 cluster
- переместить более новые индексы (созданные в 5.6) в новый кластер, работающий на ES 6.5.1
- , и установить CCS однонаправленно между 6.5.1 (новое) -> 5.6.2 (старое)
Логическое обоснование этого разделения заключалось в том, что более старые индексы были слишком массовыми, чтобы их можно было переиндексировать в ES 6.5.1 без прерывания работы.Это заняло бы недели.Мы все еще могли бы сделать это в какой-то момент, но, поскольку в какой-то момент эти индексы будут заморожены , мы не видели смысла тратить время на миграцию данных, которые все равно умрут / замерзнут.
Итак, мы были достаточно уверены в том, что переведем новые индексы на 6.5.1, и это действительно прошло довольно гладко.Фильтрация распределения сегментов помогла нам переместить все эти индексы на узлы, которые должны были стать частью нового кластера 6.5.1.Затем, в процессе непрерывной миграции, мы перенесли каждый из этих узлов в новый кластер 6.5.1, который с тех пор был зеленым и гудел.
Далее идет сложная часть, и вы, вероятно, уже видите, что она уже идет,Мы настроили CCS, используя три начальных узла (данных) из старого кластера, и именно тогда старый кластер начал дрожать.Помимо еще одной поисковой ошибки CCS , которую мы обнаружили и зарегистрировали, симптомы заключались в том, что довольно часто узел данных уходил и возвращался в кластер, вызывая почти постоянную перебалансировку сегмента.
Иными словами, у нас осталась желтая гроздь, которая, как мы боялись, могла стать красной в любое время.Иногда он снова становится зеленым в течение нескольких минут, а затем снова становится желтым (а иногда красным в течение очень короткого периода времени).Смотрите историю работоспособности ниже (большое начальное красное состояние слева было, когда мы переместили новые индексы в новый кластер, но все остальные пары зеленой / красной стрелки были временными красными состояниями из-за ошибок, которые мы собираемся описать далее):
Конкретно, то, что мы видим в журналах на главном узле старого кластера 5.6.2, это то, что мастер будетсбросить соединение с узлом данных после следующей серии событий:
Сначала мы видим следующую ошибку (очень похожую на # 23939 ), где мы видим, что узлу не удается получитьзаблокировать данный осколок.(Примечание: мы широко используем поиск с прокруткой, так что это может быть причиной, как объяснено в этой проблеме)
[2019-02-14T23:53:38,331][WARN ][o.e.c.a.s.ShardStateAction] [IK-PRD-M3] [transactions_2016][1] received shard failed for shard id [[transactions_2016][1]], allocation id [Hy0REX6nScy49_2uXpKqrw], primary term [0], message [failed to create shard], failure [IOException[failed to obtain in-memory shard lock]; nested: ShardLockObtainFailedException[[transactions_2016][1]: obtaining shard lock timed out after 5000ms]; ]
java.io.IOException: failed to obtain in-memory shard lock
at org.elasticsearch.index.IndexService.createShard(IndexService.java:364) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.indices.IndicesService.createShard(IndicesService.java:499) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.indices.IndicesService.createShard(IndicesService.java:147) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.indices.cluster.IndicesClusterStateService.createShard(IndicesClusterStateService.java:542) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.indices.cluster.IndicesClusterStateService.createOrUpdateShards(IndicesClusterStateService.java:519) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.indices.cluster.IndicesClusterStateService.applyClusterState(IndicesClusterStateService.java:204) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.cluster.service.ClusterService.callClusterStateAppliers(ClusterService.java:814) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.cluster.service.ClusterService.publishAndApplyChanges(ClusterService.java:768) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.cluster.service.ClusterService.runTasks(ClusterService.java:587) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.cluster.service.ClusterService$ClusterServiceTaskBatcher.run(ClusterService.java:263) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:150) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.cluster.service.TaskBatcher$BatchedTask.run(TaskBatcher.java:188) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:569) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedEsThreadPoolExecutor.java:247) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:210) ~[elasticsearch-5.6.2.jar:5.6.2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[?:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[?:1.8.0_74]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_74]
Caused by: org.elasticsearch.env.ShardLockObtainFailedException: [transactions_2016][1]: obtaining shard lock timed out after 5000ms
at org.elasticsearch.env.NodeEnvironment$InternalShardLock.acquire(NodeEnvironment.java:724) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.env.NodeEnvironment.shardLock(NodeEnvironment.java:643) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.index.IndexService.createShard(IndexService.java:294) ~[elasticsearch-5.6.2.jar:5.6.2]
... 17 more
Сразу после этого мы видим проблему транспортного уровня, когда сообщение не может быть полностью прочитано:
[2019-02-14T23:53:52,630][WARN ][o.e.t.n.Netty4Transport ] [IK-PRD-M3] exception caught on transport layer [[id: 0xd97a9d8c, L:/10.10.1.184:51594 - R:10.10.1.166/10.10.1.166:9300]], closing connection
java.lang.IllegalStateException: Message not fully read (response) for requestId [7719647], handler [org.elasticsearch.transport.TransportService$ContextRestoreResponseHandler/org.elasticsearch.transport.TransportActionProxy$ProxyResponseHandler@7f2fcd88], error [false]; resetting
at org.elasticsearch.transport.TcpTransport.messageReceived(TcpTransport.java:1399) ~[elasticsearch-5.6.2.jar:5.6.2]
at org.elasticsearch.transport.netty4.Netty4MessageChannelHandler.channelRead(Netty4MessageChannelHandler.java:74) ~[transport-netty4-5.6.2.jar:5.6.2]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310) [netty-codec-4.1.13.Final.jar:4.1.13.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:297) [netty-codec-4.1.13.Final.jar:4.1.13.Final]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:413) [netty-codec-4.1.13.Final.jar:4.1.13.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) [netty-codec-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:644) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:544) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:498) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:458) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) [netty-common-4.1.13.Final.jar:4.1.13.Final]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_74]
И затем этот узел данных сбрасывается ...
[2019-02-14T23:53:52,639][INFO ][o.e.c.s.ClusterService ] [IK-PRD-M3] removed {{IK-PRD-D103}{gAwPc0AvTyGR58ugLQ7K4Q}{-MdtgQHlT4SEQsDYTjvRBw}{10.10.1.166}{10.10.1.166:9300}{ml.max_open_jobs=10, ml.enabled=true, tag=hot},}, reason: zen-disco-node-failed({IK-PRD-D103}{gAwPc0AvTyGR58ugLQ7K4Q}{-MdtgQHlT4SEQsDYTjvRBw}{10.10.1.166}{10.10.1.166:9300}{ml.max_open_jobs=10, ml.enabled=true, tag=hot}), reason(transport disconnected)[{IK-PRD-D103}{gAwPc0AvTyGR58ugLQ7K4Q}{-MdtgQHlT4SEQsDYTjvRBw}{10.10.1.166}{10.10.1.166:9300}{ml.max_open_jobs=10, ml.enabled=true, tag=hot} transport disconnected]
... и считывается несколько секунд спустя
[2019-02-14T23:53:58,367][INFO ][o.e.c.s.ClusterService ] [IK-PRD-M3] added {{IK-PRD-D103}{gAwPc0AvTyGR58ugLQ7K4Q}{-MdtgQHlT4SEQsDYTjvRBw}{10.10.1.166}{10.10.1.166:9300}{ml.max_open_jobs=10, ml.enabled=true, tag=hot},}, reason: zen-disco-node-join[{IK-PRD-D103}{gAwPc0AvTyGR58ugLQ7K4Q}{-MdtgQHlT4SEQsDYTjvRBw}{10.10.1.166}{10.10.1.166:9300}{ml.max_open_jobs=10, ml.enabled=true, tag=hot}]
Также стоит отметить, что узлы, которые прыгали и на кластере, почти всегда были одними и теми же тремя, один из которых находится в списке начальных узлов CCS.
Согласен, нет абсолютно никакой подсказки, что CCS имеет какое-либо отношение к этому, но так как это в значительной степени единственное изменение, которое претерпел старый кластер 5.6.2, и тот факт, что один из прыжковых узлов являетсяУзел шлюза CCS, высока вероятность того, что это вызывает CCS.
Одна вещь, которая пришла в голову, - это перенести старый кластер 5.6.2 на последний выпуск исправлений 5.6.14, но попытаться выполнить миграцию нанестабильная желтая гроздь может быть опасной, и поэтому мы ищем совета здесь.
Глядя на 5.6.3 заметки о выпуске , мы видим исправление ( # 26833 , исправленное @ javanna в PR # 27881 ) это может решить нашу проблему, но мы не уверены, нужно ли нам перенести весь кластер на 5.6.3 или только на начальные узлы.Мы попытались добавить в кластер 5.6.2 два клиентских узла 5.6.3 (т. Е. Не мастер и не данные) и использовать их в качестве начальных узлов для CCS, но это сделало кластер еще более нестабильным.Таким образом, мы отменили это изменение, но, возможно, мы не сделали правильную вещь
Мы не видели ни в одном другом 5.6.В выпуске отмечается все, что исправляло ошибки, которые могли вызвать то, что мы видим.Мы ищем совет специалиста, как решить эту проблему, еще раз спасибо за ваше внимание.
Примечание: это также было размещено на официальном форуме Elasticsearch: https://discuss.elastic.co/t/shaky-cross-cluster-search-between-6-5-1-and-5-6-2/168518/6