On the path to a massive scale SolrCloud: removing Overseer
summary
SolrCloud removes the single Overseer bottleneck by making nodes update cluster state directly in Zookeeper using compare-and-swap (CAS) for state.json and coordinating long-running Collection/Config Set commands with Zookeeper-based distributed locks. Asynchronous Collection API semantics are preserved via a mix of persistent and ephemeral znodes. Distributed mode is opt-in today and can be enabled in Solr 9; most Collection API operations become faster, while high-contention concurrent state mutations may incur retries.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 2:22Understanding SolrCloud architecture
- 6:37Limitations of the Overseer
- 10:55Proposed distributed architecture
- 15:19Implementing state changes
- 18:38Distributed locking strategy
- 22:26Asynchronous API execution
- 25:49Benefits and deployment plan
- 30:37Future scaling work
- 35:42Q&A session
related talks
44mOpenSearch’s Quest for Disaggregated Storage: The Strangler Fig Patter...
41mCross Data Center Replication in Solr - A new approach
31mSharding 2.0: Unlocking Infinite Search Scalability in OpenSearch
37mInside Onyx
24mOxia - A Horizontally Scalable Alternative to Apache Zookeeper
39mScaling OpenSearch: Next-Generation Shard Allo...
44mScaling OpenSearch at Uber: Operating Resilient, Fault-Tolerant, High-Performance Clus...
15mUnconference Session: Dedicated Coordination Nodes - Why? When? How?
