From 89a86a6f5bb51113c3f1909baf82fdda52262dcc Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 13 Mar 2026 02:57:56 +0000 Subject: [PATCH 01/11] Initial plan From d2f424638ed21971dd2c189ffbe763ef369391ef Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 13 Mar 2026 03:03:35 +0000 Subject: [PATCH 02/11] Move Cluster Concepts section under Solr Concepts in reference guide Co-authored-by: epugh <22395+epugh@users.noreply.github.com> --- .../configuration-guide/pages/configuration-files.adoc | 2 +- .../modules/configuration-guide/pages/coreadmin-api.adoc | 2 +- .../modules/deployment-guide/deployment-nav.adoc | 1 - .../modules/deployment-guide/pages/cloud-screens.adoc | 2 +- .../modules/deployment-guide/pages/installing-solr.adoc | 4 ++-- .../pages/solr-control-script-reference.adoc | 2 +- .../pages/user-managed-distributed-search.adoc | 2 +- .../pages/user-managed-index-replication.adoc | 2 +- .../modules/getting-started/getting-started-nav.adoc | 1 + .../pages/cluster-types.adoc | 0 .../modules/getting-started/pages/introduction.adoc | 2 +- .../modules/getting-started/pages/solr-admin-ui.adoc | 6 +++--- .../modules/getting-started/pages/solr-glossary.adoc | 2 +- .../modules/query-guide/pages/result-grouping.adoc | 2 +- .../modules/query-guide/pages/spell-checking.adoc | 2 +- 15 files changed, 16 insertions(+), 16 deletions(-) rename solr/solr-ref-guide/modules/{deployment-guide => getting-started}/pages/cluster-types.adoc (100%) diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc index 63b5eb3f8f51..44c0e0c502b0 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc @@ -96,7 +96,7 @@ The Files screen in the Admin UI lets you browse & view configuration files (suc .The Files Screen image::configuration-files/files-screen.png[Files screen,height=400] -If you are using xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper. +If you are using xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper. In user-managed clusters or single-node installations, all files in the `conf` directory are displayed. The configuration files shown may or may not be used by the collection as use of the file depends on how they are referenced in either `solrconfig.xml` or your schema. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc index 261caa7370f5..7b6434d4a386 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc @@ -18,7 +18,7 @@ // specific language governing permissions and limitations // under the License. -The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster. +The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster. SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or single-node installations for core maintenance operations. diff --git a/solr/solr-ref-guide/modules/deployment-guide/deployment-nav.adoc b/solr/solr-ref-guide/modules/deployment-guide/deployment-nav.adoc index 55301601e3e0..04dfeb766436 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/deployment-nav.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/deployment-nav.adoc @@ -30,7 +30,6 @@ *** xref:docker-faq.adoc[] * Scaling Solr -** xref:cluster-types.adoc[] ** SolrCloud Clusters *** xref:solrcloud-shards-indexing.adoc[] *** xref:solrcloud-recoveries-and-write-tolerance.adoc[] diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc index a4f23232d45f..70e1c12c08c4 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc @@ -21,7 +21,7 @@ This screen provides status information about each collection & node in your clu .Only Visible When using SolrCloud [NOTE] ==== -The "Cloud" menu option is only available when Solr is running xref:cluster-types.adoc#solrcloud-mode[SolrCloud]. +The "Cloud" menu option is only available when Solr is running xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud]. User-managed clusters or single-node installations will not display this option. ==== diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc index 15cc9898a026..4fc9b6cea35d 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc @@ -59,7 +59,7 @@ A very good blog post that discusses the issues to consider is https://lucidwork One thing to note when planning your installation is that a hard limit exists in Lucene for the number of documents in a single index: approximately 2.14 billion documents (2,147,483,647 to be exact). In practice, it is highly unlikely that such a large number of documents would fit and perform well in a single index, and you will likely need to distribute your index across a cluster before you ever approach this number. -If you know you will exceed this number of documents in total before you've even started indexing, it's best to plan your installation with xref:cluster-types.adoc#solrcloud-mode[SolrCloud] as part of your design from the start. +If you know you will exceed this number of documents in total before you've even started indexing, it's best to plan your installation with xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] as part of your design from the start. == Package Installation @@ -197,7 +197,7 @@ Currently, the available examples you can run are: techproducts, schemaless, and See the section xref:solr-control-script-reference.adoc#running-with-example-configurations[Running with Example Configurations] for details on each example. .Going deeper with SolrCloud -NOTE: Running the `cloud` example demonstrates running multiple nodes of Solr using xref:cluster-types.adoc#solrcloud-mode[SolrCloud] mode. +NOTE: Running the `cloud` example demonstrates running multiple nodes of Solr using xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] mode. For more information on starting Solr in SolrCloud mode, see the section xref:getting-started:tutorial-solrcloud.adoc[]. === Check if Solr is Running diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc index a7348059cc2e..25740a026258 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc @@ -339,7 +339,7 @@ For more information about starting Solr in SolrCloud mode, see also the section `bin/solr start --user-managed` starts Solr in User Managed mode (AKA Standalone mode). This was the default mode up until Solr 10x. -For more information about the different modes, see the section xref:deployment-guide:cluster-types.adoc[]. +For more information about the different modes, see the section xref:getting-started:cluster-types.adoc[]. ==== Running with Example Configurations diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc index 460039639cab..cb59d1349081 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc @@ -18,7 +18,7 @@ When using traditional index sharding, you will need to consider how to query your documents. -It is highly recommended that you use xref:cluster-types.adoc#solrcloud-mode[SolrCloud] when needing to scale up or scale out. +It is highly recommended that you use xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] when needing to scale up or scale out. The setup described below is legacy and was used prior to the existence of SolrCloud. SolrCloud provides for a truly distributed set of features with support for things like automatic routing, leader election, optimistic concurrency and other sanity checks that are expected out of a distributed system. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc index ea3f0f376747..2b8a453694a5 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc @@ -43,7 +43,7 @@ Configuring replication is therefore similar to any normal request handler. .Replication In SolrCloud [NOTE] ==== -Although there is no explicit concept of leader or follower nodes in a xref:cluster-types.adoc#solrcloud-mode[SolrCloud cluster], the `ReplicationHandler` discussed on this page is still used by SolrCloud as needed to support "shard recovery" – but this is done in a peer to peer manner. +Although there is no explicit concept of leader or follower nodes in a xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud cluster], the `ReplicationHandler` discussed on this page is still used by SolrCloud as needed to support "shard recovery" – but this is done in a peer to peer manner. When using SolrCloud, the `ReplicationHandler` must be available via the `/replication` path. Solr does this implicitly unless overridden explicitly in your `solrconfig.xml`. diff --git a/solr/solr-ref-guide/modules/getting-started/getting-started-nav.adoc b/solr/solr-ref-guide/modules/getting-started/getting-started-nav.adoc index 095f679f93b6..562ba636558e 100644 --- a/solr/solr-ref-guide/modules/getting-started/getting-started-nav.adoc +++ b/solr/solr-ref-guide/modules/getting-started/getting-started-nav.adoc @@ -23,6 +23,7 @@ ** xref:solr-indexing.adoc[] ** xref:searching-in-solr.adoc[] ** xref:relevance.adoc[] +** xref:cluster-types.adoc[] ** xref:solr-glossary.adoc[] * xref:solr-tutorial.adoc[] diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/cluster-types.adoc b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc similarity index 100% rename from solr/solr-ref-guide/modules/deployment-guide/pages/cluster-types.adoc rename to solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc diff --git a/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc b/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc index c29091ac2a6f..35b4183ba3ad 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc @@ -40,7 +40,7 @@ Any platform capable of HTTP can talk to Solr. Several xref:deployment-guide:client-apis.adoc[] are provided for use in common programming languages. In addition to providing a network accessible engine for Lucene based document retrieval, Solr provides the ability to scale beyond the limitations of a single machine. -Indexes can be sharded and replicated for performance and reliability, using either one of two xref:deployment-guide:cluster-types.adoc[]. +Indexes can be sharded and replicated for performance and reliability, using either one of two xref:cluster-types.adoc[]. The most scalable option uses https://zookeeper.apache.org/[Apache Zookeeper^TM^] to coordinate management activities across the cluster. The older approach requires no supporting infrastructure, however instances are managed directly by administrators. Solr scaling and high availability features are so effective that some of the largest and most famous internet sites use Solr. diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc index d23d3c12192f..d635a1d545bd 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc @@ -33,7 +33,7 @@ The left-side of the screen is a menu under the Solr logo that provides the navi The first set of links are for system-level information and configuration and provide access to xref:deployment-guide:configuring-logging.adoc#logging-screen[Logging Screen], xref:deployment-guide:collections-core-admin.adoc[], and xref:deployment-guide:jvm-settings.adoc#java-properties-screen[Java Properties Screen], among other things. At the end of this information is at least one pulldown listing Solr cores configured for this instance. -On xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud] nodes, an additional pulldown list shows all collections in this cluster. +On xref:cluster-types.adoc#solrcloud-mode[SolrCloud] nodes, an additional pulldown list shows all collections in this cluster. Clicking on a collection or core name shows secondary menus of information for the specified collection or core, such as a xref:indexing-guide:schema-browser-screen.adoc[], xref:configuration-guide:configuration-files.adoc#files-screen[Files Screen], xref:deployment-guide:plugins-stats-screen.adoc[], and a xref:query-guide:query-screen.adoc[] on indexed data. The left-side navigation appears on every screen, while the center changes to the detail of the option selected. @@ -98,7 +98,7 @@ image::solr-admin-ui/schema-designer.png[image] .Only Visible When Using SolrCloud [NOTE] ==== -The Schema Designer is only available on Solr instances running xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud]. +The Schema Designer is only available on Solr instances running xref:cluster-types.adoc#solrcloud-mode[SolrCloud]. ==== == Collection-Specific Tools @@ -108,7 +108,7 @@ In the left-hand navigation bar, you will see a pull-down menu titled Collection .Only Visible When Using SolrCloud [NOTE] ==== -The Collection Selector pull-down menu is only available on Solr instances running xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud]. +The Collection Selector pull-down menu is only available on Solr instances running xref:cluster-types.adoc#solrcloud-mode[SolrCloud]. User-managed clusters or single-node installations will not display this menu, instead the Collection specific UI pages described in this section will be available in the <>. ==== diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc index 9c5986f70d04..ae786a799a4e 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc @@ -184,7 +184,7 @@ In SolrCloud, a logical partition of a single <>. Every shard consists of at least one physical <>, but there may be multiple Replicas distributed across multiple <> for fault tolerance. See also <>. -[[solrclouddef]]xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud]:: +[[solrclouddef]]xref:cluster-types.adoc#solrcloud-mode[SolrCloud]:: Umbrella term for a suite of functionality in Solr which allows managing a <> of Solr <> for scalability, fault tolerance, and high availability. [[schema]]xref:indexing-guide:schema-elements.adoc[Solr Schema (managed-schema.xml or schema.xml)]:: diff --git a/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc b/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc index cc3b824fdce1..1c9192dabc82 100644 --- a/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc +++ b/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc @@ -383,7 +383,7 @@ This is because one result for "memory" did not have a price assigned to it. == Distributed Result Grouping Caveats -Grouping is supported for xref:deployment-guide:cluster-types.adoc#solrcloud-mode[distributed searches], with some caveats: +Grouping is supported for xref:getting-started:cluster-types.adoc#solrcloud-mode[distributed searches], with some caveats: * Currently `group.func` is not supported in any distributed searches * `group.ngroups` and `group.facet` require that all documents in each group must be co-located on the same shard in order for accurate counts to be returned. diff --git a/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc b/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc index fea8e94c5bfc..9b122bbfaf92 100644 --- a/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc +++ b/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc @@ -580,7 +580,7 @@ s|Required |Default: none |=== + Specifies the shards in your distributed indexing configuration. -For more information about distributed indexing, see xref:deployment-guide:cluster-types.adoc[]. +For more information about distributed indexing, see xref:getting-started:cluster-types.adoc[]. `shards.qt`:: + From c807443dd949c6934464fc55969ffae4948fe979 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sun, 29 Mar 2026 08:35:19 -0400 Subject: [PATCH 03/11] place holder changelog, will update if we make any big moves --- .../SOLR-18179-move-cluster-concepts-section.yml | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 changelog/unreleased/SOLR-18179-move-cluster-concepts-section.yml diff --git a/changelog/unreleased/SOLR-18179-move-cluster-concepts-section.yml b/changelog/unreleased/SOLR-18179-move-cluster-concepts-section.yml new file mode 100644 index 000000000000..103e0aabb961 --- /dev/null +++ b/changelog/unreleased/SOLR-18179-move-cluster-concepts-section.yml @@ -0,0 +1,7 @@ +title: Move cluster concepts into Getting Started in Ref Guide +type: changed +authors: + - name: Eric Pugh +links: + - name: SOLR-18179 + url: https://issues.apache.org/jira/browse/SOLR-18179 From 6c87297cac3a816d4fb04e670f882eb2c5fd5593 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sun, 29 Mar 2026 09:00:42 -0400 Subject: [PATCH 04/11] Bring in new concept of servers and nodes, rework definitions to try and be more explicit --- .../getting-started/pages/cluster-types.adoc | 119 ++++++++++++------ 1 file changed, 82 insertions(+), 37 deletions(-) diff --git a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc index 44a03d3e805a..ca72dec85614 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc @@ -16,7 +16,7 @@ // specific language governing permissions and limitations // under the License. -A Solr cluster is a group of servers (_nodes_) that each run Solr. +A Solr cluster is a group of servers that each run one or more Solr _nodes_. There are two general modes of operating a cluster of Solr nodes. One mode provides central coordination of the Solr nodes (<>), while the other allows you to operate a cluster without this central coordination (<>). @@ -29,38 +29,83 @@ First let's cover a few general concepts and then outline the differences betwee == Cluster Concepts +=== Servers and Nodes + +A _server_ is the hardware or virtual machine that hosts Solr software. +A _node_ is an instance of a running Solr process that services search and indexing requests. +Large servers may run multiple Solr nodes, though typically one node per server is most common. + === Shards -In both cluster modes, a single logical index can be split across nodes as _shards_. -Each shard contains a subset of overall index. +In both cluster modes, a logical collection of documents can be divided across nodes as _shards_. +Each shard represents a logical slice of the overall collection and contains a subset of the documents. -The number of shards dictates the theoretical limit to the number of documents that can be indexed to Solr. -It also determines the amount of parallelization possible for an individual search request. +The number of shards determines the theoretical limit to the number of documents that can be stored. +It also dictates the amount of parallelization possible for an individual search request. === Replicas -In order to provide some failover for each shard, each shard can be copied as a _replica_. -A replica has the same configuration as the shard and any other replicas for the same index. +A shard is a logical concept—a slice of your collection. +A _replica_ is the physical manifestation of that logical shard. +It is the actual running instance that holds and serves the documents belonging to that shard. + +A shard must have at least one replica to exist physically. +If you have one shard with one physical copy, you have one replica. +If you add redundancy by creating additional copies of that shard, you have multiple replicas—each is equally a replica, including the first one. -It's possible to have replicas without having created shards. -In this case, each replica would be a full copy of the entire index, instead of being only a copy of a part of the entire index. +IMPORTANT: There is no "original shard" separate from its replicas. +The replicas ARE how the shard exists. +This is why we say "a shard with 2 replicas" has 2 total physical copies, not an original plus 2 additional copies. -The number of replicas determines the level of fault tolerance the entire cluster has in the event of a node failure. +All replicas of the same shard contain the same subset of documents and share the same configuration. + +The number of replicas determines the level of fault tolerance the cluster has in the event of a node failure. It also dictates the theoretical limit on the number of concurrent search requests that can be processed under heavy load. -=== Leaders +=== Leaders and Followers -Once replicas have been created, a _leader_ must be identified. -The responsibility of the leader is to be a source-of-truth for each replica. -When updates are made to the index, they are first processed by the leader and then by each replica (the exact mechanism for how this happens varies). +Among the replicas for a given shard, one replica is designated as the _leader_. +The leader serves as the source-of-truth for its shard. +When document updates are made, they are first processed by the leader replica and then propagated to the other replicas (the exact mechanism varies by cluster mode). -The replicas which are not leaders are _followers_. +The replicas which are not leaders are called _followers_. === Cores -Each replica, whether it is a leader or a follower, is called a _core_. +In Solr's implementation, each replica is represented as a _core_. +The term "core" is primarily an internal implementation detail—when you create a replica, Solr creates a core to represent it. Multiple cores can be hosted on any one node. +NOTE: The term "core" can be confusing because in everyday English it implies something central and singular, but in Solr it actually refers to one of potentially many replicas distributed across the cluster. +In most contexts, thinking of "core" as synonymous with "replica" will help clarify discussions about Solr's architecture. + +=== Collections and Indexes + +A _collection_ is the complete logical set of searchable documents that share a schema and configuration. +In SolrCloud mode (described below), a collection encompasses all the shards and their replicas. + +An _index_ refers to the physical data structures written to disk by Apache Lucene. +Each core (replica) maintains exactly one Lucene index on disk, containing the actual inverted indexes, stored fields, and other data structures that enable search. + +This creates a clear hierarchy from logical concepts to physical storage: + +[source,text] +---- +Collection (logical grouping of all searchable documents) + └─> Shard 1 (logical partition) + │ └─> Replica 1 / Core 1 (physical instance) + │ │ └─> Lucene Index (disk structures) + │ └─> Replica 2 / Core 2 (physical instance) + │ └─> Lucene Index (disk structures) + └─> Shard 2 (logical partition) + └─> Replica 1 / Core 3 (physical instance) + │ └─> Lucene Index (disk structures) + └─> Replica 2 / Core 4 (physical instance) + └─> Lucene Index (disk structures) +---- + +In this example, a collection is divided into 2 shards, each shard has 2 replicas for redundancy, and each replica maintains its own Lucene index on disk. + == SolrCloud Mode SolrCloud mode (also called "SolrCloud") uses Apache ZooKeeper to provide the centralized cluster management that is its main feature. @@ -69,45 +114,45 @@ ZooKeeper tracks each node of the cluster and the state of each core on each nod In this mode, configuration files are stored in ZooKeeper and not on the file system of each node. When configuration changes are made, they must be uploaded to ZooKeeper, which in turn makes sure each node knows changes have been made. -SolrCloud introduces an additional concept, a _collection_. -A collection is the entire group of cores that represent an index: the logical shards and the physical replicas for each shard. -Collections all share the same configurations (schema, `solrconfig.xml`, etc.). -This is an additional centralization of the cluster management, as operations can be performed on the entire collection at one time. +SolrCloud manages collections as first-class entities. +A collection represents the entire group of shards and replicas that together provide access to a corpus of documents. +Collections share the same configurations (schema, `solrconfig.xml`, etc.). +This centralization of cluster management means that operations can be performed on the entire collection at one time. -When changes are made to configurations, a single command to reload the collection would automatically reload each individual core that is a member of the collection. +When changes are made to configurations, a single command to reload the collection will automatically reload each individual core (replica) that is a member of the collection. Sharding is handled automatically, simply by telling Solr during collection creation how many shards you'd like the collection to have. -Index updates are then generally balanced between each shard automatically. +Document updates are then generally balanced between each shard automatically. Some degree of control over what documents are stored in which shards is also available, if needed. ZooKeeper also handles load balancing and failover. Incoming requests, either to index documents or for user queries, can be sent to any node of the cluster and ZooKeeper will route the request to an appropriate replica of each shard. -In SolrCloud, the leader is flexible, with built-in mechanisms for automatic leader election in case of failure in the leader. -This means another core can become the leader, and from that point forward it is the source-of-truth for all replicas. +In SolrCloud, the leader is flexible, with built-in mechanisms for automatic leader election in case the current leader fails. +This means another replica can become the leader, and from that point forward it is the source-of-truth for all other replicas of that shard. As long as one replica of each relevant shard is available, a user query or indexing request can still be satisfied when running in SolrCloud mode. == User-Managed Mode -Solr's user-managed mode requires that cluster coordination activities that SolrCloud normally uses ZooKeeper for to be performed manually or with local scripts. +Solr's user-managed mode requires that cluster coordination activities that SolrCloud normally uses ZooKeeper for be performed manually or with local scripts. -If the corpus of documents is too large for a single-sharded index, the logic to create shards is entirely left to the user. +If the corpus of documents is too large for a single shard, the logic to create multiple shards is entirely left to the user. There are no automated or programmatic ways for Solr to create shards during indexing. -Routing documents to shards are handled manually, either with a simple hashing system or a simple round-robin list of shards that sends each document to a different shard. +Routing documents to shards is handled manually, either with a simple hashing system or a simple round-robin list of shards that sends each document to a different shard. Document updates must be sent to the right shard or duplicate documents could result. -In user-managed mode, the concept of leader and follower becomes critical. -Identifying which node will host the leader replica and which host(s) will be replicas dictate how each node is configured. -In this mode, all index updates are sent to the leader only. -Once the leader has completed indexing, the replica will request the index updates and copy them from the leader. +In user-managed mode, the distinction between leader and follower replicas becomes critical. +Identifying which node will host the leader replica and which host(s) will have follower replicas dictates how each node is configured. +In this mode, all document updates are sent to the leader replica only. +Once the leader has completed indexing, each follower replica will request the index updates and copy them from the leader. -Load balancing is achieved with an external tool or process, unless request traffic can be managed by the leader or one of its replicas alone. +Load balancing is achieved with an external tool or process, unless request traffic can be managed by the leader or one of its follower replicas alone. -If the leader goes down, there is no built-in failover mechanism. -A replica could continue to serve queries if the queries were specifically directed to it. -Changing a replica to serve as the leader would require changing `solrconfig.xml` configurations on all replicas and reloading each core. +If the leader replica goes down, there is no built-in failover mechanism. +A follower replica could continue to serve queries if the queries were specifically directed to it. +Promoting a follower replica to serve as the leader would require changing `solrconfig.xml` configurations on all replicas and reloading each core. -User-managed mode has no concept of a collection, so for all intents and purposes each Solr node is distinct from other nodes. -Only some configuration parameters keep each node from behaving as independent entities. +User-managed mode has no concept of a collection as a managed entity, so for all intents and purposes each Solr core is configured and managed independently. +Only configuration parameters keep related cores from behaving as completely independent entities. \ No newline at end of file From a7735c70c71f2ea9bc9725fe62f2b71b2e0ccec1 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sun, 29 Mar 2026 09:04:58 -0400 Subject: [PATCH 05/11] expand/update/add to glossary based on the solr cluster concepts --- .../getting-started/pages/solr-glossary.adoc | 53 ++++++++++++++----- 1 file changed, 40 insertions(+), 13 deletions(-) diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc index ae786a799a4e..a2c36dd8b5f1 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc @@ -50,22 +50,31 @@ A cluster may contain many collections. See also <>. [[collection]]Collection:: -In Solr, one or more <> grouped together in a single logical index using a single configuration and Schema. +The complete logical set of searchable documents that share a schema and configuration. + -In <> a collection may be divided up into multiple logical shards, which may in turn be distributed across many nodes. +In <>, a collection may be divided up into multiple logical <>, which may in turn be distributed across many <> for scalability and fault tolerance. +Each collection encompasses all the shards and their <>. + -Single-node installations and user-managed clusters use instead the concept of a <>. -"Collection" is most frequently used in the SolrCloud context, but as it represents a "logical index", the term may be used to refer to individual cores in a user-managed cluster as well. +Single-node installations and user-managed clusters do not manage collections as first-class entities; instead they work directly with individual <>. + [[defcommit]]Commit:: To make document changes permanent in the index. In the case of added documents, they would be searchable after a _commit_. [[core]]Core:: -An individual Solr instance (represents a logical index). -Multiple cores can run on a single node. +In Solr's implementation, a core is the physical instance that represents a <>. +When you create a replica, Solr creates a core to represent it. +Multiple cores can be hosted on a single <>. +Each core maintains exactly one Lucene <> on disk. ++ +NOTE: The term "core" can be confusing because in everyday English it implies something central and singular, but in Solr it actually refers to one of potentially many replicas distributed across the cluster. +In most contexts, thinking of "core" as synonymous with "replica" will clarify discussions about Solr's architecture. ++ See also <>. +[[corpus]]Corpus:: +The set of documents available for indexing, irrespective of whether or not they are currently indexed in Solr. + [[corereload]]Core reload:: To re-initialize a Solr core after changes to the schema file, `solrconfig.xml` or other configuration files. @@ -96,6 +105,11 @@ The arrangement of search results into categories based on indexed terms. [[field]]Field:: The content to be indexed/searched along with metadata defining how the content should be processed by Solr. +[[follower]]Follower:: +A <> that is not the <> for its <>. +Follower replicas receive index updates from the leader replica and serve queries. +See also <>. + [[SolrGlossary-I]] === I @@ -105,6 +119,10 @@ It is calculated as the number of total Documents divided by the number of Docum See http://en.wikipedia.org/wiki/Tf-idf and {lucene-javadocs}/core/org/apache/lucene/search/similarities/TFIDFSimilarity.html[the Lucene TFIDFSimilarity javadocs] for more info on TF-IDF based scoring and Lucene scoring in particular. See also <>. +[[index]]Index:: +The physical data structures written to disk by Apache Lucene. +Each <> (<>) maintains exactly one Lucene index on disk, containing the actual inverted indexes, stored fields, and other data structures that enable search. + [[invertedindex]]Inverted index:: A way of creating a searchable index that lists every word and the documents that contain those words, similar to an index in the back of a book which lists words and the pages on which they can be found. When performing keyword searches, this method is considered more efficient than the alternative, which would be to create a list of documents paired with every word used in each document. @@ -114,8 +132,8 @@ Since users search using terms they expect to be in documents, finding the term === L [[leader]]Leader:: -A single <> for each <> that takes charge of coordinating index updates (document additions or deletions) to other replicas in the same shard. -This is a transient responsibility assigned to a node via an election, if the current Shard Leader goes down, a new node will automatically be elected to take its place. +A single <> for each <> that serves as the source-of-truth and coordinates index updates (document additions or deletions) to the <> replicas in the same shard. +This is a transient responsibility assigned to a replica via an election; if the current leader goes down, another replica will automatically be elected to take its place. See also <>. [[SolrGlossary-M]] @@ -132,8 +150,8 @@ Metadata is information about a document, such as its title, author, or location A search that is entered as a user would normally speak or write, as in, "What is aspirin?" [[node]]Node:: -A JVM instance running Solr. -Also known as a Solr server. +An instance of a running Solr process that services search and indexing requests. +A node is a JVM instance running Solr on a <>. [[SolrGlossary-O]] === O @@ -163,7 +181,11 @@ The ability of a search engine to retrieve _all_ of the possible matches to a us The appropriateness of a document to the search conducted by the user. [[replica]]Replica:: -A <> that acts as a physical copy of a <> in a <> <>. +The physical manifestation of a logical <>. +A replica is the actual running instance (represented as a <>) that holds and serves the documents belonging to that shard. +A shard must have at least one replica to exist physically, and may have multiple replicas for redundancy and fault tolerance. +All replicas of the same shard contain the same subset of documents. +See also <>. [[replication]]xref:deployment-guide:user-managed-index-replication.adoc[Replication]:: @@ -179,9 +201,14 @@ Logic and configuration parameters that tell Solr how to handle incoming "reques Logic and configuration parameters used by request handlers to process query requests. Examples of search components include faceting, highlighting, and "more like this" functionality. +[[server]]Server:: +The hardware or virtual machine that hosts Solr software. +A server may run one or more Solr <>. + [[shard]]Shard:: -In SolrCloud, a logical partition of a single <>. -Every shard consists of at least one physical <>, but there may be multiple Replicas distributed across multiple <> for fault tolerance. +A logical slice of a <>. +Each shard represents a logical partition containing a subset of the collection's documents. +A shard exists physically as one or more <>, which may be distributed across multiple <> for fault tolerance and scalability. See also <>. [[solrclouddef]]xref:cluster-types.adoc#solrcloud-mode[SolrCloud]:: From 48e1f9d3bd61179dcc93d47ffde25b483b03185b Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sun, 29 Mar 2026 09:13:50 -0400 Subject: [PATCH 06/11] add in common terms standalone and user managed. --- .../getting-started/pages/solr-glossary.adoc | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc index a2c36dd8b5f1..2216438699af 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc @@ -25,7 +25,7 @@ Where possible, terms are linked to relevant parts of the Solr Reference Guide f *Jump to a letter:* -<> <> <> <> <> <> G H <> J K <> <> <> <> P <> <> <> <> U V <> X Y <> +<> <> <> <> <> <> G H <> J K <> <> <> <> P <> <> <> <> <> V <> X Y <> [[SolrGlossary-A]] @@ -44,10 +44,10 @@ These control the inclusion or exclusion of keywords in a query by using operato [[SolrGlossary-C]] === C -[[cluster]]Cluster:: +[[cluster]]xref:cluster-types.adoc[Cluster]:: In Solr, a cluster is a set of Solr nodes operating in coordination with each other via <>, and managed as a unit. A cluster may contain many collections. -See also <>. +See also xref:cluster-types.adoc[] and <>. [[collection]]Collection:: The complete logical set of searchable documents that share a schema and configuration. @@ -240,6 +240,12 @@ Synonyms generally are terms which are near to each other in meaning and may sub In a search engine implementation, synonyms may be abbreviations as well as words, or terms that are not consistently hyphenated. Examples of synonyms in this context would be "Inc." and "Incorporated" or "iPod" and "i-pod". +[[standalone]]Standalone:: +An informal term referring to Solr deployments that do not use <> mode. +This includes both single-node installations and <> clusters. +In source code and documentation, "Standalone" may refer to either <> or single-node deployments. +See also xref:cluster-types.adoc[] and <>. + [[SolrGlossary-T]] === T @@ -252,6 +258,16 @@ See also <>. An append-only log of write operations maintained by each <>. This log is required with SolrCloud implementations and is created and managed automatically by Solr. +[[SolrGlossary-U]] +=== U + +[[usermanaged]]xref:cluster-types.adoc#user-managed-mode[User-Managed Mode]:: +A mode of operating a Solr <> without the centralized coordination provided by <> in <> mode. +In user-managed mode, cluster coordination activities must be performed manually or with local scripts. +This includes shard creation, document routing, leader/follower configuration, and load balancing. +Also known as <> mode. +See also xref:cluster-types.adoc[]. + [[SolrGlossary-W]] === W From c5e83eedfde4de8d4ba79ff9350b6864cb2e76ff Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Mon, 13 Apr 2026 10:07:02 +0200 Subject: [PATCH 07/11] Use standalone everywhere we had single node. Single node isn't a user-managed or cloud thing. it's just, one node. --- .../configuration-guide/pages/config-api.adoc | 4 ++-- .../pages/config-sets.adoc | 4 ++-- .../pages/configuration-files.adoc | 6 +++--- .../pages/coreadmin-api.adoc | 2 +- .../configuration-guide/pages/libs.adoc | 2 +- .../pages/request-parameters-api.adoc | 2 +- .../pages/resource-loading.adoc | 2 +- .../pages/update-request-processors.adoc | 2 +- ...hentication-and-authorization-plugins.adoc | 8 ++++---- .../pages/backup-restore.adoc | 4 ++-- .../pages/basic-authentication-plugin.adoc | 2 +- .../deployment-guide/pages/cloud-screens.adoc | 2 +- .../pages/collections-core-admin.adoc | 2 +- .../deployment-guide/pages/enabling-ssl.adoc | 4 ++-- .../pages/solr-control-script-reference.adoc | 8 ++++---- .../pages/solrcloud-distributed-requests.adoc | 2 +- .../getting-started/pages/cluster-types.adoc | 4 ++-- .../getting-started/pages/solr-admin-ui.adoc | 2 +- .../getting-started/pages/solr-glossary.adoc | 6 +++--- ...transforming-and-indexing-custom-json.adoc | 20 +++++++++---------- .../query-guide/pages/other-parsers.adoc | 2 +- .../pages/major-changes-in-solr-7.adoc | 2 +- .../pages/major-changes-in-solr-8.adoc | 4 ++-- 23 files changed, 48 insertions(+), 48 deletions(-) diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc index 27bc358782bb..93e94a69045d 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc @@ -19,7 +19,7 @@ The Config API enables manipulating various aspects of your `solrconfig.xml` using REST-like API calls. -This feature is enabled by default and works similarly in both SolrCloud, user-managed clusters, and single-node installations. +This feature is enabled by default and works similarly in both SolrCloud and user-managed clusters installations. Many commonly edited properties (such as cache sizes and commit settings) and request handler definitions can be changed with this API. When using this API, `solrconfig.xml` is not changed. @@ -847,7 +847,7 @@ In order to be able to `update` and `delete` of the same item in `configoverlay. When using SolrCloud, every core watches the ZooKeeper directory for the configset being used with that core. If there are multiple cores in the same node using the same configset, only one ZooKeeper watch is used. -TIP:: In a user-managed cluster or single-node installation, there is no watch (because ZooKeeper is not running). +TIP:: In a user-managed cluster or standalone installation, there is no watch (because ZooKeeper is not running). For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`. Every write operation performed through the API would 'touch' the directory and all watchers are notified. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc index 2b79b985aba8..6f746d677baa 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc @@ -60,9 +60,9 @@ However, users can impose stricter or looser limits on their systems by providin - System Property: `-Dsolr.configset.forbidden.file.types` - Environment Variable: `SOLR_CONFIG_SET_FORBIDDEN_FILE_TYPES` -== Configsets in User-Managed Clusters or Single-Node Installations +== Configsets in User-Managed Clusters or Standalone Installations -If you are using Solr in a user-managed cluster or a single-node installation, configsets are managed on the filesystem. +If you are using Solr in a user-managed cluster or a standalone installation, configsets are managed on the filesystem. Each Solr core can have it's very own configset located beneath it in a `/conf/` dir. Here, it is not named or shared and the word _configset_ isn't found. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc index 44c0e0c502b0..34d76d0878ef 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc @@ -27,11 +27,11 @@ When you first install Solr, your home directory is `server/solr`. However, some examples may change this location (such as, if you run `bin/solr start -e cloud`, your home directory will be `example/cloud`). The home directory contains important configuration information and is the place where Solr will store its index. -The layout of the home directory will look a little different when you are running Solr in a user-managed cluster or single-node installation vs. when you are running a SolrCloud cluster. +The layout of the home directory will look a little different when you are running Solr in a user-managed cluster or standalone installation vs. when you are running a SolrCloud cluster. The crucial parts of the Solr home directory are shown in these examples: -.User-Managed Cluster or Single-Node +.User-Managed Cluster or Standalone [source,plain] ---- / @@ -97,7 +97,7 @@ The Files screen in the Admin UI lets you browse & view configuration files (suc image::configuration-files/files-screen.png[Files screen,height=400] If you are using xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper. -In user-managed clusters or single-node installations, all files in the `conf` directory are displayed. +In user-managed clusters or standalone installations, all files in the `conf` directory are displayed. The configuration files shown may or may not be used by the collection as use of the file depends on how they are referenced in either `solrconfig.xml` or your schema. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc index 7b6434d4a386..e71d36ff6dbe 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc @@ -20,7 +20,7 @@ The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster. -SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or single-node installations for core maintenance operations. +SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or standalone installations for core maintenance operations. The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose xref:requesthandlers-searchcomponents.adoc[request handler] that is used to manage Solr cores. Unlike other request handlers, the CoreAdminHandler is not attached to a single core. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc index 9ed94fbc84e8..1d46c49a38b9 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc @@ -34,7 +34,7 @@ There are several special places you can place Solr plugin `.jar` files, describ |Location |Visible To |Purpose |Additional Notes |`/lib/` | Everything (Node-level plugins, Core-level plugins, `bin/solr` tools) |Any plugins that administrators want to make available to all of Solrand its tooling, esp. when building a custom Solr package or Dockerfile. |N/A |`/lib/` for whatever reason (e.g. Solr installed on read-only file system) | Directory not present by default and must be created by administrators. See xref:deployment-guide:taking-solr-to-production.adoc[]. -|`/lib/` |Core-level plugins (for a specific core) |User-managed clusters or single-node installations that want to make a plugin visible to a specific Solr core, but not others. |Directory is not created by default, and must be created by administrators adjacent to `/conf/` +|`/lib/` |Core-level plugins (for a specific core) |User-managed clusters or standalone installations that want to make a plugin visible to a specific Solr core, but not others. |Directory is not created by default, and must be created by administrators adjacent to `/conf/` |`/server/solr-webapp/webapp/WEB-INF/lib/` |Everything (Node-level plugins, Core-level plugins, `bin/solr` tools) |Intended for Solr's own jars and dependencies |Should not be used for plugins, except in the case of a few rare plugin typs whose documentation explicitly calls out the need for placement here. |`/server/lib/ext` |Everything (Node-level plugins, Core-level plugins, `bin/solr` tools) |Intended to contain Jetty jars and other things needed by the Jetty servlet classpath. Not typically used for plugins |N/A |=== diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc index 11b5e5199f99..8e7870fa43ca 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc @@ -24,7 +24,7 @@ It is really another endpoint of the xref:config-api.adoc[] instead of a separat It does not replace or modify any sections of `solrconfig.xml`, but instead provides another approach to handling parameters used in requests. It behaves in the same way as the Config API, by storing parameters in another file that will be used at runtime. In this case, the parameters are stored in a file named `params.json`. -This file is kept in ZooKeeper when running SolrCloud or in the `conf` directory of a user-managed cluster or single-node installation. +This file is kept in ZooKeeper when running SolrCloud or in the `conf` directory of a user-managed cluster or standalone installation. The settings stored in `params.json` are used at query time to override settings defined in `solrconfig.xml` in some cases as described below. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc index 3825f362de08..e758bcd4309d 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc @@ -31,7 +31,7 @@ xref:managed-resources.adoc[] can be manipulated via APIs and do not need an exp xref:config-sets.adoc[] are the directories containing `solrconfig.xml`, the schema, and resources referenced by them. In SolrCloud they are stored in ZooKeeper. -In a user-managed cluster and a single-node installation they are stored on the file system. +In a user-managed cluster or standalone installation they are stored on the file system. In any mode, resources may be shared or may be dedicated to a configSet. Prefer to put resources here. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc index c2377045ce1d..674b0b49360e 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc @@ -132,7 +132,7 @@ Once the above has been specified in `solrconfig.xml`, we can be refer to them i == Update Processors in SolrCloud -In a user-managed cluster or a single-node installation, each update is run through all the update processors in a chain exactly once. +In a user-managed cluster or standalone installation, each update is run through all the update processors in a chain exactly once. In SolrCloud, however, the behavior of update request processors deserves special consideration. A critical SolrCloud functionality is the routing and distributing of requests. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/authentication-and-authorization-plugins.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/authentication-and-authorization-plugins.adoc index 5ff8199d17c0..8aa32a3f702c 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/authentication-and-authorization-plugins.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/authentication-and-authorization-plugins.adoc @@ -25,7 +25,7 @@ This allows for verifying a user's identity and for restricting access to resour Solr includes some plugins out of the box, and additional plugins can be developed using the authentication, authorization and audit logging frameworks described below. -All authentication, authorization and audit logging plugins can work with Solr whether it is running as a cluster or a single-node installation. +All authentication, authorization and audit logging plugins can work with Solr whether it is running as a cluster or standalone installation. All related configuration, including users and permission rules, are stored in a file named `security.json`. When using SolrCloud, this file must be located at the chroot of the ZooKeeper structure. If no chroot was given, then it must be at the root. When running Solr in standalone mode (without ZooKeeper), this file must be in the `$SOLR_HOME` directory. When manually running Solr from an extracted archive, this will most likely be `server/solr`. If the service installer script is used, its default location will be `/var/solr/data`, which can be changed with options given to the service installer. @@ -110,9 +110,9 @@ Once `security.json` has been uploaded to ZooKeeper, you should use the appropri You can edit it manually, but you must take care to remove any version data so it will be properly updated across all ZooKeeper nodes. The version data is found at the end of the `security.json` file, and will appear as the letter "v" followed by a number, such as `{"v":138}`. -=== In a User-Managed Cluster or Single-Node Installation +=== In a User-Managed Cluster or Standalone Installation -When running Solr in either a user-managed cluster or a single-node installation, you create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`). +When running Solr in either a user-managed cluster or standalone installation, you create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`). With a user-managed cluster, you will need to place `security.json` on each node of the cluster. @@ -145,7 +145,7 @@ Specify the authentication plugin in `/security.json` as in this example: All of the content in the `authentication` block of `security.json` will be passed as a map to the plugin during initialization. -An authentication plugin can also be used with a single-node Solr instance by passing in `-DauthenticationPlugin=` during startup. +An authentication plugin can also be used with standalone Solr instance by passing in `-DauthenticationPlugin=` during startup. Currently available authentication plugins are: diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/backup-restore.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/backup-restore.adoc index e6fa3e4d4039..12297153e9c2 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/backup-restore.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/backup-restore.adoc @@ -21,7 +21,7 @@ If you are worried about data loss, and of course you _should_ be, you need a wa Solr provides two approaches to backing up and restoring Solr cores or collections, depending on how you are running Solr. If you run a SolrCloud cluster, you will use the Collections API. -If you run a user-managed cluster or a single-node installation, you will use the replication handler. +If you run a user-managed cluster or a standalone installation, you will use the replication handler. [NOTE] ==== @@ -49,7 +49,7 @@ More information is available in the section xref:collection-management.adoc#lis * `action=DELETEBACKUP`: This command allows deletion of backup files or whole backups. More information is available in the section xref:collection-management.adoc#deletebackup[Delete Backups]. -== User-Managed Clusters and Single-Node Installations +== User-Managed Clusters and Standalone Installations Backups and restoration uses Solr's replication handler. Out of the box, Solr includes implicit support for replication so this API can be used. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/basic-authentication-plugin.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/basic-authentication-plugin.adoc index f84361e0e945..19536088939e 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/basic-authentication-plugin.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/basic-authentication-plugin.adoc @@ -61,7 +61,7 @@ There are several options defined in this example: <5> The parameter `"forwardCredentials":false` means we let Solr's PKI authentication handle distributed request instead of forwarding the Basic Auth header. Save your settings to a file called `security.json` locally. -If you are using Solr in single-node installation, you should put this file in `$SOLR_HOME`. +If you are using Solr in standalone installation, you should put this file in `$SOLR_HOME`. If `blockUnknown` is not defined in the `security.json` file, it will default to `true`. This has the effect of requiring authentication for HTTP access to Solr. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc index 70e1c12c08c4..81f2916f58f3 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc @@ -22,7 +22,7 @@ This screen provides status information about each collection & node in your clu [NOTE] ==== The "Cloud" menu option is only available when Solr is running xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud]. -User-managed clusters or single-node installations will not display this option. +User-managed clusters or standalone installations will not display this option. ==== Click on the "Cloud" option in the left-hand navigation, and a small sub-menu appears with options called "Nodes", "Tree", "ZK Status" and "Graph". diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/collections-core-admin.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/collections-core-admin.adoc index 1e66093c4c2d..e64c589a3cfc 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/collections-core-admin.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/collections-core-admin.adoc @@ -20,7 +20,7 @@ The Collections screen provides some basic functionality for managing your Colle [NOTE] ==== -If you are running a user-managed cluster or a single-node installation, you will not see a Collections option in the left nav menu of the Admin UI. +If you are running a user-managed cluster or a standalone installation, you will not see a Collections option in the left nav menu of the Admin UI. You will instead see a "Core Admin" screen that supports some comparable Core level information & manipulation via the xref:configuration-guide:coreadmin-api.adoc[] instead. ==== diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/enabling-ssl.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/enabling-ssl.adoc index dd8998b8e19a..536038df68c1 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/enabling-ssl.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/enabling-ssl.adoc @@ -134,7 +134,7 @@ When you start Solr, the `bin/solr` script includes these settings and will pass If you are using SolrCloud, you need to <> before starting Solr. -If you are running Solr in a user-managed cluster or single-node installation, you can skip to <>. +If you are running Solr in a user-managed cluster or standalone installation, you can skip to <>. === Configure ZooKeeper @@ -218,7 +218,7 @@ C:\> bin\solr.cmd --solr-home cloud\node1 -z server1:2181,server2:2181,server3:2 ==== ====== -=== Start User-Managed Cluster or Single-Node Solr +=== Start User-Managed Cluster or Standalone Solr Start Solr using the Solr control script as shown in the examples below. Customize the values for the parameters shown as needed and add any used in your system. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc index 25740a026258..d50c3bbdb2fe 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc @@ -361,18 +361,18 @@ When chosen, an interactive session will start to guide you through options to s + When using this example, you can choose from any of the available configsets found in `$SOLR_TIP/server/solr/configsets`. -* *techproducts*: This example starts a single-node Solr instance with a schema designed for the sample documents included in the `$SOLR_HOME/example/exampledocs` directory. +* *techproducts*: This example starts a standalone Solr instance with a schema designed for the sample documents included in the `$SOLR_HOME/example/exampledocs` directory. + The configset used can be found in `$SOLR_TIP/server/solr/configsets/sample_techproducts_configs`. + The data used can be found in `$SOLR_HOME/example/exampledocs/`. -* *schemaless*: This example starts a single-node Solr instance using a managed schema, as described in the section xref:configuration-guide:schema-factory.adoc[], and provides a very minimal pre-defined schema. +* *schemaless*: This example starts a standalone Solr instance using a managed schema, as described in the section xref:configuration-guide:schema-factory.adoc[], and provides a very minimal pre-defined schema. Solr will run in xref:indexing-guide:schemaless-mode.adoc[] with this configuration, where Solr will create fields in the schema on the fly and will guess field types used in incoming documents. + The configset used can be found in `$SOLR_TIP/server/solr/configsets/_default`. -* *films*: This example starts a single-node Solr instance using a managed schema, as described in the section xref:configuration-guide:schema-factory.adoc[], and then uses the Schema API to create some custom fields. +* *films*: This example starts a standalone Solr instance using a managed schema, as described in the section xref:configuration-guide:schema-factory.adoc[], and then uses the Schema API to create some custom fields. Solr will run in xref:indexing-guide:schemaless-mode.adoc[] with this configuration, where Solr will create fields in the schema on the fly and will guess field types used in incoming documents as well. It then loads some sample film data. + @@ -800,7 +800,7 @@ See also the section <>. === Delete Collection or Core -The `delete` command detects the mode that Solr is running in and then deletes the specified collection (SolrCloud) or core (user-managed or single-node) as appropriate. +The `delete` command detects the mode that Solr is running in and then deletes the specified collection (SolrCloud) or core (user-managed or standalone) as appropriate. `bin/solr delete [options]` diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/solrcloud-distributed-requests.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/solrcloud-distributed-requests.adoc index f7b25937d9cb..51733c2bb5bf 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/solrcloud-distributed-requests.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/solrcloud-distributed-requests.adoc @@ -301,7 +301,7 @@ http://localhost:8983/solr/collection1/select?q=*:*&_route_=user1!,user2! == Near Real Time (NRT) Use Cases Near Real Time (NRT) search means that documents are available for search soon after being indexed. -NRT searching is one of the main features of SolrCloud and is rarely attempted in user-managed clusters or single-node installations. +NRT searching is one of the main features of SolrCloud and is rarely attempted in user-managed clusters or standalone installations. Document durability and searchability are controlled by `commits`. The "Near" in "Near Real Time" is configurable to meet the needs of your application. diff --git a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc index ca72dec85614..1034c6d8f653 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc @@ -21,7 +21,7 @@ A Solr cluster is a group of servers that each run one or more Solr _nodes_. There are two general modes of operating a cluster of Solr nodes. One mode provides central coordination of the Solr nodes (<>), while the other allows you to operate a cluster without this central coordination (<>). -TIP: "User Managed" and "Single Node" are sometimes referred to as "Standalone", especially in source code. +TIP: "User Managed" is sometimes referred to as "Standalone" in source code. Both modes share general concepts, but ultimately differ in how those concepts are reflected in functionality and features. @@ -155,4 +155,4 @@ A follower replica could continue to serve queries if the queries were specifica Promoting a follower replica to serve as the leader would require changing `solrconfig.xml` configurations on all replicas and reloading each core. User-managed mode has no concept of a collection as a managed entity, so for all intents and purposes each Solr core is configured and managed independently. -Only configuration parameters keep related cores from behaving as completely independent entities. \ No newline at end of file +Only configuration parameters keep related cores from behaving as completely independent entities. diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc index d635a1d545bd..af5e795dd0d4 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc @@ -110,7 +110,7 @@ In the left-hand navigation bar, you will see a pull-down menu titled Collection ==== The Collection Selector pull-down menu is only available on Solr instances running xref:cluster-types.adoc#solrcloud-mode[SolrCloud]. -User-managed clusters or single-node installations will not display this menu, instead the Collection specific UI pages described in this section will be available in the <>. +User-managed clusters or standalone installations will not display this menu, instead the Collection specific UI pages described in this section will be available in the <>. ==== Clicking on the Collection Selector pull-down menu will show a list of the collections in your Solr cluster, with a search box that can be used to find a specific collection by name. diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc index 2216438699af..44257cde5b3e 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc @@ -55,7 +55,7 @@ The complete logical set of searchable documents that share a schema and configu In <>, a collection may be divided up into multiple logical <>, which may in turn be distributed across many <> for scalability and fault tolerance. Each collection encompasses all the shards and their <>. + -Single-node installations and user-managed clusters do not manage collections as first-class entities; instead they work directly with individual <>. +Standalone installations and user-managed clusters do not manage collections as first-class entities; instead they work directly with individual <>. + [[defcommit]]Commit:: To make document changes permanent in the index. @@ -242,8 +242,8 @@ Examples of synonyms in this context would be "Inc." and "Incorporated" or "iPod [[standalone]]Standalone:: An informal term referring to Solr deployments that do not use <> mode. -This includes both single-node installations and <> clusters. -In source code and documentation, "Standalone" may refer to either <> or single-node deployments. +This includes both standalone installations and <> clusters. +In source code and documentation, "Standalone" may refer to either <> or standalone deployments. See also xref:cluster-types.adoc[] and <>. [[SolrGlossary-T]] diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc index 2ad1e684cc97..3a4fc8c081a6 100644 --- a/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc +++ b/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc @@ -134,7 +134,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs'\ ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -261,7 +261,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs'\ ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -359,7 +359,7 @@ V1 API:: ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -416,7 +416,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs?useParams=my_para ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -513,7 +513,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs'\ ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -602,7 +602,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs'\ ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -690,7 +690,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs?split=/exams'\ ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -780,7 +780,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs' -H 'Content-type ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -818,7 +818,7 @@ curl 'http://localhost:8983/solr/techproducts/update/json/docs' -H 'Content-type ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] @@ -894,7 +894,7 @@ V1 API:: ---- ==== -V2 API User-Managed / Single-Node Solr:: +V2 API User-Managed / Standalone Solr:: + ==== [source,bash] diff --git a/solr/solr-ref-guide/modules/query-guide/pages/other-parsers.adoc b/solr/solr-ref-guide/modules/query-guide/pages/other-parsers.adoc index 2bd6dac3e7a1..f71489d9ad03 100644 --- a/solr/solr-ref-guide/modules/query-guide/pages/other-parsers.adoc +++ b/solr/solr-ref-guide/modules/query-guide/pages/other-parsers.adoc @@ -525,7 +525,7 @@ Boolean that indicates if Automatons should be compiled for each iteration of th === Graph Query Limitations -The `graph` parser only works in single-node Solr installations, or with SolrCloud and user-managed clusters that use exactly 1 shard. +The `graph` parser only works in standalone Solr installations, or with SolrCloud and user-managed clusters that use exactly 1 shard. === Graph Query Examples diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc index a9f776d6dc4e..e2d14fc5d317 100644 --- a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc +++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc @@ -82,7 +82,7 @@ Several changes have been made to configsets that ship with Solr; not only their The `sample_techproducts_configset` also remains, and is designed for use with the example documents shipped with Solr in the `example/exampledocs` directory. * When creating a new collection, if you do not specify a configset, the `_default` will be used. ** If you use SolrCloud, the `_default` configset will be automatically uploaded to ZooKeeper. -** If you run a user-managed cluster or a single-node installation, the instanceDir will be created automatically, using the `_default` configset as its basis. +** If you run a user-managed cluster or a standalone installation, the instanceDir will be created automatically, using the `_default` configset as its basis. === Schemaless Improvements diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc index 105c61dee709..61f78985e9ed 100644 --- a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc +++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc @@ -34,7 +34,7 @@ A thorough review of the list in <>, belo Solr's LeaderInRecovery (LIR) functionality <> in Solr 7.3. While these changes were back-compatible for all subsequent 7.x releases, that compatibility has been removed in 8.0. In order to upgrade to Solr 8.x, all nodes of your cluster must be running Solr 7.3 or higher. If an upgrade is attempted with nodes running versions earlier than 7.3, documents could be lost. -If you are not using Solr in SolrCloud mode (you run a user-managed cluster or a single-node installation), we expect you can upgrade to Solr 8 from any 7.x version without major issues. +If you are not using Solr in SolrCloud mode (you run a user-managed cluster or a standalone installation), we expect you can upgrade to Solr 8 from any 7.x version without major issues. === Rolling Upgrades with Solr 8 @@ -287,7 +287,7 @@ The login screen's purpose is cosmetic only - Admin UI-triggered Solr requests w + In SolrCloud mode this allow-list is automatically configured to contain all live nodes. -In a user-managed cluster or a single-node installation the allow-list is empty by default. +In a user-managed cluster or a standalone installation the allow-list is empty by default. Upgrading users who use the `shards` parameter in these installations can set this value by setting the `allowUrls` property in any `shardHandler` configurations in their `solrconfig.xml` file. + For more information, see the xref:deployment-guide:solrcloud-distributed-requests.adoc#configuring-the-shardhandlerfactory[Distributed Request] documentation. From ded64d9ee7d734085b1dcbd0fab7c2052f359c16 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Mon, 13 Apr 2026 16:55:40 +0200 Subject: [PATCH 08/11] Respond to detailed feedback on words. --- .../getting-started/pages/cluster-types.adoc | 81 ++++++++++--------- .../getting-started/pages/solr-glossary.adoc | 9 +-- 2 files changed, 49 insertions(+), 41 deletions(-) diff --git a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc index 1034c6d8f653..bdf74411647b 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc @@ -33,12 +33,12 @@ First let's cover a few general concepts and then outline the differences betwee A _server_ is the hardware or virtual machine that hosts Solr software. A _node_ is an instance of a running Solr process that services search and indexing requests. -Large servers may run multiple Solr nodes, though typically one node per server is most common. +In special cases where oversized pre-existing hardware must be utilized, a server might host two or more nodes. Note that such configurations are typically sub-optimal. === Shards -In both cluster modes, a logical collection of documents can be divided across nodes as _shards_. -Each shard represents a logical slice of the overall collection and contains a subset of the documents. +In both cluster modes, _shards_ are logical divisions of a collection of documents. +Shards slice a collection of documents into discrete non-overlapping subsets, and may be based on data values you specify or ranges of a hash on the document ID. The number of shards determines the theoretical limit to the number of documents that can be stored. It also dictates the amount of parallelization possible for an individual search request. @@ -47,7 +47,8 @@ It also dictates the amount of parallelization possible for an individual search A shard is a logical concept—a slice of your collection. A _replica_ is the physical manifestation of that logical shard. -It is the actual running instance that holds and serves the documents belonging to that shard. +It's comprised of a Lucene index on disk, and supporting infrastructure for managing the index. +A Solr node hosts each of its replicas that are solely responsible for operating that index including handling requests to it for indexing & searching. A shard must have at least one replica to exist physically. If you have one shard with one physical copy, you have one replica. @@ -57,7 +58,8 @@ IMPORTANT: There is no "original shard" separate from its replicas. The replicas ARE how the shard exists. This is why we say "a shard with 2 replicas" has 2 total physical copies, not an original plus 2 additional copies. -All replicas of the same shard contain the same subset of documents and share the same configuration. +All replicas of the same shard contain the same subset of documents. +All replicas of the same collection use the same xref:cluster-types.adoc#collections-and-indexes[configuration] and xref:configuration-guide:config-sets.adoc[configset]. The number of replicas determines the level of fault tolerance the cluster has in the event of a node failure. It also dictates the theoretical limit on the number of concurrent search requests that can be processed under heavy load. @@ -72,12 +74,16 @@ The replicas which are not leaders are called _followers_. === Cores +Historically the term "core" has mostly been used as a synonym for replica, but the term "core" can be confusing because in everyday English it implies something central and singular.Since there may be many replicas in Solr, and they are distributed across the cluster "Replica" is the preferred term. +Core is mostly only used for historical reasons in the code base and other places where renaming things would be disruptive. + In Solr's implementation, each replica is represented as a _core_. The term "core" is primarily an internal implementation detail—when you create a replica, Solr creates a core to represent it. Multiple cores can be hosted on any one node. -NOTE: The term "core" can be confusing because in everyday English it implies something central and singular, but in Solr it actually refers to one of potentially many replicas distributed across the cluster. -In most contexts, thinking of "core" as synonymous with "replica" will help clarify discussions about Solr's architecture. +NOTE: Historically the term "core" has mostly been used as a synonym for replica, but the term "core" can be confusing because in everyday English it implies something central and singular. +Since there may be many replicas in Solr, and they are distributed across the cluster "Replica" is the preferred term. +Core is mostly only used for historical reasons in the code base and other places where renaming things would be disruptive. === Collections and Indexes @@ -85,33 +91,35 @@ A _collection_ is the complete logical set of searchable documents that share a In SolrCloud mode (described below), a collection encompasses all the shards and their replicas. An _index_ refers to the physical data structures written to disk by Apache Lucene. -Each core (replica) maintains exactly one Lucene index on disk, containing the actual inverted indexes, stored fields, and other data structures that enable search. +Each replica maintains exactly one Lucene index on disk, containing the actual inverted indexes, stored fields, and other data structures that enable search. This creates a clear hierarchy from logical concepts to physical storage: [source,text] ---- -Collection (logical grouping of all searchable documents) - └─> Shard 1 (logical partition) - │ └─> Replica 1 / Core 1 (physical instance) - │ │ └─> Lucene Index (disk structures) - │ └─> Replica 2 / Core 2 (physical instance) - │ └─> Lucene Index (disk structures) - └─> Shard 2 (logical partition) - └─> Replica 1 / Core 3 (physical instance) - │ └─> Lucene Index (disk structures) - └─> Replica 2 / Core 4 (physical instance) - └─> Lucene Index (disk structures) +Cluster + └─> Collection (logical grouping of all searchable documents) + └─> Shard 1 (logical partition) + │ └─> Replica 1 / Core 1 (physical instance) + │ │ └─> Lucene Index (disk structures) + │ └─> Replica 2 / Core 2 (physical instance) + │ └─> Lucene Index (disk structures) + └─> Shard 2 (logical partition) + └─> Replica 1 / Core 3 (physical instance) + │ └─> Lucene Index (disk structures) + └─> Replica 2 / Core 4 (physical instance) + └─> Lucene Index (disk structures) ---- In this example, a collection is divided into 2 shards, each shard has 2 replicas for redundancy, and each replica maintains its own Lucene index on disk. -== SolrCloud Mode +== SolrCloud Clusters -SolrCloud mode (also called "SolrCloud") uses Apache ZooKeeper to provide the centralized cluster management that is its main feature. -ZooKeeper tracks each node of the cluster and the state of each core on each node. +A SolrCloud cluster (or simply "SolrCloud") uses Apache ZooKeeper to provide the centralized cluster management that is its main feature. +ZooKeeper holds a list of each live node in the cluster and the state of each collection (and thus shard and replica). -In this mode, configuration files are stored in ZooKeeper and not on the file system of each node. +In this mode, configuration files (a "Configset") are stored in ZooKeeper and not on the file system of each node. +Like most things in Solr, this choice is configurable. When configuration changes are made, they must be uploaded to ZooKeeper, which in turn makes sure each node knows changes have been made. SolrCloud manages collections as first-class entities. @@ -119,28 +127,32 @@ A collection represents the entire group of shards and replicas that together pr Collections share the same configurations (schema, `solrconfig.xml`, etc.). This centralization of cluster management means that operations can be performed on the entire collection at one time. -When changes are made to configurations, a single command to reload the collection will automatically reload each individual core (replica) that is a member of the collection. +When changes are made to configurations, a single command to "reload" the collection will automatically reload each individual core (replica) that is a member of the collection with the latest configuration. -Sharding is handled automatically, simply by telling Solr during collection creation how many shards you'd like the collection to have. -Document updates are then generally balanced between each shard automatically. +Collections may also be configured to provide automatic routing of documents to shards by hashing document ids and automatically assigning ranges of the possible hash values to shards. Some degree of control over what documents are stored in which shards is also available, if needed. -ZooKeeper also handles load balancing and failover. -Incoming requests, either to index documents or for user queries, can be sent to any node of the cluster and ZooKeeper will route the request to an appropriate replica of each shard. +Incoming requests, either to index documents or for user queries, can be sent to any node of the cluster and Solr will consult the state information in ZooKeeper in order to route the request to an appropriate replica of each shard. -In SolrCloud, the leader is flexible, with built-in mechanisms for automatic leader election in case the current leader fails. +In SolrCloud, the leader replica within a shard is flexible, with built-in mechanisms for automatic leader election in case the current leader fails. This means another replica can become the leader, and from that point forward it is the source-of-truth for all other replicas of that shard. As long as one replica of each relevant shard is available, a user query or indexing request can still be satisfied when running in SolrCloud mode. -== User-Managed Mode +== User-Managed Cluster + +User-managed mode has no concept of a collection as a managed entity, so for all intents and purposes each Solr core is configured and managed independently. +Only configuration parameters keep related cores from behaving as completely independent entities. -Solr's user-managed mode requires that cluster coordination activities that SolrCloud normally uses ZooKeeper for be performed manually or with local scripts. +Solr's user-managed cluster is nothing more than a set of Solr nodes in standalone mode, and thus know nothing of collections or shards, and Zookeeper is not used as a centralized storage for any configuration or real-time state. +Instead the "user" / operator (you) must do-it-yourself, both at client layers and probably some local scripts to automate whatever needs doing. +The Core Admin APIs of Solr with some special core-level APIs like replication become the fundamental building blocks for you to design / build a system to your own specifications. +This was what people did prior to SolrCloud, and some still do. If the corpus of documents is too large for a single shard, the logic to create multiple shards is entirely left to the user. -There are no automated or programmatic ways for Solr to create shards during indexing. +There are no automated or programmatic ways for Solr to create shards on demand. -Routing documents to shards is handled manually, either with a simple hashing system or a simple round-robin list of shards that sends each document to a different shard. +Routing documents to shards is handled manually, either with a hashing system (that you design and implement), assignment of documents to shards based on the value of a field (implicit routing), or a simple round-robin list of shards that sends each document to a different shard. Document updates must be sent to the right shard or duplicate documents could result. In user-managed mode, the distinction between leader and follower replicas becomes critical. @@ -153,6 +165,3 @@ Load balancing is achieved with an external tool or process, unless request traf If the leader replica goes down, there is no built-in failover mechanism. A follower replica could continue to serve queries if the queries were specifically directed to it. Promoting a follower replica to serve as the leader would require changing `solrconfig.xml` configurations on all replicas and reloading each core. - -User-managed mode has no concept of a collection as a managed entity, so for all intents and purposes each Solr core is configured and managed independently. -Only configuration parameters keep related cores from behaving as completely independent entities. diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc index 44257cde5b3e..c3b39e3eb5bc 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc @@ -67,8 +67,7 @@ When you create a replica, Solr creates a core to represent it. Multiple cores can be hosted on a single <>. Each core maintains exactly one Lucene <> on disk. + -NOTE: The term "core" can be confusing because in everyday English it implies something central and singular, but in Solr it actually refers to one of potentially many replicas distributed across the cluster. -In most contexts, thinking of "core" as synonymous with "replica" will clarify discussions about Solr's architecture. +NOTE: Historically the term "core" has mostly been used as a synonym for replica, but the term "core" can be confusing because in everyday English it implies something central and singular. Since there may be many replicas in Solr, and they are distributed across the cluster "Replica" is the preferred term. Core is mostly only used for historical reasons in the code base and other places where renaming things would be disruptive. + See also <>. @@ -182,7 +181,7 @@ The appropriateness of a document to the search conducted by the user. [[replica]]Replica:: The physical manifestation of a logical <>. -A replica is the actual running instance (represented as a <>) that holds and serves the documents belonging to that shard. +A replica is the actual running instance that holds and serves the documents belonging to that shard. A shard must have at least one replica to exist physically, and may have multiple replicas for redundancy and fault tolerance. All replicas of the same shard contain the same subset of documents. See also <>. @@ -207,7 +206,7 @@ A server may run one or more Solr <>. [[shard]]Shard:: A logical slice of a <>. -Each shard represents a logical partition containing a subset of the collection's documents. +Each shard represents a partition containing a subset of the collection's documents. A shard exists physically as one or more <>, which may be distributed across multiple <> for fault tolerance and scalability. See also <>. @@ -241,7 +240,7 @@ In a search engine implementation, synonyms may be abbreviations as well as word Examples of synonyms in this context would be "Inc." and "Incorporated" or "iPod" and "i-pod". [[standalone]]Standalone:: -An informal term referring to Solr deployments that do not use <> mode. +An informal term referring to Solr nodes that do not utilize Apache Zookeeper and thus do not provide the centralized configuration management that is available in <> mode. This includes both standalone installations and <> clusters. In source code and documentation, "Standalone" may refer to either <> or standalone deployments. See also xref:cluster-types.adoc[] and <>. From bc59045fdf50d10c173b57c866b616697e8f96de Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Mon, 13 Apr 2026 16:55:51 +0200 Subject: [PATCH 09/11] Fix up antora warnings --- .../modules/query-guide/pages/dense-vector-search.adoc | 2 +- .../modules/query-guide/pages/searching-nested-documents.adoc | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc b/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc index cbe3d5781906..639a8f14c808 100644 --- a/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc +++ b/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc @@ -242,7 +242,7 @@ client.add(Arrays.asList(d1, d2)); Here's how a `DenseVectorField` should be indexed when multi-valued: -[tabs#densevectorfield-index] +[tabs#densevectorfield-index-multivalued] ====== JSON:: + diff --git a/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc b/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc index 83b2e35f54cd..9064dfa521a6 100644 --- a/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc +++ b/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc @@ -334,5 +334,3 @@ children.q={!knn f=vector topK=3 parents.preFilter=$someParents childrenOf=$allP This query is a knn vector search on the children documents. Specifically it retrieves the top k=3 children documents, filtered by 'someParent' metadata. This query ensures only one child per parent is retrieved. - ----- From 17e21d12382351b8f2ac7946c1855d4d72853aba Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Mon, 13 Apr 2026 17:29:31 +0200 Subject: [PATCH 10/11] Small text fixes. --- .../modules/getting-started/pages/cluster-types.adoc | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc index bdf74411647b..fd1bd3608bd6 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc @@ -19,7 +19,7 @@ A Solr cluster is a group of servers that each run one or more Solr _nodes_. There are two general modes of operating a cluster of Solr nodes. -One mode provides central coordination of the Solr nodes (<>), while the other allows you to operate a cluster without this central coordination (<>). +One mode provides central coordination of the Solr nodes (<>), while the other allows you to operate a cluster without this central coordination (<>). TIP: "User Managed" is sometimes referred to as "Standalone" in source code. @@ -74,9 +74,6 @@ The replicas which are not leaders are called _followers_. === Cores -Historically the term "core" has mostly been used as a synonym for replica, but the term "core" can be confusing because in everyday English it implies something central and singular.Since there may be many replicas in Solr, and they are distributed across the cluster "Replica" is the preferred term. -Core is mostly only used for historical reasons in the code base and other places where renaming things would be disruptive. - In Solr's implementation, each replica is represented as a _core_. The term "core" is primarily an internal implementation detail—when you create a replica, Solr creates a core to represent it. Multiple cores can be hosted on any one node. From 097648a60d2d73c1e8c6c694d78bf2bb666fc932 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Mon, 20 Apr 2026 11:19:05 -0400 Subject: [PATCH 11/11] Fix up cross links --- .../configuration-guide/pages/configuration-files.adoc | 2 +- .../modules/configuration-guide/pages/coreadmin-api.adoc | 2 +- .../modules/deployment-guide/pages/cloud-screens.adoc | 2 +- .../modules/deployment-guide/pages/installing-solr.adoc | 4 ++-- .../pages/user-managed-distributed-search.adoc | 2 +- .../pages/user-managed-index-replication.adoc | 2 +- .../modules/getting-started/pages/solr-admin-ui.adoc | 6 +++--- .../modules/getting-started/pages/solr-glossary.adoc | 4 ++-- .../modules/query-guide/pages/result-grouping.adoc | 2 +- 9 files changed, 13 insertions(+), 13 deletions(-) diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc index 34d76d0878ef..43f47a2eb19c 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc @@ -96,7 +96,7 @@ The Files screen in the Admin UI lets you browse & view configuration files (suc .The Files Screen image::configuration-files/files-screen.png[Files screen,height=400] -If you are using xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper. +If you are using xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper. In user-managed clusters or standalone installations, all files in the `conf` directory are displayed. The configuration files shown may or may not be used by the collection as use of the file depends on how they are referenced in either `solrconfig.xml` or your schema. diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc index e71d36ff6dbe..6cd1d566ac28 100644 --- a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc +++ b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc @@ -18,7 +18,7 @@ // specific language governing permissions and limitations // under the License. -The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster. +The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud] cluster. SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or standalone installations for core maintenance operations. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc index 81f2916f58f3..a17c7ee8b3ae 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc @@ -21,7 +21,7 @@ This screen provides status information about each collection & node in your clu .Only Visible When using SolrCloud [NOTE] ==== -The "Cloud" menu option is only available when Solr is running xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud]. +The "Cloud" menu option is only available when Solr is running xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud]. User-managed clusters or standalone installations will not display this option. ==== diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc index 4fc9b6cea35d..8743ee2298af 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc @@ -59,7 +59,7 @@ A very good blog post that discusses the issues to consider is https://lucidwork One thing to note when planning your installation is that a hard limit exists in Lucene for the number of documents in a single index: approximately 2.14 billion documents (2,147,483,647 to be exact). In practice, it is highly unlikely that such a large number of documents would fit and perform well in a single index, and you will likely need to distribute your index across a cluster before you ever approach this number. -If you know you will exceed this number of documents in total before you've even started indexing, it's best to plan your installation with xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] as part of your design from the start. +If you know you will exceed this number of documents in total before you've even started indexing, it's best to plan your installation with xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud] as part of your design from the start. == Package Installation @@ -197,7 +197,7 @@ Currently, the available examples you can run are: techproducts, schemaless, and See the section xref:solr-control-script-reference.adoc#running-with-example-configurations[Running with Example Configurations] for details on each example. .Going deeper with SolrCloud -NOTE: Running the `cloud` example demonstrates running multiple nodes of Solr using xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] mode. +NOTE: Running the `cloud` example demonstrates running multiple nodes of Solr using xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud] mode. For more information on starting Solr in SolrCloud mode, see the section xref:getting-started:tutorial-solrcloud.adoc[]. === Check if Solr is Running diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc index cb59d1349081..bae54f784fa7 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc @@ -18,7 +18,7 @@ When using traditional index sharding, you will need to consider how to query your documents. -It is highly recommended that you use xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] when needing to scale up or scale out. +It is highly recommended that you use xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud] when needing to scale up or scale out. The setup described below is legacy and was used prior to the existence of SolrCloud. SolrCloud provides for a truly distributed set of features with support for things like automatic routing, leader election, optimistic concurrency and other sanity checks that are expected out of a distributed system. diff --git a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc index 2b8a453694a5..9747334f14a9 100644 --- a/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc +++ b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc @@ -43,7 +43,7 @@ Configuring replication is therefore similar to any normal request handler. .Replication In SolrCloud [NOTE] ==== -Although there is no explicit concept of leader or follower nodes in a xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud cluster], the `ReplicationHandler` discussed on this page is still used by SolrCloud as needed to support "shard recovery" – but this is done in a peer to peer manner. +Although there is no explicit concept of leader or follower nodes in a xref:getting-started:cluster-types.adoc#solrcloud-clusters[SolrCloud cluster], the `ReplicationHandler` discussed on this page is still used by SolrCloud as needed to support "shard recovery" – but this is done in a peer to peer manner. When using SolrCloud, the `ReplicationHandler` must be available via the `/replication` path. Solr does this implicitly unless overridden explicitly in your `solrconfig.xml`. diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc index af5e795dd0d4..715047bec86f 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-admin-ui.adoc @@ -33,7 +33,7 @@ The left-side of the screen is a menu under the Solr logo that provides the navi The first set of links are for system-level information and configuration and provide access to xref:deployment-guide:configuring-logging.adoc#logging-screen[Logging Screen], xref:deployment-guide:collections-core-admin.adoc[], and xref:deployment-guide:jvm-settings.adoc#java-properties-screen[Java Properties Screen], among other things. At the end of this information is at least one pulldown listing Solr cores configured for this instance. -On xref:cluster-types.adoc#solrcloud-mode[SolrCloud] nodes, an additional pulldown list shows all collections in this cluster. +On xref:cluster-types.adoc#solrcloud-clusters[SolrCloud] nodes, an additional pulldown list shows all collections in this cluster. Clicking on a collection or core name shows secondary menus of information for the specified collection or core, such as a xref:indexing-guide:schema-browser-screen.adoc[], xref:configuration-guide:configuration-files.adoc#files-screen[Files Screen], xref:deployment-guide:plugins-stats-screen.adoc[], and a xref:query-guide:query-screen.adoc[] on indexed data. The left-side navigation appears on every screen, while the center changes to the detail of the option selected. @@ -98,7 +98,7 @@ image::solr-admin-ui/schema-designer.png[image] .Only Visible When Using SolrCloud [NOTE] ==== -The Schema Designer is only available on Solr instances running xref:cluster-types.adoc#solrcloud-mode[SolrCloud]. +The Schema Designer is only available on Solr instances running xref:cluster-types.adoc#solrcloud-clusters[SolrCloud]. ==== == Collection-Specific Tools @@ -108,7 +108,7 @@ In the left-hand navigation bar, you will see a pull-down menu titled Collection .Only Visible When Using SolrCloud [NOTE] ==== -The Collection Selector pull-down menu is only available on Solr instances running xref:cluster-types.adoc#solrcloud-mode[SolrCloud]. +The Collection Selector pull-down menu is only available on Solr instances running xref:cluster-types.adoc#solrcloud-clusters[SolrCloud]. User-managed clusters or standalone installations will not display this menu, instead the Collection specific UI pages described in this section will be available in the <>. ==== diff --git a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc index c3b39e3eb5bc..7f7649ed8e30 100644 --- a/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc +++ b/solr/solr-ref-guide/modules/getting-started/pages/solr-glossary.adoc @@ -210,7 +210,7 @@ Each shard represents a partition containing a subset of the collection's docume A shard exists physically as one or more <>, which may be distributed across multiple <> for fault tolerance and scalability. See also <>. -[[solrclouddef]]xref:cluster-types.adoc#solrcloud-mode[SolrCloud]:: +[[solrclouddef]]xref:cluster-types.adoc#solrcloud-clusters[SolrCloud]:: Umbrella term for a suite of functionality in Solr which allows managing a <> of Solr <> for scalability, fault tolerance, and high availability. [[schema]]xref:indexing-guide:schema-elements.adoc[Solr Schema (managed-schema.xml or schema.xml)]:: @@ -260,7 +260,7 @@ This log is required with SolrCloud implementations and is created and managed a [[SolrGlossary-U]] === U -[[usermanaged]]xref:cluster-types.adoc#user-managed-mode[User-Managed Mode]:: +[[usermanaged]]xref:cluster-types.adoc#user-managed-cluster[User-Managed Cluster]:: A mode of operating a Solr <> without the centralized coordination provided by <> in <> mode. In user-managed mode, cluster coordination activities must be performed manually or with local scripts. This includes shard creation, document routing, leader/follower configuration, and load balancing. diff --git a/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc b/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc index 1c9192dabc82..ce539c07f8b9 100644 --- a/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc +++ b/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc @@ -383,7 +383,7 @@ This is because one result for "memory" did not have a price assigned to it. == Distributed Result Grouping Caveats -Grouping is supported for xref:getting-started:cluster-types.adoc#solrcloud-mode[distributed searches], with some caveats: +Grouping is supported for xref:getting-started:cluster-types.adoc#solrcloud-clusters[distributed searches], with some caveats: * Currently `group.func` is not supported in any distributed searches * `group.ngroups` and `group.facet` require that all documents in each group must be co-located on the same shard in order for accurate counts to be returned.