Merge v4.0.22 into v4.0

source/core/replica-set-oplog.txt

@@ -218,3 +218,10 @@ set member. This restriction applies to both single-member and
 multi-member replica sets. Dropping the oplog can lead to data
 inconsistencies in the replica set if a node temporarily
 goes down and attempts to replay the oplog during the restart process.
+
+Starting in MongoDB 4.0.22, it is no longer possible to perform manual
+write operations to the :doc:`oplog </core/replica-set-oplog>` on a
+cluster running as a :ref:`replica set <replication>`. Performing write
+operations to the oplog when running as a
+:term:`standalone instance <standalone>` should only be done with
+guidance from MongoDB Support.

source/reference/local-database.txt

@@ -25,8 +25,8 @@ stores data used in the replication process and other
 instance-specific data. The ``local`` database is invisible to
 replication: collections in the ``local`` database are not replicated.
 
-Collection on all ``mongod`` Instances
---------------------------------------
+Collections on all ``mongod`` Instances
+---------------------------------------
 
 .. data:: local.startup_log
 
@@ -117,14 +117,19 @@ Collections on Replica Set Members
 
    :data:`local.oplog.rs` is the capped collection that holds the
    :term:`oplog`. You set its size at creation using the
-   :setting:`~replication.oplogSizeMB` setting. To resize the oplog after replica set
-   initiation, use the :doc:`/tutorial/change-oplog-size`
-   procedure. For additional information, see the
-   :ref:`replica-set-oplog-sizing` section.
-
-   .. note::
-
-      .. include:: /includes/fact-oplog-size.rst
+   :setting:`~replication.oplogSizeMB` setting. To resize the oplog
+   after replica set initiation, use the
+   :doc:`/tutorial/change-oplog-size` procedure. For additional
+   information, see the :ref:`replica-set-oplog-sizing` section.
+
+   .. include:: /includes/fact-oplog-size.rst
+
+   Starting in MongoDB 4.0.22, it is no longer possible to perform
+   manual write operations to the :doc:`oplog </core/replica-set-oplog>`
+   on a cluster running as a :ref:`replica set <replication>`.
+   Performing write operations to the oplog when running as a
+   :term:`standalone instance <standalone>` should only be done with
+   guidance from MongoDB Support.
 
 .. data:: local.replset.minvalid
 

source/tutorial/troubleshoot-replica-sets.txt

@@ -275,83 +275,3 @@ tutorial.
 .. [#oplog]
 
    .. include:: /includes/fact-oplog-size.rst
-
-Oplog Entry Timestamp Error
----------------------------
-
-.. todo:: link assertion 13290 here once assertion guide exists.
-
-Consider the following error in :binary:`~bin.mongod` output and logs:
-
-.. code-block:: javascript
-
-   replSet error fatal couldn't query the local local.oplog.rs collection.  Terminating mongod after 30 seconds.
-   <timestamp> [rsStart] bad replSet oplog entry?
-
-Often, an incorrectly typed value in the ``ts`` field in the last
-:term:`oplog` entry causes this error. The correct data type is
-Timestamp.
-
-Check the type of the ``ts`` value using the following two queries
-against the oplog collection:
-
-.. code-block:: javascript
-
-   db = db.getSiblingDB("local")
-   db.oplog.rs.find().sort({$natural:-1}).limit(1)
-   db.oplog.rs.find({ts:{$type:17}}).sort({$natural:-1}).limit(1)
-
-The first query returns the last document in the oplog, while the
-second returns the last document in the oplog where the ``ts`` value
-is a Timestamp. The :query:`$type` operator allows you to select
-:term:`BSON type <BSON types>` 17, is the Timestamp data type.
-
-If the queries don't return the same document, then the last document in
-the oplog has the wrong data type in the ``ts`` field.
-
-.. example::
-
-   If the first query returns this as the last oplog entry:
-
-   .. code-block:: javascript
-
-      { "ts" : {t: 1347982456000, i: 1},
-        "h" : NumberLong("8191276672478122996"),
-        "op" : "n",
-        "ns" : "",
-        "o" : { "msg" : "Reconfig set", "version" : 4 } }
-
-   And the second query returns this as the last entry where ``ts``
-   has the ``Timestamp`` type:
-
-   .. code-block:: javascript
-
-      { "ts" : Timestamp(1347982454000, 1),
-        "h" : NumberLong("6188469075153256465"),
-        "op" : "n",
-        "ns" : "",
-        "o" : { "msg" : "Reconfig set", "version" : 3 } }
-
-   Then the value for the ``ts`` field in the last oplog entry is of the
-   wrong data type.
-
-To set the proper type for this value and resolve this issue,
-use an update operation that resembles the following:
-
-.. code-block:: javascript
-
-   db.oplog.rs.update( { ts: { t:1347982456000, i:1 } },
-                       { $set: { ts: new Timestamp(1347982456000, 1)}})
-
-Modify the timestamp values as needed based on your oplog entry. This
-operation may take some period to complete because the update must
-scan and pull the entire oplog into memory.
-
-Duplicate Key Error on ``local.slaves``
----------------------------------------
-
-.. versionchanged:: 3.0.0
-
-MongoDB 3.0.0 removes the :data:`local.slaves` collection. For
-``local.slaves`` error in earlier versions of MongoDB, refer to the
-appropriate version of the MongoDB Manual.