My situation is: I have a big index (let's call it old) that allows search on documents that I derive from information in a relational database. I need to change the index mapping and add data to every document, and the easiest way I see to do that is to re-derive every document from the database and insert it into a new index (let's call it new) that is configured with the updated mappings.
Unfortunately, this process is going to take some time, and it would be great if, in the middle of the migration, my application had access to the new versions of already-migrated documents and could fall back to the old versions of documents that haven't been migrated yet.
My first attempt at achieving this was to set up an alias, merged, where both old and new pointed to merged with new being the write index. Unfortunately, once the process got going, new contained documents that had the same ID as documents in old, and that caused Elasticsearch to throw an error.
Is there any way to set things up so that instead of throwing an error, I could configure Elasticsearch to prefer documents from new and fall back on old only if nothing is found for new? Given that I found nothing about it in the reference, I am guessing the answer here is "no" -- if that's the case, then is there another approach I could take to this migration that would work better?
Thanks! Any insights would be appreciated.