1

I'm trying to figure out the best way to deploy solr (6.6.6) on two nodes in conjunction with Drupal 7 to provide some kind of resilience.

The first problem is that Drupal only supports the concept of a single solr instance. So even if multiple solr servers are implemented, load balancing external to drupal is needed somewhere in the environment. Which is extra complexity that I'd like to avoid, at least in the short-term.

The second problem is that I only have 2 servers available. So SolrCloud is out as the ZooKeeper node means I'm back down to a single solr server without resilience, and is probably overkill for my small environment anyway.

I could configure the two solr servers as Master / Slave, but this runs into the problem that Drupal doesn't support the concept of two solr nodes without load balancing. But even if load balancing were implemented, if the Master were lost and I reconfigured the Slave as a Master, I have nothing to respond to search queries as Master nodes just maintain the index.

I've even looked at running Master and Slave on the same node, which appears technically possible. But that doesn't really seem to solve anything.

If I'm faced with manual intervention, I'd be happy to have the second solr server as a standby, with the solr indexes replicated to it. But that seems to require the Master / Server config which Drupal doesn't support without load balancing...

Which brings me to my questions:

  1. Am I missing anything obvious here, that would allow a 2nd solr node to provide some form of resilience (even manual) for drupal, without external load balancing?
  2. What seems best to me at the moment, is deploying two single standalone solr servers, with one active. Then using Solr's backup facility on the active server, replicating the backups to the standby node via rsync, and then restoring the backups on the standby node. This means that I have a fairly up-to-date 2nd solr server ready to go, and just a minor config change in Drupal to bring it on-line. Are there any flaws in this approach, or better ideas?
Pang
  • 273
  • 3
  • 8
P Burke
  • 163
  • 1
  • 10

0 Answers0