lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Replacing a Solr index on the fly using SolrJ
Date Fri, 01 Aug 2014 14:54:14 GMT
On 8/1/2014 3:21 AM, Sören Schneider wrote:
> I'm looking for a way to (programmatically) replace a Solr index
> on-the-fly using SolrJ, just as mentioned in Solr CoreAdmin Wiki[1]. I
> already managed to create a dump of the index on-the-fly.
> The intention is to use the dump transparently while rebuilding the
> "original" index to achieve that the index and all its files stay
> online. When the reindexing process is finished, the dump gets
> replaced vice versa with the recent index.
> If there's another way to solve this problem, please let me know.

This sounds like a job for core swapping -- build up a new index in
another core, then swap that core with the old one.  I assume from your
description that you are not using SolrCloud.  SolrCloud changes things,
for that you would need to use collection aliasing -- swapping cores in
SolrCloud mode is likely to cause some serious breakage.

Here's the "swap" method in my Core object:

     * Swap one Solr core with another.
     * @param other Core representing the other core to swap with.
     * @throws BuildException
    public final void swap(Core other) throws BuildException
        CoreAdminRequest car = new CoreAdminRequest();
   + _name + ": swapped with " +
        catch (Exception e)
            throw new BuildException("Failed to swap cores on " +
_prefix + _name, e);

The _serverSolr object is an instance of HttpSolrServer, set to
http://host:port/solr ... I also have a _querySolr object that is set to
http://host:port/solr/corename ... that one gets used for
queries/updates.  The updateDirectories method looks up the new
instanceDir and dataDir and populates class members with the correct info.

I'm using the old solr.xml format.  Below is how I have defined two
cores that get swapped.  I used more generic directory names so that I
won't ever have a "live" core that points to a directory that says
"build" ... that would be really confusing:

    <core name="s1build" instanceDir="cores/s1_1/" loadOnStartup="true"
dataDir="../../data/s1_1" transient="false"/>
    <core name="s1live" instanceDir="cores/s1_0/" loadOnStartup="true"
dataDir="../../data/s1_0" transient="false"/>


View raw message