Multi core setup is the default for Solr 5 and above but unfortunately not supported by collective.solr.
You can access a multicore Solr but only the default core,
which can be specified in the
collective.recipe.solrinstance buildout recipe.
The following options only apply if
collective.recipe.solrinstance:mc is specified.
They are optional if the normal recipe is being used.
All options defined in the solr-instance section will we inherited to cores.
A core could override a previous defined option.
A list of identifiers of Buildout configuration sections that correspond to individual Solr core configurations. Each identifier specified will have the section it relates to processed according to the given options above to generate Solr configuration files for each core.
Each identifier specified will result in a Solr
instanceDirbeing created and entries for each core placed in Solr’s
Optional and deprecated. This option controls which core is set as the default for incoming requests that do not specify a core name. This corresponds to the
defaultCoreNameoption described at http://wiki.apache.org/solr/CoreAdmin#cores. No longer used in Solr 5.
An example for a multi-core configuration you can find in the documentation of
collective.solr comes with some predefined Munin configuration.
The values for Munin are collected and exposed via the Java JMX framework.
You will need Munin and the JMX_ extension.
The Munin config however seems a little outdated.
Different host setup¶
One use case in a production setup might be the split between the Plone server runs on and the Solr server(s). To make this happen you have to consider a couple of things:
configure host of Solr in
collective.solr, it can be done TTW (Through-The-Web), via ZCML or via /etc/hosts
make sure the blobstorage directory of Plone is available via a network drive to the Solr host. You need to make sure Solr has read permissions which means it has the SAME User ID than the user which runs the Zope server.