@tatdat How many nodes do you have in your cluster? Do they all have X-Pack installed and did any of the nodes successfully upgrade before you hit the ML parsing exception?
Is it possible that this node upgraded successfully in which case the cluster state is now version 6.0 and can't be read by version 5.6.2.
The error comes from X-Pack Monitoring but I suspect you would see it even if monitoring was disabled.
I apologize, @dkyle, I should have been more clear.
The APIs do not show any jobs for me to be able to delete, and I don't remember the name to ask for it specifically. As I mentioned, I think the .ml indexes were deleted, so when I query for all I get an index not found.
I am still good while running on 5.6.3, but cannot make the move to 6.0.0 without these errors. It looks like those three types exist somewhere, but I don't have a clue where.
Hope this explains better, and thank you for your help and patience.
The ML jobs are stored in the Elasticsearch cluster state not the indices. Even after deleting the indices you should be able to list the jobs via the API
@tatdat Thanks for sending the log file the root cause seems to be a fatal error:
[2017-11-25T00:19:54,082][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [Elastic-03] fatal error in thread [elasticsearch[Elastic-03][clusterService#updateTask][T#1]], exiting
java.lang.ClassFormatError: Incompatible magic value 1347093252 in class file org/elasticsearch/license/LicenseVerifier
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:1.8.0_121]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:1.8.0_121]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) ~[?:1.8.0_121]
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) ~[?:1.8.0_121]
at java.net.URLClassLoader.access$100(URLClassLoader.java:73) ~[?:1.8.0_121]
For some reason the LicenseVerifier could not be found. This is not my area of expertise I would try creating a new install of elasticsearch and x-pack. If that fails could you create a new question with a more specific title please.
This constant is famous: it's the magic number for ZIP files (the 0x504B is PK for Phil Katz).
Well I did not know that! I actually decoded the number one byte at a time once I got to PK I assumed it was something to do with keys and was then a little surprised the 3rd byte was end-of-text. Good to know.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.