如何将数据从Elasticsearch 5.6迁移到Elasticsearch 8.3
我有一个运行5.6的弹性搜索群集。我计划升级我的群集，但我计划通过基本运行的ES群集8.3并行运行，然后将数据移至该集群。
我认为的首选方法是进行快照和还原 https://www.elastic.co/guide/guide/en/elasticsearch/reference/reference/current/snapshot-restore.html ，
但我对SnapShot版本的兼容性的意思是什么感到困惑：
在上面，我无法直接在版本8.3中恢复？ （这意味着我必须首先移动到6.x，然后再移至7.x，最后移至8.x）？
但是，以下索引兼容性矩阵说，5.x中的版本在8.x中可以使用？
我错过了什么？还是有人可以帮助我详细说明这一点？
I have an elastic search cluster running 5.6. I plan to upgrade my cluster but i plan to do it by basically running a ES cluster 8.3 running in parallel and then moving data over to it.
The preferred way i think is to do snapshot and restore https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html
But I am confused about what exactly Snapshot version compatibility mean : 
In the above does it mean that if i take a snapshot in elasticsearch 5.6, I cannot restore directly in version 8.3 ?? (which mean I have to first move to 6.x then to 7.x and finally to 8.x ) ??
The below index compatibility matrix, however says that a version in 5.x will work in 8.x ?
Am i missing something ? or can someone help me elaborate this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，根本的问题是用lucene版本编写的数据只能使用n+1读取。对于Elasticsearch 5到8，Lucene版本总是比ES版本大1个（SO 6至9）。
这意味着，无论是用于升级还是恢复的快照：如果您的数据用5.x编写，则只能使用6.x读 /还原。对于7.x或8.x，您需要重新索引数据。如果可能的话，我将直接从5.x到8.latest进行远程reindex：
noreferrer“ >
取决于它是什么样的数据：如果它已经老化（例如日志或指标），也许您不必将其迁移到新集群中？
So, the underlying problem is that data written in Lucene version N, can only be read with N+1. For Elasticsearch 5 to 8 the Lucene version was always 1 greater than the ES version (so 6 to 9).
That means, both for an upgrade or a restored snapshot: If your data was written with 5.x, you can only read / restore it with 6.x. For 7.x or 8.x you'll need to reindex the data. I would do a remote reindex straight from 5.x to 8.latest if possible: https://www.elastic.co/guide/en/elasticsearch/reference/current/reindex-upgrade-remote.html
There are some small caveats but they will probably not apply to you:
Depending on what kind of data it is: If it's aging out (like logs or metrics), maybe you don't have to migrate it to the new cluster?