This is an automated email from the ASF dual-hosted git repository.
epugh pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/solr.git
The following commit(s) were added to refs/heads/main by this push:
new 5a658d7eca7 SOLR-18179: Better highlight and expand upon our Cluster
concepts in the Ref Guide (#4246)
5a658d7eca7 is described below
commit 5a658d7eca725422fa45bcfaf6fd1ca486db193a
Author: Eric Pugh <[email protected]>
AuthorDate: Fri Apr 24 08:14:07 2026 -0400
SOLR-18179: Better highlight and expand upon our Cluster concepts in the
Ref Guide (#4246)
Co-authored-by: copilot-swe-agent[bot]
<[email protected]>
Co-authored-by: epugh <[email protected]>
---
.../SOLR-18179-move-cluster-concepts-section.yml | 7 +
.../configuration-guide/pages/config-api.adoc | 4 +-
.../configuration-guide/pages/config-sets.adoc | 4 +-
.../pages/configuration-files.adoc | 8 +-
.../configuration-guide/pages/coreadmin-api.adoc | 4 +-
.../modules/configuration-guide/pages/libs.adoc | 2 +-
.../pages/request-parameters-api.adoc | 2 +-
.../pages/resource-loading.adoc | 2 +-
.../pages/update-request-processors.adoc | 2 +-
.../modules/deployment-guide/deployment-nav.adoc | 1 -
.../authentication-and-authorization-plugins.adoc | 8 +-
.../deployment-guide/pages/backup-restore.adoc | 4 +-
.../pages/basic-authentication-plugin.adoc | 2 +-
.../deployment-guide/pages/cloud-screens.adoc | 4 +-
.../deployment-guide/pages/cluster-types.adoc | 113 --------------
.../pages/collections-core-admin.adoc | 2 +-
.../deployment-guide/pages/enabling-ssl.adoc | 4 +-
.../deployment-guide/pages/installing-solr.adoc | 4 +-
.../pages/solr-control-script-reference.adoc | 10 +-
.../pages/solrcloud-distributed-requests.adoc | 2 +-
.../pages/user-managed-distributed-search.adoc | 2 +-
.../pages/user-managed-index-replication.adoc | 2 +-
.../getting-started/getting-started-nav.adoc | 1 +
.../getting-started/pages/cluster-types.adoc | 164 +++++++++++++++++++++
.../getting-started/pages/introduction.adoc | 2 +-
.../getting-started/pages/solr-admin-ui.adoc | 8 +-
.../getting-started/pages/solr-glossary.adoc | 76 +++++++---
.../transforming-and-indexing-custom-json.adoc | 20 +--
.../query-guide/pages/dense-vector-search.adoc | 2 +-
.../modules/query-guide/pages/other-parsers.adoc | 2 +-
.../modules/query-guide/pages/result-grouping.adoc | 2 +-
.../pages/searching-nested-documents.adoc | 2 -
.../modules/query-guide/pages/spell-checking.adoc | 2 +-
.../pages/major-changes-in-solr-7.adoc | 2 +-
.../pages/major-changes-in-solr-8.adoc | 4 +-
35 files changed, 289 insertions(+), 191 deletions(-)
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 00000000000..103e0aabb96
--- /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
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 27bc358782b..93e94a69045 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 5e22aa3200a..2b7433a6abb 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
`<instance_dir>/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 63b5eb3f8f5..43f47a2eb19 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]
----
<solr-home-directory>/
@@ -96,8 +96,8 @@ 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.
-In user-managed clusters or single-node installations, all files in the `conf`
directory are displayed.
+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 261caa7370f..6cd1d566ac2 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,9 +18,9 @@
// 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-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 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 9ed94fbc84e..1d46c49a38b 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
|`<solr_install>/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
|`<solr_home/lib/` | Node-level plugins, Core-level plugins |Useful when
plugins should be made available to all of Solr, but cannot be put in
`<solr_install>/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[].
-|`<core_instance>/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
`<core_instance>/conf/`
+|`<core_instance>/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
`<core_instance>/conf/`
|`<solr_install>/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.
|`<solr_install>/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 11b5e5199f9..8e7870fa43c 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 3825f362de0..e758bcd4309 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 c2377045ce1..674b0b49360 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/deployment-nav.adoc
b/solr/solr-ref-guide/modules/deployment-guide/deployment-nav.adoc
index 55301601e3e..04dfeb76643 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/authentication-and-authorization-plugins.adoc
b/solr/solr-ref-guide/modules/deployment-guide/pages/authentication-and-authorization-plugins.adoc
index 5ff8199d17c..8aa32a3f702 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=<plugin class name>` during startup.
+An authentication plugin can also be used with standalone Solr instance by
passing in `-DauthenticationPlugin=<plugin class name>` 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 e6fa3e4d403..12297153e9c 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 f84361e0e94..19536088939 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 a4f23232d45..a17c7ee8b3a 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,8 +21,8 @@ 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].
-User-managed clusters or single-node installations will not display this
option.
+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.
====
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/cluster-types.adoc
b/solr/solr-ref-guide/modules/deployment-guide/pages/cluster-types.adoc
deleted file mode 100644
index 44a03d3e805..00000000000
--- a/solr/solr-ref-guide/modules/deployment-guide/pages/cluster-types.adoc
+++ /dev/null
@@ -1,113 +0,0 @@
-= Solr Cluster Types
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements. See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership. The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License. You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied. See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-A Solr cluster is a group of servers (_nodes_) that each run Solr.
-
-There are two general modes of operating a cluster of Solr nodes.
-One mode provides central coordination of the Solr nodes (<<SolrCloud Mode>>),
while the other allows you to operate a cluster without this central
coordination (<<User-Managed Mode>>).
-
-TIP: "User Managed" and "Single Node" are sometimes referred to as
"Standalone", especially in source code.
-
-Both modes share general concepts, but ultimately differ in how those concepts
are reflected in functionality and features.
-
-First let's cover a few general concepts and then outline the differences
between the two modes.
-
-== Cluster Concepts
-
-=== Shards
-
-In both cluster modes, a single logical index can be split across nodes as
_shards_.
-Each shard contains a subset of overall index.
-
-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.
-
-=== 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.
-
-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.
-
-The number of replicas determines the level of fault tolerance the entire
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
-
-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).
-
-The replicas which are not leaders are _followers_.
-
-=== Cores
-
-Each replica, whether it is a leader or a follower, is called a _core_.
-Multiple cores can be hosted on any one node.
-
-== SolrCloud Mode
-
-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.
-
-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.
-
-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.
-
-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.
-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.
-
-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.
-
-If the corpus of documents is too large for a single-sharded index, the logic
to create 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.
-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.
-
-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.
-
-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.
-
-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.
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 1e66093c4c2..e64c589a3cf 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 dd8998b8e19..536038df68c 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 <<Configure ZooKeeper>> before
starting Solr.
-If you are running Solr in a user-managed cluster or single-node installation,
you can skip to <<Start User-Managed Cluster or Single-Node Solr>>.
+If you are running Solr in a user-managed cluster or standalone installation,
you can skip to <<Start User-Managed Cluster or Standalone Solr>>.
=== 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/installing-solr.adoc
b/solr/solr-ref-guide/modules/deployment-guide/pages/installing-solr.adoc
index 15cc9898a02..8743ee2298a 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-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: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/solr-control-script-reference.adoc
b/solr/solr-ref-guide/modules/deployment-guide/pages/solr-control-script-reference.adoc
index a7348059cc2..d50c3bbdb2f 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
@@ -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 <<Set or Unset Configuration
Properties>>.
=== 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 f7b25937d9c..51733c2bb5b 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/deployment-guide/pages/user-managed-distributed-search.adoc
b/solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-distributed-search.adoc
index 460039639ca..bae54f784fa 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-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 ff3e4421fbb..4191e3a27a6 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-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/getting-started-nav.adoc
b/solr/solr-ref-guide/modules/getting-started/getting-started-nav.adoc
index 095f679f93b..562ba636558 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/getting-started/pages/cluster-types.adoc
b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc
new file mode 100644
index 00000000000..fd1bd3608bd
--- /dev/null
+++ b/solr/solr-ref-guide/modules/getting-started/pages/cluster-types.adoc
@@ -0,0 +1,164 @@
+= Solr Cluster Types
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+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 (<<SolrCloud
Clusters>>), while the other allows you to operate a cluster without this
central coordination (<<User-Managed Cluster>>).
+
+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.
+
+First let's cover a few general concepts and then outline the differences
between the two modes.
+
+== 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.
+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, _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.
+
+=== Replicas
+
+A shard is a logical concept—a slice of your collection.
+A _replica_ is the physical manifestation of that logical 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.
+If you add redundancy by creating additional copies of that shard, you have
multiple replicas—each is equally a replica, including the first one.
+
+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.
+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.
+
+=== Leaders and Followers
+
+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 called _followers_.
+
+=== Cores
+
+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: 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
+
+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 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]
+----
+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 Clusters
+
+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 (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.
+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 will automatically reload each individual core (replica) that is a
member of the collection with the latest configuration.
+
+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.
+
+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 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 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 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 on
demand.
+
+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.
+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 follower replicas alone.
+
+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.
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 c29091ac2a6..35b4183ba3a 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 d23d3c12192..715047bec86 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-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:deployment-guide: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,9 +108,9 @@ 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-clusters[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 <<Core-Specific Tools,Core Selector pull-down menu>>.
+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 <<Core-Specific Tools,Core Selector pull-down menu>>.
====
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 9c5986f70d0..7f7649ed8e3 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:*
-<<SolrGlossary-A,A>> <<SolrGlossary-B,B>> <<SolrGlossary-C,C>>
<<SolrGlossary-D,D>> <<SolrGlossary-E,E>> <<SolrGlossary-F,F>> G H
<<SolrGlossary-I,I>> J K <<SolrGlossary-L,L>> <<SolrGlossary-M,M>>
<<SolrGlossary-N,N>> <<SolrGlossary-O,O>> P <<SolrGlossary-Q,Q>>
<<SolrGlossary-R,R>> <<SolrGlossary-S,S>> <<SolrGlossary-T,T>> U V
<<SolrGlossary-W,W>> X Y <<SolrGlossary-Z,Z>>
+<<SolrGlossary-A,A>> <<SolrGlossary-B,B>> <<SolrGlossary-C,C>>
<<SolrGlossary-D,D>> <<SolrGlossary-E,E>> <<SolrGlossary-F,F>> G H
<<SolrGlossary-I,I>> J K <<SolrGlossary-L,L>> <<SolrGlossary-M,M>>
<<SolrGlossary-N,N>> <<SolrGlossary-O,O>> P <<SolrGlossary-Q,Q>>
<<SolrGlossary-R,R>> <<SolrGlossary-S,S>> <<SolrGlossary-T,T>>
<<SolrGlossary-U,U>> V <<SolrGlossary-W,W>> X Y <<SolrGlossary-Z,Z>>
[[SolrGlossary-A]]
@@ -44,28 +44,36 @@ 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 <<zookeeper,ZooKeeper>>, and managed as a unit.
A cluster may contain many collections.
-See also <<solrclouddef,SolrCloud>>.
+See also xref:cluster-types.adoc[] and <<solrclouddef,SolrCloud>>.
[[collection]]Collection::
-In Solr, one or more <<document,Documents>> 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 <<solrclouddef,SolrCloud>> a collection may be divided up into multiple
logical shards, which may in turn be distributed across many nodes.
+In <<solrclouddef,SolrCloud>>, a collection may be divided up into multiple
logical <<shard,shards>>, which may in turn be distributed across many
<<node,nodes>> for scalability and fault tolerance.
+Each collection encompasses all the shards and their <<replica,replicas>>.
+
-Single-node installations and user-managed clusters use instead the concept of
a <<core,Core>>.
-"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.
+Standalone installations and user-managed clusters do not manage collections
as first-class entities; instead they work directly with individual
<<core,cores>>.
+
[[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
<<replica,Replica>>.
+When you create a replica, Solr creates a core to represent it.
+Multiple cores can be hosted on a single <<node,Node>>.
+Each core maintains exactly one Lucene <<index,Index>> on disk.
++
+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 <<solrclouddef,SolrCloud>>.
+[[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 +104,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 <<replica,Replica>> that is not the <<leader,Leader>> for its
<<shard,Shard>>.
+Follower replicas receive index updates from the leader replica and serve
queries.
+See also <<solrclouddef,SolrCloud>>.
+
[[SolrGlossary-I]]
=== I
@@ -105,6 +118,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 <<termfrequency,Term frequency>>.
+[[index]]Index::
+The physical data structures written to disk by Apache Lucene.
+Each <<core,Core>> (<<replica,Replica>>) 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 +131,8 @@ Since users search using terms they expect to be in
documents, finding the term
=== L
[[leader]]Leader::
-A single <<replica,Replica>> for each <<shard,Shard>> 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 <<replica,Replica>> for each <<shard,Shard>> that serves as the
source-of-truth and coordinates index updates (document additions or deletions)
to the <<follower,follower>> 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 <<solrclouddef,SolrCloud>>.
[[SolrGlossary-M]]
@@ -132,8 +149,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 <<server,Server>>.
[[SolrGlossary-O]]
=== O
@@ -163,7 +180,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 <<core,Core>> that acts as a physical copy of a <<shard,Shard>> in a
<<solrclouddef,SolrCloud>> <<collection,Collection>>.
+The physical manifestation of a logical <<shard,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 <<solrclouddef,SolrCloud>>.
[[replication]]xref:deployment-guide:user-managed-index-replication.adoc[Replication]::
@@ -179,12 +200,17 @@ 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 <<node,Nodes>>.
+
[[shard]]Shard::
-In SolrCloud, a logical partition of a single <<collection,Collection>>.
-Every shard consists of at least one physical <<replica,Replica>>, but there
may be multiple Replicas distributed across multiple <<node,Nodes>> for fault
tolerance.
+A logical slice of a <<collection,Collection>>.
+Each shard represents a partition containing a subset of the collection's
documents.
+A shard exists physically as one or more <<replica,Replicas>>, which may be
distributed across multiple <<node,Nodes>> for fault tolerance and scalability.
See also <<solrclouddef,SolrCloud>>.
-[[solrclouddef]]xref:deployment-guide: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
<<cluster,Cluster>> of Solr <<node,Nodes>> for scalability, fault tolerance,
and high availability.
[[schema]]xref:indexing-guide:schema-elements.adoc[Solr Schema
(managed-schema.xml or schema.xml)]::
@@ -213,6 +239,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 nodes that do not utilize Apache Zookeeper
and thus do not provide the centralized configuration management that is
available in <<solrclouddef,SolrCloud>> mode.
+This includes both standalone installations and <<usermanaged,User-Managed>>
clusters.
+In source code and documentation, "Standalone" may refer to either
<<usermanaged,User-Managed Mode>> or standalone deployments.
+See also xref:cluster-types.adoc[] and <<cluster,Cluster>>.
+
[[SolrGlossary-T]]
=== T
@@ -225,6 +257,16 @@ See also <<idf,Inverse document frequency (IDF)>>.
An append-only log of write operations maintained by each <<replica,Replica>>.
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-cluster[User-Managed
Cluster]::
+A mode of operating a Solr <<cluster,Cluster>> without the centralized
coordination provided by <<zookeeper,ZooKeeper>> in <<solrclouddef,SolrCloud>>
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 <<standalone,Standalone>> mode.
+See also xref:cluster-types.adoc[].
+
[[SolrGlossary-W]]
=== W
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 2ad1e684cc9..3a4fc8c081a 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/dense-vector-search.adoc
b/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc
index 15371bb0267..2681cc59840 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/other-parsers.adoc
b/solr/solr-ref-guide/modules/query-guide/pages/other-parsers.adoc
index e584e7c21f4..e293a42509f 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/query-guide/pages/result-grouping.adoc
b/solr/solr-ref-guide/modules/query-guide/pages/result-grouping.adoc
index cc3b824fdce..ce539c07f8b 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-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.
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 15979f8ac32..81220d51318 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
@@ -311,5 +311,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.
-
-----
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 fea8e94c5bf..9b122bbfaf9 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`::
+
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 a9f776d6dc4..e2d14fc5d31 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 105c61dee70..61f78985e9e 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 <<Major Changes in Earlier
7.x Versions>>, belo
Solr's LeaderInRecovery (LIR) functionality <<Solr 7.3,changed significantly>>
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.
