See this article if you haven’t already set up Zookeeper for SolrCloud. Liferay also has documentation for setting up Solr and SolrCloud. I found this documentation good for the former and not so good for the latter. Starting at step 4 I found their way confusing and chose a different path. I will place the first three steps in this article as well in case the original content is moved/removed.
First you want to follow Liferay instructions to setup a standalone Solr server. If you have never setup Solr before this is recommended. It gives you a feel for how Solr should work. The key takeaways is you create a configuration in Solr for liferay by copying the default Solr configuration and overwriting some of its files with files from the Liferay Connector to Solr 7 package. The package can be found on the Liferay Marketplace.
Stop the Solr server if it’s running.
Navigate to the Solr_Home/configsets folder and create a folder called liferay_configs
Copy the conf folder from Solr_Home/liferay to the liferay_configs folder you just created. The
configset/liferay_configs folder contains the SolrCloud Liferay Portal collection configuration and is uploaded to ZooKeeper. By copying the conf folder from the liferay
server configured earlier, you’re using the schema.xml and solrconfig.xml files provided with the Liferay Solr Adapter.
Next we want to edit the solr.in.sh file and add all of our Zookeeper hosts.
We need to create our Zookeeper chroot which we will define as “/solr”. This should allow us to use zookeeper for other purposes. The end of line 54, of the previous code snippet, is referencing the chroot. A znode is created that acts as a root directory for our Solr information that will keep it seperate from other applications that use the same instance of Zookeeper.
/your/directory/path/solr/bin
Now we run our command to load the configset as a collection we made when we followed the Liferay directions. We also need to determine the number of shards and replicas we need. Shards are logical seperation of document storage. If you have two shards then a document will only be stored in one of them. Replicas are copies of all the documents stored. If you have one shard and two replicas then there will be one logical storage area and two copies. For our deployments we want one replica for each Solr instance. We have two Solr instances. We then specify two replicas usin the “-rf 2” option as shown below.
First start solr in cloud mode so we can make the configuration. Then run the create command to configure the core, shards and replicas.
/your/directory/path/solr/bin
This should create one configuration for each replica you specified. Directories will look close to the below.
/your/directory/path/solr/server/solr
Finally we want to move liferay_shard1_replica_n2 directory to our second instance and start both Solr servers in cloud mode.
As I was working through moving from Solr 4 to Solr 7 I encountered errors (below) concerning coreNodeName. This seems to concern replicas and how they were handled in early versions of Solr. There is a reference to this change, but it contains little information. From what little information was available it seems the legacyCloud being set to true obfuscates the number of replicas in your deployment.
In my situation I needed to deploy Solr in sets of 2 or 4 depending on the environment. The number of documents is small, so only one shard. I did want redundancy and responsiveness. Which means I should have one replica for each Solr instance I plan to deploy.
/your/directory/path/solr/server/logs/solr.log
Though it is not recommended you can work around this problem with the command below. After reading Major Changes in Solr 7. This shouldn’t be necessary if you followed the directions at the beginning of this page.