I have found myself in an uncomfortable spot where I have to migrate data off of ES 0.90.3 (I have no access to the server itself, just to the data) and into a different ES 1.7.x (here I have full access).
So far I have tried two approaches:
elasticdump (did not work, as it requires ES 1.2 at least)
A plugin had an unrecoverable error. Will restart this plugin.
Plugin: <LogStash::Inputs::Elasticsearch hosts=>["some_host:9200"], index=>"id_prod", query=>"*", codec=><LogStash::Codecs::JSON charset=>"UTF-8">, scan=>true, size=>1000, scroll=>"1m", docinfo=>false, docinfo_target=>"@metadata", docinfo_fields=>["_index", "_type", "_id"], ssl=>false>
Error: [400] {
"error":"SearchPhaseExecutionException[Failed to execute phase [init_scan], all shards failed; shardFailures {
[i22flp_3TGWYPYsOkCG5OA][id_prod][0]: SearchParseException[[id_prod][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [na]]]; nested:
ElasticSearchParseException[Failed to derive xcontent from org.elasticsearch.common.bytes.ChannelBufferBytesReference@2a];
}{
[i22flp_3TGWYPYsOkCG5OA][id_prod][2]: SearchParseException[[id_prod][2]: from[-1],size[-1]: Parse Failure [Failed to parse source [na]]]; nested:
ElasticSearchParseException[Failed to derive xcontent from org.elasticsearch.common.bytes.ChannelBufferBytesReference@2a];
}{
[i22flp_3TGWYPYsOkCG5OA][id_prod][1]: SearchParseException[[id_prod][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [na]]]; nested:
ElasticSearchParseException[Failed to derive xcontent from org.elasticsearch.common.bytes.ChannelBufferBytesReference@2a];
}{
[i22flp_3TGWYPYsOkCG5OA][id_prod][4]: SearchParseException[[id_prod][4]: from[-1],size[-1]: Parse Failure [Failed to parse source [na]]]; nested:
ElasticSearchParseException[Failed to derive xcontent from org.elasticsearch.common.bytes.ChannelBufferBytesReference@2a];
}{
[i22flp_3TGWYPYsOkCG5OA][id_prod][3]: SearchParseException[[id_prod][3]: from[-1],size[-1]: Parse Failure [Failed to parse source [na]]]; nested:
ElasticSearchParseException[Failed to derive xcontent from org.elasticsearch.common.bytes.ChannelBufferBytesReference@2a]; }]",
"status":400} {:level=>:error}
I have verified that this is related to the source server (removed elasticsearch output from logstash config, leaving just stdout for testing). I have no idea what's going on there and the only thing I have found on the Internets is related to... the number of spaces in the data part of a query.
When you say you have access to the old data, do you mean the physical data itself (e.g. the data directory)?
I think the first thing I would try is to rsync that over to your new server's data directory, then try to start ES 1.7 and allow it to import the "dangling indices". I don't quite remember, but I don't think the underlying Lucene version has changed enough in that period of time to drop bwc for 0.90.
It'd be worth a try anyway, if you have the raw data directory.
Otherwise, I'm not sure. Make sure you are using the HTTP output for Elasticsearch (not the Java version, which uses the transport client and requires identical ES versions on LS + ES). The logstash folks in the logstash forum and/or #logstash IRC might be able to help more.
Worst case, you could always write a script to dump from one cluster to the other. The Python client for example has a Reindex Helper, which will execute a scan/scroll and reindex into a new index (or new cluster). You could also write something similar in your language of choice. Not ideal, but it'd be an effective option.
Yes, I seem to be able to connect to port 9300 on that server. I think I can safely assume, based on the history of that host, that ES has not been configured to use a different port for this.
If you are lucky, you can export your documents into a compressed archive file, and import it later with another knapsack version into a more recent ES version like 1.7
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.