Does snapshot/restore do any analysis on restore?


(Harry Waye-2) #1

I'm hoping to use Snapshot/Restore to shelter our production cluster from
the load entailed from reindexing our indices. I'd be interested in
knowing whether this is something it would provide or if analysis would be
involved either way. We have a dataset that we'd like to index without
worry of affecting queries. We could throttle indexing to reduce effect
but this has proved to be a difficult endeavour. I'd prefer that any cpu
intensive ops occur away from production. How do others deal with this
scenario?

Our other option would be to maintain two clusters and switch between the
two. To maintain would mean quite an investment in hardware and I'd prefer
to look at other options first.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/e6d9432e-3306-48fe-b210-b5953be26d52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(David Pilato) #2

Snapshot/restore "just" save Lucene files (and some metadata).
Restoring does not imply any analysis process.

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 25 mars 2014 à 00:54, Harry Waye harry@arachnys.com a écrit :

I'm hoping to use Snapshot/Restore to shelter our production cluster from the load entailed from reindexing our indices. I'd be interested in knowing whether this is something it would provide or if analysis would be involved either way. We have a dataset that we'd like to index without worry of affecting queries. We could throttle indexing to reduce effect but this has proved to be a difficult endeavour. I'd prefer that any cpu intensive ops occur away from production. How do others deal with this scenario?

Our other option would be to maintain two clusters and switch between the two. To maintain would mean quite an investment in hardware and I'd prefer to look at other options first.

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/e6d9432e-3306-48fe-b210-b5953be26d52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/5ACC6FAD-5ACB-47F4-9B58-54492B69468B%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.


(Harry Waye-2) #3

Excellent great thanks David

On Tuesday, March 25, 2014 5:56:55 AM UTC, David Pilato wrote:

Snapshot/restore "just" save Lucene files (and some metadata).
Restoring does not imply any analysis process.

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 25 mars 2014 à 00:54, Harry Waye <ha...@arachnys.com <javascript:>> a
écrit :

I'm hoping to use Snapshot/Restore to shelter our production cluster from
the load entailed from reindexing our indices. I'd be interested in
knowing whether this is something it would provide or if analysis would be
involved either way. We have a dataset that we'd like to index without
worry of affecting queries. We could throttle indexing to reduce effect
but this has proved to be a difficult endeavour. I'd prefer that any cpu
intensive ops occur away from production. How do others deal with this
scenario?

Our other option would be to maintain two clusters and switch between the
two. To maintain would mean quite an investment in hardware and I'd prefer
to look at other options first.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/e6d9432e-3306-48fe-b210-b5953be26d52%40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/e6d9432e-3306-48fe-b210-b5953be26d52%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/dfea7ce8-cdf7-4775-bbc6-b7d4c36ed54f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(system) #4