Hi, Snapshot/restore is fine to run on an active, production system. The indices are still available for normal indexing and searching operations. You can throttle the snapshot operation if you are concerned about impacting production quality of service [1].
I would suggest avoiding using scroll as a backup strategy. Keeping a scroll open for a long time can be taxing on an actively used production cluster. You are much better off using the snapshot/restore functionality. Andrew 1. http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-snapshots.html On Apr 21, 2014, at 9:23 AM, Mohit Anchlia <mohitanch...@gmail.com> wrote: > Our data centers are a actively used and need to be highly available. Does > snapshot and restore happen in the background and indexes are still available > to the clients for read/write? > > Can Scroll be used to read indexes continuously and insert/update them? > > On Mon, Apr 21, 2014 at 5:57 AM, Alexander Reelsen <a...@spinscale.de> wrote: > hey, > > snapshot and restore might be an option, if you are willing to accept a lag a > few minutes behind. another option might be to index/update/delete all your > data into two different clusters, so you dont need replication at all? > > > --Alex > > > On Fri, Apr 18, 2014 at 10:19 PM, Mohit Anchlia <mohitanch...@gmail.com> > wrote: > As I understand there is currently no feature that does async replication > between 2 clusters or even within the same cluster, but we have a need to > write one. What would be the best way to do it in elasticsearch? I was > thinking of leveraging Scroll for this. > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAOT3TWrUdDdiqy62yHaaS6bJJ08_txDCNNXR8rGr%3DRGY8gAv-Q%40mail.gmail.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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAGCwEM9G8539fUmrzLWgkXoSYAEyUYkjUbyjeBiNVhBdarWTFA%40mail.gmail.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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpqVdoSWv552vh3ZOL7siBiMUCGRUV5NcBwAFoWPisVLQ%40mail.gmail.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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/B852C0E8-A2BE-4C23-B14A-EE2593A4D7ED%40elasticsearch.com. For more options, visit https://groups.google.com/d/optout.
