DOCSP-26700 Removes EOL version references from Replication - backport v4.2 (#2252)

* DOCSP-26700 Removes EOL version references from Replication  (#2194)

* Fixes build error

Author: kennethdyer

source/core/replica-set-elections.txt

@@ -49,17 +49,12 @@ Factors and Conditions that Affect Elections
 Replication Election Protocol
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionchanged:: 4.0
-
-   MongoDB 4.0 removes the deprecated replication protocol version 0.
-
 Replication :rsconf:`protocolVersion: 1 <protocolVersion>` reduces
 replica set failover time and accelerate the detection of multiple
 simultaneous primaries.
 
-With protocolVersion 1, you can use
-:rsconf:`~settings.catchUpTimeoutMillis` to prioritize between faster
-failovers and preservation of :writeconcern:`w:1 <\<number\>>` writes.
+You can use :rsconf:`~settings.catchUpTimeoutMillis` to prioritize between 
+faster failovers and preservation of :writeconcern:`w:1 <\<number\>>` writes.
 
 For more information on ``pv1``, see
 :doc:`/reference/replica-set-protocol-versions`.

source/core/replica-set-oplog.txt

@@ -16,11 +16,9 @@ The :term:`oplog` (operations log) is a special :term:`capped
 collection` that keeps a rolling record of all operations that modify
 the data stored in your databases. 
 
-.. note::
-
-   Starting in MongoDB 4.0, unlike other capped collections, the oplog
-   can grow past its configured size limit to avoid deleting the
-   :data:`majority commit point <replSetGetStatus.optimes.lastCommittedOpTime>`.
+Unlike other capped collections, the oplog
+can grow past its configured size limit to avoid deleting the
+:data:`majority commit point <replSetGetStatus.optimes.lastCommittedOpTime>`.
 
 MongoDB applies database operations
 on the :term:`primary` and then records the operations on the
@@ -172,8 +170,7 @@ information.
 Slow Oplog Application
 ----------------------
 
-Starting in version 4.2 (also available starting in version 4.0.6),
-secondary members of a replica set now log oplog entries that take
+Secondary members of a replica set log oplog entries that take
 longer than the slow operation threshold to apply. These messages are
 :option:`logged <mongod --logpath>` for the secondaries under the
 :data:`REPL` component with the text ``applied op: <oplog entry> took
@@ -214,11 +211,10 @@ Oplog Collection Behavior
 
 You cannot :dbcommand:`drop` the ``local.oplog.rs`` collection from any 
 replica set member if your MongoDB deployment uses the :ref:`WiredTiger 
-Storage Engine <storage-wiredtiger>`. Starting in v4.2, you cannot drop 
-the ``local.oplog.rs`` collection from a standalone MongoDB instance, 
-and we recommend that you do not drop the collection from a standalone 
-MongoDB v4.0 instance. The :ref:`mongod` requires the oplog for both 
-:ref:`replication` and recovery of a node if the node goes down.
+Storage Engine <storage-wiredtiger>`. You cannot drop 
+the ``local.oplog.rs`` collection from a standalone MongoDB instance.
+:binary:`~bin.mongod` requires the oplog for
+both :ref:`replication` and recovery of a node if the node goes down.
 
 Starting in MongoDB 4.2.11, it is no longer possible to perform manual
 write operations to the :doc:`oplog </core/replica-set-oplog>` on a

source/core/replica-set-rollbacks.txt

@@ -45,9 +45,8 @@ Collect Rollback Data
 Configure Rollback Data
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-Starting in version 4.0, MongoDB adds the parameter
-:parameter:`createRollbackDataFiles` to control whether or not rollback
-files are created during rollbacks.
+The :parameter:`createRollbackDataFiles` parameter
+controls whether or not rollback files are created during rollbacks.
 
 Rollback Data
 ~~~~~~~~~~~~~
@@ -137,35 +136,19 @@ Index Builds
 Size Limitations
 ~~~~~~~~~~~~~~~~
 
-.. versionchanged:: 4.0
-
-Starting in version 4.0, MongoDB has no limit on the amount of data
-that can be rolled back.
-
-In previous versions, a :binary:`~bin.mongod` instance will not
-roll back more than 300 megabytes of data and requires manual
-intervention if more than 300 megabytes of data need to be rolled back.
+MongoDB does not limit the amount of data you can roll back.
 
 .. _rollback-time-limit:
 
 Rollback Elapsed Time Limitations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Starting in version 4.0, the rollback time limit defaults to 24 hours
-and is configurable using the parameter
-:parameter:`rollbackTimeLimitSecs`:
-
-- In MongoDB 4.2+ and 4.0.13+, the rollback time limit is calculated
-  between the first operation after the common point and the last point
-  in the oplog for the member to roll back.
-
-- In MongoDB 4.0.0-4.0.12, the rollback time limit is calculated between the
-  common point and the last point in the oplog for the member to roll
-  back.
+The rollback time limit defaults to 24 hours and is configurable using 
+the :parameter:`rollbackTimeLimitSecs` parameter.
 
-In MongoDB 3.6 and earlier, the rollback time limit is not configurable.
-For these versions, rollback is limited by the amount of data, with a
-maximum of 300 megabytes.
+MongoDB measures elapsed time as the time between the first common 
+operation in the oplogs to  the last entry in the oplog of the member
+being rolled back.
 
 .. seealso:: :doc:`/core/replica-set-high-availability` and
    :doc:`/core/replica-set-elections`.

source/core/replica-set-sync.txt

@@ -213,14 +213,13 @@ improve concurrency. MongoDB groups batches by document id (:ref:`WiredTiger
 operations using a different thread. MongoDB always applies write
 operations to a given document in their original write order.
 
-.. versionchanged:: 4.0
-
-Starting in MongoDB 4.0, read operations that
+Read operations that
 :ref:`target secondaries <replica-set-read-preference>` and are
 configured with a :ref:`read concern<read-concern>` level of
-:readconcern:`"local"` or  :readconcern:`"majority"` will now read from
+:readconcern:`"local"` or  :readconcern:`"majority"` read from
 a :ref:`WiredTiger<storage-wiredtiger>` snapshot of the data if the read
 takes place on a secondary where replication batches are being applied. 
+
 Reading from a snapshot guarantees a consistent view of the
 data, and allows the read to occur simultaneously with the ongoing
 replication without the need for a lock. As a result, secondary reads

source/core/transactions-in-applications.txt

@@ -423,12 +423,6 @@ clusters)*, clients :red:`must` use MongoDB drivers updated for MongoDB
 
 .. include:: /includes/list-4.2-drivers.rst
 
-*For transactions on MongoDB 4.0 replica sets*, clients require MongoDB
-drivers updated for MongoDB 4.0 or later.
-
-.. include:: /includes/list-4.0-drivers.rst
-
-
 .. _transactions-retry:
 
 Transaction Error Handling

source/includes/extracts-4.2-changes.yaml

@@ -97,16 +97,30 @@ content: |
 ref: 4.2-changes-slow-oplog-log-message-footnote
 content: |
 
-   Starting in version 4.2 (also available starting in 4.0.6), secondary members of a replica set now
-   :ref:`log oplog entries <slow-oplog>` that take longer than the slow
-   operation threshold to apply. These slow oplog messages are logged
-   for the secondaries in the :option:`diagnostic log <mongod
-   --logpath>` under the :data:`REPL` component with the text ``applied
-   op: <oplog entry> took <num>ms``. These slow oplog entries depend
-   only on the slow operation threshold. They do not depend on the log
-   levels (either at the system or component level), or the profiling
-   level, or the slow operation sample rate. The profiler does not
-   capture slow oplog entries.
+   Starting in version 4.2, secondary
+   members of a replica set now :ref:`log oplog entries
+   <slow-oplog>` that take longer than the slow operation
+   threshold to apply. These slow oplog messages:
+      
+   - Are logged for the secondaries in the
+     :option:`diagnostic log <mongod --logpath>`.
+     
+   - Are logged under the :data:`REPL` component with the text
+     ``applied op: <oplog entry> took <num>ms``.
+   
+   - Do not depend on the log levels (either at the system or component
+     level)
+   
+   - Do not depend on the profiling level.
+
+   - May be affected by :setting:`~operationProfiling.slowOpSampleRate`,
+     depending on your MongoDB version:
+
+     In MongoDB 4.2, these slow oplog entries are not
+     affected by the :setting:`~operationProfiling.slowOpSampleRate`.
+     MongoDB logs all slow oplog entries regardless of the sample rate.
+
+   The profiler does not capture slow oplog entries.
 ---
 ref: 4.2-changes-type-0
 content: |

source/includes/extracts-changestream.yaml

@@ -182,9 +182,7 @@ content: |
 ref: changestream-disable-rc-majority
 content: |
    
-   Disabling :readconcern:`"majority"` read concern disables support
-   for :doc:`/changeStreams` for MongoDB 4.0 and earlier. For MongoDB
-   4.2+, disabling read concern ``"majority"`` has no effect on change
+   Disabling :readconcern:`"majority"` read concern has no effect on change
    streams availability.
 ---
 ref: changestream-rc-majority-4.2

source/includes/extracts-default-bind-ip-security.yaml

@@ -1,41 +1,37 @@
 ref: default-bind-ip-security-command-line
 content: |
 
-   Starting in MongoDB 3.6, :binary:`~bin.mongod` and :binary:`~bin.mongos`
+   :binary:`~bin.mongod` and :binary:`~bin.mongos`
    bind to localhost by default. If the members of your deployment are
    run on different hosts or if you wish remote clients to connect to
-   your instance, you must specify the ``--bind_ip`` option. For more
-   information, see :ref:`3.6-bind_ip-compatibility`.
+   your instance, you must specify the ``--bind_ip`` option. 
 
 ---
 ref: default-bind-ip-security-config-file
 content: |
 
-   Starting in MongoDB 3.6, :binary:`~bin.mongod` and :binary:`~bin.mongos`
+   :binary:`~bin.mongod` and :binary:`~bin.mongos`
    bind to localhost by default. If the members of your deployment are
    run on different hosts or if you wish remote clients to connect to
    your deployment, you must specify the :setting:`net.bindIp` setting.
-   For more information, see :ref:`3.6-bind_ip-compatibility`.
 ---
 ref: default-bind-ip-security
 content: |
 
-   Starting in MongoDB 3.6, :binary:`~bin.mongod` and :binary:`~bin.mongos`
+   :binary:`~bin.mongod` and :binary:`~bin.mongos`
    bind to localhost by default. If the members of your deployment are
    run on different hosts or if you wish remote clients to connect to
    your deployment, you must specify ``--bind_ip`` or
-   :setting:`net.bindIp`. For more information, see
-   :ref:`3.6-bind_ip-compatibility`.
+   :setting:`net.bindIp`. 
 ---
 ref: default-bind-ip-security-windows
 content: |
 
-   Starting in MongoDB 3.6, :binary:`~bin.mongod.exe` and
+   :binary:`~bin.mongod.exe` and
    :binary:`~bin.mongos.exe` bind to localhost by default. If the members
    of your deployment are run on different hosts or if you wish remote
    clients to connect to your deployment, you must specify
-   ``--bind_ip`` or :setting:`net.bindIp`. For more information, see
-   :ref:`3.6-bind_ip-compatibility`. For more information on the
+   ``--bind_ip`` or :setting:`net.bindIp`. For more information on the
    configuration file, see :doc:`configuration
    options</reference/configuration-options>`.
        

source/includes/extracts-hybrid-index-fcv.yaml

@@ -24,11 +24,6 @@ content: |
     :ref:`index builds <index-operations>` to finish before starting a 
     rollback.
 
-  - For :ref:`feature compatibility version (fcv) <view-fcv>` ``"4.0"``,
-    MongoDB waits for any in-progress background 
-    :ref:`index builds <index-operations>` to finish before starting a 
-    rollback.
-
   For more information on the index build process, see
   :ref:`index-operations`.
 ---

source/includes/fact-arbiter-priority.rst

@@ -1,4 +1 @@
-Starting in MongoDB 3.6, arbiters have priority ``0``. When you upgrade
-a replica set to MongoDB 3.6, if the existing configuration has an
-arbiter with priority ``1``, MongoDB 3.6 reconfigures the arbiter to
-have priority ``0``.
+Arbiters have priority ``0``.