> On Mar 3, 2017, at 11:30 AM, Erick Erickson <erickerick...@gmail.com> wrote: > > One way to handle this (presuming SolrCloud) is collection aliasing. > You create two collections, c1 and c2. You then have two aliases. when > you start "index" is aliased to c1 and "search" is aliased to c2. Now > do your full import to "index" (and, BTW, you'd be well advised to do > at least a hard commit openSearcher=false during that time or you risk > replaying all the docs in the tlog). > > When the full import is done, switch the aliases so "search" points to c1 and > "index" points to c2. Rinse. Repeat. Your client apps always use the same > alias, > the alias switching makes whether c1 or c2 is being used transparent. > By that I mean your user-facing app uses "search" and your indexing client > uses "index". > > You can now do your live updates to the "search" alias that has a soft > commit set. > Of course you have to have some mechanism for replaying all the live updates > that came in when you were doing your full index into the "indexing" > alias before > you switch, but you say you have that handled. > > Best, > Erick >
Thanks. So, is this available on 4.10.4? If not, we used to gen another core, do the import, and, swap cores so this is possibly similar to collection aliases since in the end, the client did not care. I don’t see why that would not still work. Took a little effort to automate, but, not much. Regarding the import and commit, we use in data-config.xml readonly so this sets autocommit the way I understand it. Not sure what happens with opensearcher though. If that is not sufficient, how would I do hard commit and opensearcher false during that time? Surely not by modifying the config file?
