This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
Use Case: Redundant Architecture for Solr Master in a WebSphere Commerce V8 environment
In this blog I’d like to share my experience in setting up a redundant architecture for the Solr master in a WebSphere Commerce V8 environment as a reference guide.
The requirement is to switch to a failover Solr master within non or minimal downtime of the Solr master. As the Solr slaves can continue working without the Solr master, a minimal downtime of the Solr master is acceptable in most cases.
If you have your WebSphere Commerce environment in a distributed operations center, there are two scenarios that have to be covered:
The architecture developed will cover both of these scenarios.
The underlying idea is, to have one active Solr master and a second backup master, which always replicates the latest index and can take over index building immediately.
The load balancer solrM.domain.xyz is configured to prefer the primary Solr master node solrMANode1_1. In normal operation, this node is building the index. Only, if this node is not reachable, the load balancer switches to the backup node solrMANode2_1.
The load balancer is setup, to keep the configuration after switching automatically over to solrMANode2_1, as after a failover the solrMANode1_1 need to be up for some time to replicate the latest index from solrMANode2_1. After this a (manual) switch back can be done.
The Solr slaves are polling their index using the logical domain name of the load balance solrM.
Also the administrative commands send from the Commerce Server to the Solr master are send to the logical name solrM.domain.xyz.
This are the steps used during configuration of the environment, prerequisite is that the Commerce environment is setup using the setup procedures from the Commerce Knowledge Center :
Setup index replication between the primary and backup Solr master:
Both of the Solr master nodes are configured to replicate the index with each other, means they are both setup as a repeater.
Sample configuration snippet:
<requestHandler name="/replication" class="com.ibm.commerce.foundation.internal.server.services.search.handler.solr.SolrSearchReplicationHandler">
As the configuration settings are made in the solrcore.properties file, this will be for the primary and backup Solr master node:
Configure the Solr slaves to poll the index using the logical domain name of the Solr master load balancer:
For each of the Solr slaves modify the solrcore.properties:
Configure the Search Server Admin Host:
For more information please check the Replicating WebSphere Commerce Search with the repeater page in the Commerce Knowledge Center.
Update the srchconf table to reflect the new Search master server, set the SearchServerName to the logical domain of the Solr master (load balancer):
select * from srchconf
Thank you to
Daniel Dunn, IBM Commerce Development
for the help on developing this architecture.