If you use Apache Solr with your Drupal site, you have probably come across the need to have more than one Solr instance. You may have multiple sites, or just multiple copies of the same site, production and staging perhaps?
There are two widely published ways to accomplish that. One is to set up completely separate Solr instances with whatever Java-server you’re using. That is somewhat inefficient, and I was unable to get such a setup working properly anyways. So here’s the alternative, “multi core”.
The benefit of using multi core is that you avoid most of the
configuration overhead associated with figuring out how to get multiple
(or whatever they’re named in your brand of Java-server) to coexist by
using the same WAR-file but not the same configuration. I spent a lot of
hours trying to accomplish just that.
Instead, all the interesting stuff happens in the Solr configuration, which is a lot less confusing for a Java novice like me.
Install a Java JRE.
You may want to see my explanation on how to do this.
Install Jetty and Solr.
If you use
portmaster, this can be as simple as running
portmaster www/jetty textproc/apache-solr
Create a folder for your Solr multi core instance’s configuration and data files. This could be anywhere, but in this example, I’m going to use
/srv/solr/solr.xmlfile for the configuration, setting up the different cores into folders.
Mine looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
<?xml version="1.0" encoding="UTF-8" ?> <!-- All (relative) paths are relative to the installation path persistent: Save changes made via the API to this file sharedLib: path to a lib directory that will be shared across all cores --> <solr persistent="false"> <!-- adminPath: RequestHandler path to manage cores. If 'null' (or absent), cores will not be manageable via request handler --> <cores adminPath="/admin/cores" sharedLib="lib"> <core name="dev" instanceDir="dev" /> <core name="prod" instanceDir="prod" /> <core name="stg" instanceDir="stg" /> </cores> </solr>
Create all the folders referenced in the config file.
We specified four folders, so lets create them via a simple
mkdir dev lib prod stg(while standing in the
Make these folders owned by the user that will run our Solr instances. In this example, I’ll use the
wwwaccount, but it would be more secure to set up a separate account for running Solr if you have other web servers running on the same machine.
chown www:www dev lib prod stg
For each core you want to set up, copy or symlink the schema and other configuration files you need into the conf folder in each core folder. In this example, I’m copying the example configuration from
/usr/local/share/examples/apache-solr/solr/conf/. If you’re working with Drupal, be sure to copy the solr configuration it ships with into each core.
cp -r /usr/local/share/examples/apache-solr/solr/conf/* ./
cp -r prod/conf dev/
cp -r prod/conf stg/
In this example, we’re going to use Jetty to run the Solr service. I am not well versed in the Java lingo for this, but Jetty is a servlet container, so I guess that means Solr is being run as a servlet. I also tried this with Tomcat, but that was a lot harder to configure properly.
jetty_enable="YES"on a new line in
ln -s /usr/local/share/java/classes/apache-solr-3.2.0.war solr.war
ln -s /srv/solr
- Start Jetty by running
service jetty start
Hopefully, after all this work, Solr should be ready once its done booting up.
You can check that it’s working by running
curl -iL localhost:8080/solr/prod/admin/. This should output the HTML
for the admin interface.
If you have problems, try running
tail -f /usr/local/jetty/jetty.log
in one terminal, and then
service jetty restart in another, and look
what goes on as Jetty restart (there’ll be a lot of messages flying by,
but the error should be in there somewhere).