On 11/11/2010 4:45 PM, Robert Gründler wrote:
So far, i can only think of 2 scenarios for rebuilding the index, if we need to
update the schema after the rollout:
1. Create 3 more cores (A1,B1,C1) - Import the data from the database - After
importing, switch the application to cores A1, B1, C
If by "corrupt index" you mean an index that's just not quite
up to date, could you do a delta import? In other words, how
do you make our Solr index reflect changes to the DB even
without a schema change? Could you extend that method
to handle your use case?
So the scenario is something like this
You can do a similar thing to your case #1 with Solr replication,
handling a lot of the details for you instead of you manually switching
cores and such. Index to a new core, then tell your production solr to
be a slave replicating from that master new core. It still may have some
of the same d
Hi again,
we're coming closer to the rollout of our newly created solr/lucene based
search, and i'm wondering
how people handle changes to their schema on live systems.
In our case, we have 3 cores (ie. A,B,C), where the largest one takes about 1.5
hours for a full dataimport from the relation
