DOCSP-26471 schema validation - shard key doc directives (#2440)

jmd-mongo · web-flow · commit 622201aa4492 · 2023-01-25T09:23:07.000-08:00
* DOCSP-26471 schema validation - shard key doc directives * internal review feedback * internal review feedback
diff --git a/source/administration/configuration.txt b/source/administration/configuration.txt
@@ -267,8 +267,8 @@ Sharding Configuration
 
 Sharding requires :binary:`~bin.mongod` instances with different
 :binary:`~bin.mongod` configurations for the :ref:`config servers
-<sharded-cluster-config-server>` and the :doc:`shards
-</core/sharded-cluster-shards>`. The config servers store the cluster's
+<sharded-cluster-config-server>` and the :ref:`shards
+<shards-concepts>`. The config servers store the cluster's
 metadata, while the shards store the data.
 
 To configure the config server :binary:`~bin.mongod` instances, in the
diff --git a/source/administration/production-notes.txt b/source/administration/production-notes.txt
@@ -615,8 +615,8 @@ set deployments.
 Sharded Clusters
 ~~~~~~~~~~~~~~~~
 
-See :doc:`Sharded Cluster Production Architecture
-</core/sharded-cluster-components>` for an
+See :ref:`Sharded Cluster Production Architecture
+<sharding-shards>` for an
 overview of recommended sharded cluster architectures for production
 deployments.
 
diff --git a/source/core/map-reduce.txt b/source/core/map-reduce.txt
@@ -90,8 +90,8 @@ and restrictions on map-reduce operations, see the
 Sharded Collections
 -------------------
 
-MongoDB supports map-reduce operations on :doc:`sharded collections
-</sharding>`.
+MongoDB supports map-reduce operations on :ref:`sharded collections
+<sharding-background>`.
 
 However, starting in version 4.2, MongoDB deprecates the map-reduce
 option to *create* a new sharded collection and the use of the
diff --git a/source/core/security-ldap-external.txt b/source/core/security-ldap-external.txt
@@ -191,8 +191,8 @@ Replica Sets
 
 For :term:`replica sets <replica set>`, configure LDAP authorization on the
 :term:`secondary` and :term:`arbiter` members first before configuring the
-:term:`primary`. This also applies to :doc:`shard replica sets
-</core/sharded-cluster-shards>`, or :ref:`config server replica sets <csrs>`.
+:term:`primary`. This also applies to :ref:`shard replica sets
+<shards-concepts>`, or :ref:`config server replica sets <csrs>`.
 Configure one replica set member at a time to maintain a majority of members
 for write availability.
 
diff --git a/source/core/security-ldap.txt b/source/core/security-ldap.txt
@@ -149,8 +149,8 @@ Deploying LDAP authentication on a replica set
 
 For :term:`replica sets <replica set>`, configure LDAP authentication on
 :term:`secondary` and :term:`arbiter` members first before configuring the
-:term:`primary`. This also applies to :doc:`shard replica sets
-</core/sharded-cluster-shards>`, or :ref:`config server replica sets <csrs>`.
+:term:`primary`. This also applies to :ref:`shard replica sets
+<shards-concepts>`, or :ref:`config server replica sets <csrs>`.
 Configure one replica set member at a time to maintain a majority of members
 for write availability.
 
diff --git a/source/core/sharded-cluster-components.txt b/source/core/sharded-cluster-components.txt
@@ -18,7 +18,7 @@ Sharded Cluster Components
 
 A MongoDB :term:`sharded cluster` consists of the following components:
 
-* :doc:`shard </core/sharded-cluster-shards>`: Each shard contains a
+* :ref:`shard <shards-concepts>`: Each shard contains a
   subset of the sharded data. As of MongoDB 3.6, shards must be deployed
   as a :term:`replica set`.
 
diff --git a/source/faq/sharding.txt b/source/faq/sharding.txt
@@ -16,8 +16,8 @@ This document answers common questions about :doc:`/sharding`. See also
 the :doc:`/sharding` section in the manual, which provides an
 :doc:`overview of sharding </sharding>`, including details on:
 
-- :doc:`Shard Keys and Considerations for Shard Key Selection
-  </core/sharding-shard-key>`
+- :ref:`Shard Keys and Considerations for Shard Key Selection
+  <sharding-shard-key>`
 
 - :ref:`Query Routing <sharding-read-operations>`
 
diff --git a/source/includes/fact-selinux-server-side-js.rst b/source/includes/fact-selinux-server-side-js.rst
@@ -1,6 +1,6 @@
 .. note::
 
    If you are using SELinux, any MongoDB operation that requires
-   :doc:`server-side JavaScript </core/server-side-javascript>` will
+   :ref:`server-side JavaScript <server-side-javascript>` will
    result in segfault errors. :ref:`disable-server-side-js` describes
    how to disable execution of server-side JavaScript.
diff --git a/source/includes/fact-sharded-cluster-components.rst b/source/includes/fact-sharded-cluster-components.rst
@@ -1,6 +1,6 @@
 A MongoDB :term:`sharded cluster` consists of the following components:
 
-- :doc:`shard </core/sharded-cluster-shards>`: Each shard contains a
+- :ref:`shard <shards-concepts>`: Each shard contains a
   subset of the sharded data. Each shard can be deployed as a :term:`replica
   set`.
 
diff --git a/source/includes/limits-sharding-unavailable-operations.rst b/source/includes/limits-sharding-unavailable-operations.rst
@@ -5,5 +5,5 @@ un-sharded collections.
 The :dbcommand:`geoSearch` command is not supported in sharded
 environments.
 
-In MongoDB 5.0 and earlier, you cannot specify :doc:`sharded collections
-</sharding>` in the ``from`` parameter of :pipeline:`$lookup` stages.
+In MongoDB 5.0 and earlier, you cannot specify :ref:`sharded collections
+<sharding-background>` in the ``from`` parameter of :pipeline:`$lookup` stages.
diff --git a/source/includes/steps-stop-sharded-cluster.yaml b/source/includes/steps-stop-sharded-cluster.yaml
@@ -18,7 +18,7 @@ ref: stop-shards
 content: |
 
    Run :method:`db.shutdownServer()` from the ``admin`` database on each
-   :doc:`shard </core/sharded-cluster-shards>` replica set member to shutdown
+   :ref:`shard <shards-concepts>` replica set member to shutdown
    its :binary:`mongod <bin.mongod>` process. Shutdown all secondary members
    before shutting down the primary in each replica set.
 
diff --git a/source/reference/command/enableSharding.txt b/source/reference/command/enableSharding.txt
@@ -20,7 +20,7 @@ Definition
       .. versionchanged:: 6.0
 
       Starting in MongoDB 6.0, this command is **not** required to
-      :doc:`shard </sharding>` a collection.
+      :ref:`shard <sharding-background>` a collection.
 
    The :dbcommand:`enableSharding` command explicitly creates a database.
 
diff --git a/source/reference/command/insert.txt b/source/reference/command/insert.txt
@@ -195,7 +195,7 @@ three documents. See :ref:`insert-command-output` for details.
 Using Insert with ``bypassDocumentValidation``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If :doc:`schema validation validationActions</core/schema-validation>` 
+If :ref:`schema validation validationActions <schema-validation-overview>` 
 are set to ``error``, inserts to a collection return errors for 
 documents that violate the schema validation rules. To insert documents
 which would violate these rules set ``bypassDocumentValidation: true``.
diff --git a/source/reference/command/refineCollectionShardKey.txt b/source/reference/command/refineCollectionShardKey.txt
@@ -82,7 +82,7 @@ The command takes the following fields:
      - .. _refineCollectionShardKey-key:
      
        The document that specifies the field or fields to use as the
-       new :doc:`shard key </core/sharding-shard-key>` for the
+       new :ref:`shard key <sharding-shard-key>` for the
        collection.
 
        ``{ <existing key specification>, <suffix1>: <1|"hashed">, ... }``
diff --git a/source/reference/command/reshardCollection.txt b/source/reference/command/reshardCollection.txt
@@ -66,7 +66,7 @@ The command takes the following fields:
    * - ``key``
      - document
      - The document that specifies the new field or fields to use as the
-       :doc:`shard key </core/sharding-shard-key/>`.
+       :ref:`shard key <sharding-shard-key>`.
  
        ``{ <field1>: <1|"hashed">, ... }``
  
diff --git a/source/reference/command/shardCollection.txt b/source/reference/command/shardCollection.txt
@@ -70,7 +70,7 @@ The command takes the following fields:
    * - ``key``
      - document
      - The document that specifies the field or fields to use as the
-       :doc:`shard key </core/sharding-shard-key/>`.
+       :ref:`shard key <sharding-shard-key>`.
  
        ``{ <field1>: <1|"hashed">, ... }``
  
@@ -81,7 +81,7 @@ The command takes the following fields:
        - ``"hashed"`` to specify a
          :ref:`hashed shard key <hashed-shard-keys>`.
        
-       :doc:`shard key </core/sharding-shard-key/>` must be
+       :ref:`shard key <sharding-shard-key>` must be
        supported by an index. Unless the collection is empty, the
        index must exist prior to the :dbcommand:`shardCollection`
        command. If the collection is empty, MongoDB creates the
diff --git a/source/reference/method/db.killOp.txt b/source/reference/method/db.killOp.txt
@@ -138,7 +138,7 @@ Kill Write Operations
 
 Within a Session
    MongoDB drivers associate all operations with a 
-   :doc:`server session </reference/server-sessions>`, with the
+   :ref:`server session <server-sessions>`, with the
    exception of unacknowledged writes.
 
    If the write operation is associated with a session, you can use the
diff --git a/source/reference/method/sh.enableSharding.txt b/source/reference/method/sh.enableSharding.txt
@@ -20,7 +20,7 @@ Definition
       .. versionchanged:: 6.0
 
       Starting in MongoDB 6.0, this method is **not** required to
-      :doc:`shard </sharding>` a collection.
+      :ref:`shard <sharding-background>` a collection.
 
    Explicitly creates a database.  Use the :binary:`~bin.mongosh` method
    :method:`sh.shardCollection()` to shard collections on the database.
diff --git a/source/reference/method/sh.reshardCollection.txt b/source/reference/method/sh.reshardCollection.txt
@@ -44,7 +44,7 @@ Definition
         - document
 
         - The document that specifies the new field or fields to use as the
-          :doc:`shard key </core/sharding-shard-key/>`.
+          :ref:`shard key <sharding-shard-key>`.
 
           ``{ <field1>: <1|"hashed">, ... }``
 
diff --git a/source/reference/method/sh.shardCollection.txt b/source/reference/method/sh.shardCollection.txt
@@ -56,7 +56,7 @@ Definition
         - document
    
         - The document that specifies the field or fields to use as the
-          :doc:`shard key </core/sharding-shard-key/>`. 
+          :ref:`shard key <sharding-shard-key>`. 
           
           ``{ <field1>: <1|"hashed">, ... }``
 
@@ -67,7 +67,7 @@ Definition
           - ``"hashed"`` to specify a
             :ref:`hashed shard key <hashed-shard-keys>`.
           
-          :doc:`shard key </core/sharding-shard-key/>` must be
+          :ref:`shard key <sharding-shard-key>` must be
           supported by an index. Unless the collection is empty, the
           index must exist prior to the :dbcommand:`shardCollection`
           command. If the collection is empty, MongoDB creates the
diff --git a/source/release-notes/5.0.txt b/source/release-notes/5.0.txt
@@ -1321,7 +1321,7 @@ Closure of Inactive Cursors Opened Within a Session
 
 Starting in MongoDB 5.0 (and 4.4.8), cursors created within a 
 :doc:`client session </core/read-isolation-consistency-recency>` close 
-when the corresponding :doc:`server session </reference/server-sessions>` 
+when the corresponding :ref:`server session <server-sessions>` 
 ends with the :dbcommand:`killSessions` command, if the session times 
 out, or if the client has exhausted the cursor. 
 See :ref:`read-operations-cursors`.
diff --git a/source/replication.txt b/source/replication.txt
@@ -61,7 +61,7 @@ operation, see :doc:`/core/replica-set-primary`.
 
 .. include:: /images/replica-set-read-write-operations-primary.rst
 
-The :doc:`secondaries </core/replica-set-secondary>` replicate the
+The :ref:`secondaries <replica-set-secondary-members-ref>` replicate the
 primary's oplog and apply the operations to their data sets such that
 the secondaries' data sets reflect the primary's data set. If the
 primary is unavailable, an eligible secondary will hold an election to
@@ -82,9 +82,8 @@ see :doc:`/core/replica-set-arbiter`.
 
 An :ref:`arbiter <replica-set-arbiter-configuration>` will always be an arbiter
 whereas a :doc:`primary </core/replica-set-primary>` may step down and
-become a :doc:`secondary </core/replica-set-secondary>` and a
-:doc:`secondary </core/replica-set-secondary>` may become the primary
-during an election.
+become a :ref:`secondary <replica-set-secondary-members-ref>` and a
+secondary may become the primary during an election.
 
 .. _asynchronous-replication:
 
diff --git a/source/sharding.txt b/source/sharding.txt
@@ -71,7 +71,7 @@ Sharded Cluster
 
 A MongoDB :term:`sharded cluster` consists of the following components:
 
-* :doc:`shard </core/sharded-cluster-shards>`: Each shard contains a
+* :ref:`shard <shards-concepts>`: Each shard contains a
   subset of the sharded data. Each shard can be deployed as a :term:`replica
   set`.
 
@@ -94,7 +94,7 @@ collection data across the shards in the cluster.
 Shard Keys
 ----------
 
-MongoDB uses the :doc:`shard key </core/sharding-shard-key>` to
+MongoDB uses the :ref:`shard key <sharding-shard-key>` to
 distribute the collection's documents across shards. The shard key
 consists of a field or multiple fields in the documents. 
 
diff --git a/source/tutorial/connection-pool-performance-tuning.txt b/source/tutorial/connection-pool-performance-tuning.txt
@@ -22,7 +22,7 @@ Tuning Your Connection Pool Settings
      - Solution
 
    * - Slow application-side operation times that are not reflected in 
-       the database :doc:`server logs </reference/log-messages>` or the
+       the database :ref:`server logs <log-messages-ref>` or the
        real time panel.
   
      - Use :urioption:`connectTimeoutMS` to ensure the driver does not 
@@ -46,9 +46,8 @@ Tuning Your Connection Pool Settings
        Set :urioption:`socketTimeoutMS` to two or three times the 
        length of the slowest operation that the driver runs.
      
-   * - The :doc:`server logs </reference/log-messages>` or real time panel
-       show that the application spends too much time creating new 
-       connections.
+   * - The server logs or real time panel show that the application 
+       spends too much time creating new connections.
 
      - Not enough connections are available at startup. 
        Allocate connections in the pool by setting 
@@ -69,8 +68,8 @@ Tuning Your Connection Pool Settings
        you are using. 
 
    * - Database CPU usage is higher than expected. The 
-       :doc:`server logs </reference/log-messages>` or real time panel
-       show more connection attempts than expected.
+       server logs or real time panel show more connection attempts 
+       than expected.
      
      - Decrease the :ref:`maxPoolSize <maxpoolsize-cp-setting>` or 
        reduce the number of threads in your application. This can reduce 
diff --git a/source/tutorial/iterate-a-cursor.txt b/source/tutorial/iterate-a-cursor.txt
@@ -123,7 +123,7 @@ Cursors Opened Within a Session
 
 Starting in MongoDB 5.0 (and 4.4.8), cursors created within a 
 :doc:`client session </core/read-isolation-consistency-recency>` close 
-when the corresponding :doc:`server session </reference/server-sessions>` 
+when the corresponding :ref:`server session <server-sessions>` 
 ends with the :dbcommand:`killSessions` command, if the session times 
 out, or if the client has exhausted the cursor. 
 
diff --git a/source/tutorial/restart-sharded-cluster.txt b/source/tutorial/restart-sharded-cluster.txt
@@ -17,7 +17,7 @@ Manual.
 This procedure demonstrates the shutdown and startup sequence for restarting
 a sharded cluster. Stopping or starting the components of a sharded cluster
 in a different order may cause communication errors between members. For
-example, :doc:`shard </core/sharded-cluster-shards>` servers may appear to hang
+example, :ref:`shard <shards-concepts>` servers may appear to hang
 if there are no :ref:`config servers <sharding-config-server>`
 available.
 
