DOCSP-27878 EOL Cleanup for Sharding Tutorials (#2660)

kennethdyer · web-flow · commit d206f30764c7 · 2023-04-20T15:23:41.000-07:00
* DOCSP-27878 Removes EOL version references from Sharding Tutorials * Cleans troubleshooting sharded clusters * Removes EOL references * Removes EOL references * Removes Shard Standalone from build * Removes EOL references * Fixes per Joe * Fixes per Joe * Fixes per Rachita and Ratika
diff --git a/source/administration/sharded-cluster-administration.txt b/source/administration/sharded-cluster-administration.txt
@@ -27,7 +27,6 @@ Sharded Cluster Administration
    /tutorial/backup-sharded-cluster-metadata
    /tutorial/convert-sharded-cluster-to-replica-set
    /tutorial/convert-replica-set-to-replicated-shard-cluster
-   /tutorial/convert-shard-standalone-to-shard-replica-set
 
 :doc:`Config Server Administration </administration/sharded-cluster-config-servers>`
    This section contains articles and tutorials related to sharded
@@ -64,6 +63,3 @@ Sharded Cluster Administration
    Convert a replica set to a sharded cluster in which each shard is
    its own replica set.
 
-:doc:`/tutorial/convert-shard-standalone-to-shard-replica-set`
-   Convert a shard standalone instance to a shard replica set.
-
diff --git a/source/includes/fact-csrs-versionchanged.rst b/source/includes/fact-csrs-versionchanged.rst
@@ -1,14 +1,10 @@
-Starting in MongoDB 3.2, config servers for sharded clusters can be
-deployed as a :doc:`replica set </replication>` (CSRS) instead of three
-mirrored config servers (SCCC). Using a replica set for the config
+Config servers for sharded clusters can be
+deployed as a :ref:`replica set <replication>` (CSRS). 
+Using a replica set for the config
 servers improves consistency across the config servers, since MongoDB
 can take advantage of the standard replica set read and write protocols
 for the config data. In addition, using a replica set for config
 servers allows a sharded cluster to have more than 3 config servers
 since a replica set can have up to 50 members. To deploy config servers
-as a replica set, the config servers must run the :doc:`WiredTiger
-storage engine </core/wiredtiger>`.
-
-In version 3.4, MongoDB :ref:`removes support for SCCC config servers
-<3.4-compat-remove-sccc>`.
+as a replica set, the config servers must run the :ref:`storage-wiredtiger`. 
 
diff --git a/source/release-notes/3.6-compatibility.txt b/source/release-notes/3.6-compatibility.txt
@@ -29,9 +29,6 @@ Starting in 3.6, shards must be replica sets. To upgrade your sharded
 cluster to version 3.6, the shard servers must be running as a replica
 set.
 
-To convert an existing shard standalone instance to a shard replica
-set, see :doc:`/tutorial/convert-shard-standalone-to-shard-replica-set`.
-
 
 HTTP Interface and REST API
 ---------------------------
diff --git a/source/release-notes/3.6-upgrade-sharded-cluster.txt b/source/release-notes/3.6-upgrade-sharded-cluster.txt
@@ -51,9 +51,7 @@ Starting in MongoDB 3.6, :binary:`~bin.mongod` instances with the shard
 server role must be replica set members.
 
 To upgrade your sharded cluster to version 3.6, the shard servers must
-be running as a replica set. To convert an existing shard standalone
-instance to a shard replica set, see
-:doc:`/tutorial/convert-shard-standalone-to-shard-replica-set`.
+be running as a replica set. 
 
 Drivers
 ~~~~~~~
diff --git a/source/release-notes/3.6.txt b/source/release-notes/3.6.txt
@@ -979,9 +979,6 @@ Sharded Clusters
   cluster to version 3.6, the shard servers must be running as a
   replica set.
 
-  To convert an existing shard standalone instance to a shard replica
-  set, see :doc:`/tutorial/convert-shard-standalone-to-shard-replica-set`.
-
 - Starting in 3.6, all members of a shard replica set, not just the
   primary, maintain the metadata regarding chunk metadata. This
   prevents reads from the secondaries from returning :term:`orphaned
diff --git a/source/tutorial/backup-sharded-cluster-with-database-dumps.txt b/source/tutorial/backup-sharded-cluster-with-database-dumps.txt
@@ -13,9 +13,3 @@ Back Up a Sharded Cluster with Database Dumps
 
    .. include:: /includes/extracts/sharded-clusters-backup-restore-mongodump-mongorestore-restriction.rst
    
-   For MongoDB 4.0 and earlier deployments, refer to the corresponding
-   versions of the manual. For example:
-
-   - :v4.0:`https://www.mongodb.com/docs/v4.0 </tutorial/backup-sharded-cluster-with-database-dumps>`
-   - :v3.6:`https://www.mongodb.com/docs/v3.6 </tutorial/backup-sharded-cluster-with-database-dumps>`
-   - :v3.4:`https://www.mongodb.com/docs/v3.4 </tutorial/backup-sharded-cluster-with-database-dumps>`
diff --git a/source/tutorial/build-indexes-on-sharded-clusters.txt b/source/tutorial/build-indexes-on-sharded-clusters.txt
@@ -195,8 +195,7 @@ configuration updates:
            - Comment out the :setting:`sharding.clusterRole` option.
 
            - Set parameter :parameter:`skipShardingConfigurationChecks`
-             (also available for MongoDB 3.6.3+, 3.4.11+, 3.2.19+) to
-             ``true`` in the :setting:`setParameter` section.
+             to ``true`` in the :setting:`setParameter` section.
       
            - Set parameter ``disableLogicalSessionCacheRefresh`` to
              ``true`` in the :setting:`setParameter` section.
@@ -243,9 +242,8 @@ configuration updates:
             --configsvr>` if a config server member.
 
           - Set parameter
-            :parameter:`skipShardingConfigurationChecks` (also
-            available for MongoDB 3.6.3+, 3.4.11+, 3.2.19+) to
-            ``true`` in the :option:`--setParameter <mongod
+            :parameter:`skipShardingConfigurationChecks` 
+            to ``true`` in the :option:`--setParameter <mongod
             --setParameter>` option.
 
           - Set parameter ``disableLogicalSessionCacheRefresh``
diff --git a/source/tutorial/change-sharded-cluster-wiredtiger.txt b/source/tutorial/change-sharded-cluster-wiredtiger.txt
@@ -41,21 +41,14 @@ the shard configuration as well.
 PSA 3-member Architecture
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Starting in MongoDB 3.6, :readconcern:`"majority"` read concern,
-available for WiredTiger, is enabled by default. However, for MongoDB
-4.0.3+, if you have a three-member shard replica set with a
+The :readconcern:`"majority"` read concern,
+available for WiredTiger, is enabled by default. However,
+if you have a three-member shard replica set with a
 primary-secondary-arbiter (PSA) architecture, you can disable
 :readconcern:`"majority"` read concern for that shard replica set.
 Disabling :readconcern:`"majority"` for a three member PSA architecture
 avoids possible cache-pressure build up.
 
-The procedure below disables :readconcern:`"majority"` read concern for
-MongoDB 4.0.3 PSA architecture by including
-:option:`--enableMajorityReadConcern false <mongod
---enableMajorityReadConcern>`. If you are running a MongoDB 4.0.1 or
-4.0.2 PSA architecture, first upgrade to the latest 4.0 version in
-order to disable this read concern.
-
 .. note::
 
    .. include:: /includes/extracts/changestream-disable-rc-majority.rst
diff --git a/source/tutorial/convert-shard-standalone-to-shard-replica-set.txt b/source/tutorial/convert-shard-standalone-to-shard-replica-set.txt
diff --git a/source/tutorial/convert-standalone-to-replica-set.txt b/source/tutorial/convert-standalone-to-replica-set.txt
@@ -12,11 +12,6 @@ This tutorial describes the process for converting a :term:`standalone`
 standalone instances for testing and development, but always use
 replica sets in production.
 
-The procedure is specific to instances that are not part of a sharded
-cluster. To convert a shard standalone instance to a shard replica set,
-see :doc:`/tutorial/convert-shard-standalone-to-shard-replica-set`
-instead.
-
 To deploy a replica set without using a pre-existing
 :binary:`~bin.mongod` instance, see :doc:`/tutorial/deploy-replica-set`
 instead.
@@ -66,6 +61,3 @@ To add members to this replica set, use the :method:`rs.add()` method.
 For more information on adding members to a replica set, see
 :doc:`/tutorial/expand-replica-set`.
 
-.. seealso::
-
-   :doc:`/tutorial/convert-shard-standalone-to-shard-replica-set`
diff --git a/source/tutorial/create-chunks-in-sharded-cluster.txt b/source/tutorial/create-chunks-in-sharded-cluster.txt
@@ -24,7 +24,7 @@ data imbalance, such as with monotonically increasing or decreasing
 shard keys. Pre-splitting the ranges of an empty sharded collection
 can help with the throughput in these cases.
 
-Alternatively, starting in MongoDB 4.0.3, by defining the :doc:`zones
+Alternatively, by defining the :doc:`zones
 and zone ranges </core/zone-sharding>` *before* sharding an empty or a
 non-existing collection, the shard collection operation creates ranges
 for the defined zone ranges as well as any additional ranges to cover
diff --git a/source/tutorial/deploy-sharded-cluster-with-keyfile-access-control.txt b/source/tutorial/deploy-sharded-cluster-with-keyfile-access-control.txt
@@ -51,8 +51,6 @@ Considerations
 IP Binding
 ~~~~~~~~~~~
 
-.. versionchanged:: 3.6
-
 .. include:: /includes/fact-default-bind-ip-change.rst
 
 Keyfile Security
diff --git a/source/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster-no-downtime.txt b/source/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster-no-downtime.txt
@@ -50,8 +50,6 @@ or :opsmgr:`Ops Manager manual
 IP Binding
 ~~~~~~~~~~~
 
-.. versionchanged:: 3.6
-
 .. include:: /includes/fact-default-bind-ip-change.rst
 
 Internal and Client Authentication Mechanisms
diff --git a/source/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster.txt b/source/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster.txt
@@ -54,8 +54,6 @@ Considerations
 IP Binding
 ~~~~~~~~~~~
 
-.. versionchanged:: 3.6
-
 .. include:: /includes/fact-default-bind-ip-change.rst
 
 Operating System
diff --git a/source/tutorial/manage-shard-zone.txt b/source/tutorial/manage-shard-zone.txt
@@ -19,9 +19,7 @@ inside of the zone.
 
 .. tip::
 
-   .. versionchanged:: 4.0.3
-
-      .. include:: /includes/extracts/zoned-sharding-pre-define-zone.rst
+   .. include:: /includes/extracts/zoned-sharding-pre-define-zone.rst
 
 
 Add Shards to a Zone
diff --git a/source/tutorial/manage-sharded-cluster-balancer.txt b/source/tutorial/manage-sharded-cluster-balancer.txt
@@ -336,8 +336,7 @@ In the :data:`config.settings` collection:
   does not wait for replication to a secondary and instead continues
   with the next document.
   
-  Default behavior for :ref:`WiredTiger <storage-wiredtiger>` starting
-  in MongoDB 3.4.
+  This is the default behavior for :ref:`WiredTiger <storage-wiredtiger>`. 
 
 To change the ``_secondaryThrottle`` setting, connect to a
 :binary:`~bin.mongos` instance and directly update the
diff --git a/source/tutorial/migrate-sharded-cluster-to-new-hardware.txt b/source/tutorial/migrate-sharded-cluster-to-new-hardware.txt
@@ -57,8 +57,6 @@ For more information, see :ref:`sharding-balancing-disable-temporarily`.
 Migrate Each Config Server Separately
 -------------------------------------
 
-.. versionchanged:: 3.4
-
 .. include:: /includes/fact-csrs-versionchanged.rst
 
 .. include:: /includes/fact-config-server-replica-set-restrictions.rst
@@ -75,14 +73,12 @@ For each member of the config server replica set:
 Restart the ``mongos`` Instances
 --------------------------------
 
-.. versionchanged:: 3.2
-
-   With replica set config servers, the :binary:`~bin.mongos` instances
-   specify in the :option:`--configdb <mongos --configdb>` or :setting:`sharding.configDB`
-   setting the config server replica set name and at least one of the
-   replica set members. The :binary:`~bin.mongos` instances for the sharded
-   cluster must specify the same config server replica set name but can
-   specify different members of the replica set. 
+With replica set config servers, the :binary:`~bin.mongos` instances
+specify in the :option:`--configdb <mongos --configdb>` or :setting:`sharding.configDB`
+setting the config server replica set name and at least one of the
+replica set members. The :binary:`~bin.mongos` instances for the sharded
+cluster must specify the same config server replica set name but can
+specify different members of the replica set. 
 
 If a :binary:`~bin.mongos` instance specifies a migrated replica set member in
 the :option:`--configdb <mongos --configdb>` or :setting:`sharding.configDB` setting, update
@@ -200,4 +196,4 @@ For more information, see :ref:`sharding-balancing-enable`.
 
 .. [#autosplit-start]
 
-   .. include:: /includes/extracts/4.2-changes-start-balancer-autosplit.rst
+   .. include:: /includes/extracts/4.2-changes-start-balancer-autosplit.rst
diff --git a/source/tutorial/restore-sharded-cluster.txt b/source/tutorial/restore-sharded-cluster.txt
@@ -21,13 +21,6 @@ sharded cluster, see :ref:`backup-sharded-lvm`.
 .. note::
 
    .. include:: /includes/extracts/sharded-clusters-backup-restore-mongodump-mongorestore-restriction.rst
-   
-   For MongoDB 4.0 and earlier deployments, refer to the corresponding
-   versions of the manual. For example:
-
-   - :v4.0:`https://www.mongodb.com/docs/v4.0 </tutorial/restore-sharded-cluster>`
-   - :v3.6:`https://www.mongodb.com/docs/v3.6 </tutorial/restore-sharded-cluster>`
-   - :v3.4:`https://www.mongodb.com/docs/v3.4 </tutorial/restore-sharded-cluster>`
 
 Considerations
 --------------
diff --git a/source/tutorial/sharding-high-availability-writes.txt b/source/tutorial/sharding-high-availability-writes.txt
@@ -19,9 +19,8 @@ sharded cluster deployment and application-side logic to support distributed
 local writes, as well as high write availability in the event of a replica set
 election or datacenter failure.
 
-.. versionchanged:: 4.0.3
 
-   .. include:: /includes/extracts/zoned-sharding-pre-define-zone.rst
+.. include:: /includes/extracts/zoned-sharding-pre-define-zone.rst
 
 .. important::
 
diff --git a/source/tutorial/sharding-segmenting-data-by-location.txt b/source/tutorial/sharding-segmenting-data-by-location.txt
@@ -14,9 +14,7 @@ Segmenting Data by Location
 
 .. tip::
 
-   .. versionchanged:: 4.0.3
-
-      .. include:: /includes/extracts/zoned-sharding-pre-define-zone.rst
+   .. include:: /includes/extracts/zoned-sharding-pre-define-zone.rst
 
 This tutorial uses :ref:`zone-sharding` to segment data based on a
 geographic area.
diff --git a/source/tutorial/sharding-segmenting-shards.txt b/source/tutorial/sharding-segmenting-shards.txt
diff --git a/source/tutorial/sharding-tiered-hardware-for-varying-slas.txt b/source/tutorial/sharding-tiered-hardware-for-varying-slas.txt
diff --git a/source/tutorial/troubleshoot-sharded-clusters.txt b/source/tutorial/troubleshoot-sharded-clusters.txt
