Force starting Elasticsearch, even with incorrect index files

[Leonid_P (Leonid)]

Hi there!

I tried to start Elasticsearch 8.6 with loading data from index which was initially created by Elasticsearch 7.13. It fails to start with message

[2023-09-20T11:17:13,331][ERROR][o.e.b.Elasticsearch ] [node_1] fatal exception while booting Elasticsearch
java.lang.IllegalStateException: cannot upgrade a node from version [7.13.4] directly to version [8.6.2], upgrade to version [7.17.0] first.

Are there any means, say .yml config parameters, to force Elasticsearch 8.6 to start nevertheless, even without starting the index? I would prefer to get corrupted index data rather than having Elasticsearch which fails to start at all.

For some reasons both obvious ways: removing all index data before starting Elasticsearch 8.6 and starting Elasticsearch 7.17 before starting Elasticsearch 8.6, which it is prescribed by the log message, are inconvinient in this case.

[Christian_Dahlqvist]

@Leonid_P

Are there any means, say .yml config parameters, to force Elasticsearch 8.6 to start nevertheless, even without starting the index?

No, there is not.

@Leonid_P

For some reasons both obvious ways: removing all index data before starting Elasticsearch 8.6 and starting Elasticsearch 7.17 before starting Elasticsearch 8.6, which it is prescribed by the log message, are inconvinient in this case.

Why is this?

[Leonid_P (Leonid)]

Thank you for replying!

To say in few words there is a bunch of servers, with Elasticsearch 7.13 on some of them and Elasticsearch 7.17 on the others. My task is to create a sort of script which on the one hand will save the data when it is possible (i.e. on the servers with 7.17), and on the other hand will start Elasticsearch 8.6 anyway.

The set of tools in this sort of script is very limited, that's why it is not possible to start one version of Elasticsearch after another.

[Christian_Dahlqvist]

If the scripts have limited capabilities, why then not create two scripts - one that upgrades the environment to 7.17 (run on all environments first) and one that then subsequently migrates to version 8.9?

[Leonid_P (Leonid)]

Unfortunately it should a single universal script. It seems that we have to expand its capabilities by some means.

BTW, isn't it possible to change data folder for running Elasticsearch, for example switch path.data with PUT request, something like that? It could be also a way to solve my issue.

[Christian_Dahlqvist]

No, that is not possible.

[Leonid_P (Leonid)]

Thank you!

[Andrew_Mora]

@Leonid_P

Hi there!

I tried to start Elasticsearch 8.6 with loading data from index which was initially created by Elasticsearch 7.13. It fails to start with message

[2023-09-20T11:17:13,331][ERROR][o.e.b.Elasticsearch ] [node_1] fatal exception while booting Elasticsearch
java.lang.IllegalStateException: cannot upgrade a node from version [7.13.4] directly to version [8.6.2], upgrade to version [7.17.0] first.

Are there any means, say .yml config parameters, to force Elasticsearch 8.6 to start nevertheless, even without starting the index? I would prefer to get corrupted index data rather than having Elasticsearch which fails to start at all.

For some reasons both obvious ways: removing all index data before starting Elasticsearch 8.6 and starting Elasticsearch 7.17 before starting Elasticsearch 8.6, which it is prescribed by the log message, are inconvinient in this case.

Attempting to force Elasticsearch 8.6 to start without upgrading the index directly from version 7.13.4 to 8.6.2 is not recommended as it can lead to data corruption or issues. It's advisable to follow the prescribed steps of upgrading to version 7.17.0 first to ensure a smooth transition and data integrity. AC Football Cases

[Leonid_P (Leonid)]

Yes, I see, but in my particular case data corruption is better than failure to start the cluster at all.