Rolling Restarts

This feature is also available as part of the SearchStax Deployment API suite and can be run programmatically like any other REST API. Now users can issue a Rolling Restart command and know that servers will be restarted one-at-a-time, with back-end systems checking Solr replicas’ health on the most recently restarted server before the next server restart initializes to ensure that service uptime and availability are not impacted. 

Rolling Restarts can come in handy for various use cases. Below are some common scenarios which users and even our team encounter the need for using Rolling Restarts:

• Change Management – If users ever need to update runtime libraries or various configurations, restarting Solr becomes a necessity post-update to ensure changes have been refreshed on all servers.
• JVM Heap Memory over-utilization – JVM Heap Memory utilization can sharply or steadily rise on a system. Users should always troubleshoot and optimize the underlying cause, but Rolling Restarts offer Solr users with a stopgap option to reset utilization in the meantime.
• High Transaction rates – SolrCloud clusters are effective at exchanging updates via internode communication but if resource utilization is running high, Transaction Logs (T-Logs) can build up and reduce Solr’s ability to provide near-real-time (NRT) replication. The symptom of this can be that the same search query returns different search results. Rolling Restarts can help alleviate the buildup of unprocessed T-Logs and return Solr nodes to a state of parity. 
• General Troubleshooting – Rolling Restarts allow users to remove many factors which may be at play while troubleshooting a live production cluster. It’s not uncommon for users to want to trigger a Rolling Restart at the onset of ongoing incident investigations to help narrow down the root cause.