DOCSP-26700 Removes EOL version references from Replication - v4.4 (#2249)

* 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. 
 
-.. versionchanged:: 4.0
-
-   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>`.
 
 .. versionadded:: 4.4
 
@@ -217,8 +215,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
@@ -256,11 +253,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.4.2, 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

@@ -41,9 +41,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.
 
 .. _replica-set-rollback-data:
 
@@ -115,7 +114,7 @@ By default, when a rollback occurs, MongoDB writes the rollback data to
                if (foundcollection) { break; }
             }
 
-   .. tab:: MongoDB 4.2-4.0
+   .. tab:: MongoDB 4.2
       :tabid: 4.2
 
       For each collection whose data is rolled back, the
@@ -137,20 +136,6 @@ By default, when a rollback occurs, MongoDB writes the rollback data to
 
       where ``<dbpath>`` is the :binary:`~bin.mongod`'s :setting:`~storage.dbPath`.
 
-   .. tab:: MongoDB 3.6 and earlier
-      :tabid: 3.6
-
-      In versions 3.6 and earlier, rollback files are located directly under the
-      ``<dbpath>/rollback`` directory with the filenames of the form
-      ``<db>.<collection>.<timestamp>.bson``.
-      
-      For example, if data for the collection ``comments`` in the
-      ``reporting`` database rolled back:
-
-      .. code-block:: none
-         :copyable: false
-
-         <dbpath>/rollbacktest.col.2020-02-19T04-46-22.0.bson
 
 Rollback Data Exclusion
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -219,35 +204,19 @@ Index Operations When :readconcern:`"majority"` Read Concern is Disabled
 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::
 

source/core/replica-set-sync.txt

@@ -251,14 +251,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

@@ -362,12 +362,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,7 +97,7 @@ content: |
 ref: 4.2-changes-slow-oplog-log-message-footnote
 content: |
 
-   Starting in version 4.2 (also available starting in 4.0.6), secondary
+   Starting in version 4.2, secondary
    members of a replica set now :ref:`log oplog entries
    <slow-oplog-application>` that take longer than the slow operation
    threshold to apply. These slow oplog messages:
@@ -116,7 +116,7 @@ content: |
    - May be affected by :setting:`~operationProfiling.slowOpSampleRate`,
      depending on your MongoDB version:
 
-     - In MongoDB 4.2 and earlier, these slow oplog entries are not
+     - 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.
 

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``.