Here is how I do it: 1. Have index called foo_1392831890 with alias foo pointing to it 2. Create index called foo_1392841890 with new config 3. Scan/scroll everything from the foo alias into foo_1392841890. 4. Swap alias. Time has now warped backwards. 5. Run script to reindex everything that happened since I created foo_1392841890 from the system of record.
If you happen to use jobs to update your index you can pause them during this process which would prevent things from going back in time. They'd just stall instead. Another option is to index into both indexes once they exist. At this point you'd have to do it manually. I imagine that'd actually be a nice feature for Elasticsearch to add though. Nik On Wed, Feb 19, 2014 at 5:15 AM, [email protected] < [email protected]> wrote: > Zero downtime works by using the atomic switch in the index alias setting. > > Here is an example, which also allows to decommission nodes for > maintenance. > > 1. your index I1 with data is distributed on node (groups) N1 and N2 > 2. create an alias A for I1 > 3. direct your search API to alias A > 4. create a new index I2 only on N1. I2 may have other parameters than I1, > the old index. > 5. you may decommission N2 now. All shards of I1 move to N1 automatically. > 6. direct your (re-)indexing API to I2, and index unless I2 contains all > the docs of I1 > 7. switch alias A from I1 to I2. This is atomic. > 8. you may drop index I1 now > 9. maintain N2 (update software, hardware) > 10. let N2 rejoin and disable decommissioning of N2 > 11. index I2 distributes shards over N1 and N2 > > Does this help? > > Jörg > > > > On Wed, Feb 19, 2014 at 5:41 AM, Andrew Kane <[email protected]> wrote: > >> Hi, >> >> I've followed the documentation for zero-downtime mapping changes and it >> works great. >> http://www.elasticsearch.org/blog/changing-mapping-with-zero-downtime/ >> >> However, there is a (pretty big) race condition with this approach - >> while reindexing, changes may not make it to the new index. I've looked >> all over and haven't found a single solution to address this. The best >> attempt I've seen is to buffer updates, but this is tedious and still >> leaves a race condition (with a smaller window). My initial thoughts were >> to create a write alias that points to the old and new indices and use >> versioning. However, there is no way to write to multiple indices >> atomically. >> >> It seems like this issue should affect most Elasticsearch users (whether >> they realize it or not). Does anyone have a good solution to this? >> >> Thanks, >> Andrew >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/f633b7d6-67a6-464f-b0ad-fe478ae85cc6%40googlegroups.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGcK-ddBULqZWQ03bme%3DQVFTzoWtiZ43DiuzErpM606qQ%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd01SwqXwHxEj76GcM3yo6jwqBpTFbn4VutGzKGQv_h41Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
