From f2cadd51122db37d05687508847d86ad74036244 Mon Sep 17 00:00:00 2001 From: Andrew Feierabend Date: Fri, 6 Nov 2020 14:18:51 -0500 Subject: [PATCH] DOCS-13894 forbid manual writes to oplog when replset --- source/core/replica-set-oplog.txt | 7 ++ source/reference/local-database.txt | 25 +++--- source/tutorial/troubleshoot-replica-sets.txt | 80 ------------------- 3 files changed, 22 insertions(+), 90 deletions(-) diff --git a/source/core/replica-set-oplog.txt b/source/core/replica-set-oplog.txt index f468af6291a..58c2a59c81a 100644 --- a/source/core/replica-set-oplog.txt +++ b/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 ` on a +cluster running as a :ref:`replica set `. Performing write +operations to the oplog when running as a +:term:`standalone instance ` should only be done with +guidance from MongoDB Support. diff --git a/source/reference/local-database.txt b/source/reference/local-database.txt index 360c2f5b39a..289b70d21b8 100644 --- a/source/reference/local-database.txt +++ b/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 ` + on a cluster running as a :ref:`replica set `. + Performing write operations to the oplog when running as a + :term:`standalone instance ` should only be done with + guidance from MongoDB Support. .. data:: local.replset.minvalid diff --git a/source/tutorial/troubleshoot-replica-sets.txt b/source/tutorial/troubleshoot-replica-sets.txt index e9f4d0e3d14..01eb7431db3 100644 --- a/source/tutorial/troubleshoot-replica-sets.txt +++ b/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. - [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 ` 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.