Nik, that actually what Clinton Gormley responded to me on twitter when I asked the same question. I believe it is the way to go, but still we have that little time frame between your steps 4 and 5. A request asking for a document on foo may lead to no results when this document has been indexed while doing step 3. Do you agree?
Matthias Am Mittwoch, 19. Februar 2014 21:35:56 UTC+1 schrieb Nikolas Everett: > > 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] <javascript:> < > [email protected] <javascript:>> 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]<javascript:> >> > 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] <javascript:>. >>> 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] <javascript:>. >> 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/c13c1dbd-1666-4120-8309-8672f0476996%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
