I am using Curator version 3.5.1 and we are trying to set this up on an old Elasticsearch Version 1.1.2.
When I run the following (with --dry-run): curator --dry-run --host 127.0.0.1 snapshot --repository Elasticsearch2-Repo-S3 indices --older-than 53 --time-unit days --timestring '%Y.%m.%d'
It lists several Indices it will Snapshot, However when I run it without --dry-run it fails withthe following:
2017-03-07 15:54:48,815 INFO Job starting: snapshot indices
2017-03-07 15:54:48,816 INFO Overriding default connection timeout for snapshot action. New timeout: 21600
2017-03-07 15:54:48,902 INFO Action snapshot will be performed on the following indices: [u'applogs-2017.01.13', u'latencymetrics-2017.01.13', u'preadvicemetrics-2017.01.13']
2017-03-07 15:54:48,917 ERROR No indices provided.
2017-03-07 15:54:48,917 WARNING Job did not complete successfully.
Without re-running with --debug, I won't be able to offer any more insight. 1.1.2 is a very old version of Elasticsearch, and many of the early bugs in the snapshot API were yet to be worked out.
Here is the same command with the debug option - Is there a way of attaching a txt file. appartley there is a limit on chars, and this is way way over that
Yes I understand that 1.1.2 is very old, but we have some legacy apps that are using this.
Because the cluster state response is so very different from 1.4.x, Curator is not receiving an anticipated response—specifically, whether the index is open or closed. As a result, it fails, and removes the index from the actionable list.
Curator 3.5.1 can do many, if not most other actions for 1.1.2, but apparently not Snapshot.
Potential workarounds include using the show indices action, and using the output with a scripted curl call.
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.