If you are using master/slave (non-cloud), here is an approach. 1. Build a new master with the new schema. 2. Index all content there. 3. Send all updates to both the old master and new master. 4. One by one, take a slave down, delete all the documents, configure with the new schema and new master, then replicate. 5. When finished, stop sending updates to the old master and turn it off.
It is a hassle, but it is guaranteed to work. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Mar 13, 2017, at 5:48 AM, Shawn Heisey <apa...@elyograg.org> wrote: > > On 3/13/2017 3:07 AM, danny teichthal wrote: >> I have a limitation that our Solr cluster is "live" during full >> indexing. We have many updates and the index is incrementally updated. >> There's no way to index everything on a side index and replace. So, >> I'm trying to find a solution where users can still work not depending >> on my full indexing. > > This is extremely common. In fact, I would say it probably applies to > most production Solr indexes. > > There are two options that you always have with Solr. One is an option > if you're NOT running SolrCloud, the other is an option if you ARE > running SolrCloud. > > Without SolrCloud, you can build a new core with the settings you want, > and once it is fully built and contains the same documents as the > primary core, atomically swap it with the primary. The directories will > retain the old names, but the *cores* will change names. You would have > the option of fixing the directory names later, by shutting down and > renaming. Depending on which version of Solr, a config file might also > need updating. > > With SolrCloud, you can create a new collection, and then delete the old > one and create an alias with the name of the old collection. All > accesses to the old collection name will be redirected to the alias > destination. > >> I thought about another option: 1. Add a new field - "id_str". 2. Let >> periodic full indexing run. 3. Somewhere later during full change the >> uniqeKey from my "id" to "id_str". May this work? Assuming that all >> ids are unique? > > I think this would also work. I have not tried it. > > Thanks, > Shawn >
