Solr

An application with a large document collection may need full-text search, filtering and other queries that a folder of files cannot provide. Apache Solr builds searchable indexes using Lucene and exposes search services over the indexed content. SolrCloud adds a distributed operating model, which the separate Solr Operator can manage on Kubernetes. The useful design depends on schemas, shards, replicas and the indexing workload, so adding pods alone does not establish good search performance or recoverability.

Current guidance

The old lucene.apache.org/solr address now redirects to solr.apache.org; that is a verified project relocation, not a replacement search product. Distinguish Solr server versions from a Helm chart and from the Apache Solr Operator.

For Kubernetes, the operator documentation describes SolrCloud management. Review the selected Solr, operator and ZooKeeper configuration together. Plan persistent storage, shard and replica placement, disruption behavior and resource limits around the query and indexing workload. Adding pods cannot fix a poorly sized shard layout or an unsuitable storage backend.

The operator’s backup guide distinguishes configuring backup repositories on SolrCloud from triggering backups with SolrBackup resources. Decide where backup bytes live and how retention is enforced; deleting the Kubernetes backup object does not itself delete the persisted backup data. Rehearse restore and schema or configset changes with representative queries before production upgrades. Protect the administrative API and avoid exposing an unauthenticated search cluster through a default ingress. This entry has not certified a release combination or measured search performance.