Thanks Chris. So, assuming that we rebuild the index, delete the old data and then execute a commit, will the snap scripts take care of reconciling all the data ? Internally, is there an update timestamp notion used to figure out which unique id records have changed and then synchronize them by executing delete/insert ops ?
Chris Hostetter wrote: > > > : Thanks. The problem is, it is not easy to do an incremental update on > the > : data set. > : In which case, I guess the index needs to be created in a different path > and > : we need to move > : files around. However, since the documents are added over HTTP, how does > one > : even create > : the index in a different path on the same machine while the application > is > : still running ? > > for the record, i don't think you *have* to do this ... allthough it will > certianly work fine if you want to (since it's just hte master/slave model > starting with an empty index) > > if in your current model, you have an index which you never modify, and > you regularly build a new index on a new path and then replace it, you > could do the same thing with a single Solr instance by indexing all of > your new documents on the same index, then deleting all docs older then > your newest "rebuild" (using a timestamp field) and then and only then > issue a commit to tell Solr to start using the new index. > > as long as no one else issues a commit while you are "rebuilding" your > index will allways look consistent. > > But as i said: the master/slave model will work perfectly for what you > want as well -- and the snap* scripts will take care of loading it up on > your slave. > > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Realtime-directory-change...-tf2867482.html#a8082000 Sent from the Solr - User mailing list archive at Nabble.com.
