@@ -10,18 +10,11 @@ Change the Size of the Oplog
10
10
:depth: 1
11
11
:class: singlecol
12
12
13
- .. versionadded:: 3.6
14
-
15
13
This procedure changes the size of the oplog [#oplog]_ on each member of a
16
14
replica set using the :dbcommand:`replSetResizeOplog` command, starting
17
15
with the :term:`secondary` members before proceeding to the
18
- :term:`primary`.
19
-
20
- .. important::
21
-
22
- You can only run :dbcommand:`replSetResizeOplog` on
23
- replica set members running with the
24
- :ref:`WiredTiger storage engine <storage-wiredtiger>`.
16
+ :term:`primary`. The :dbcommand:`replSetResizeOplog` command only
17
+ supports the :ref:`storage-wiredtiger` storage engine.
25
18
26
19
Perform these steps on each :term:`secondary` replica set member
27
20
*first*. Once you have changed the oplog size for all secondary
@@ -76,3 +69,48 @@ member to 16 gigabytes, or 16000 megabytes.
76
69
.. [#oplog]
77
70
78
71
.. include:: /includes/fact-oplog-size.rst
72
+
73
+ .. compact-oplog-rs:
74
+
75
+ D. (Optional) Compact ``oplog.rs`` to reclaim disk space
76
+ --------------------------------------------------------
77
+
78
+ Reducing the size of the oplog does *not* automatically reclaim
79
+ the disk space allocated to the original oplog size. You must run
80
+ :dbcommand:`compact` against the ``oplog.rs`` collection in the
81
+ ``local`` database to reclaim disk space. There are no benefits to
82
+ running ``compact`` on the ``oplog.rs`` collection after increasing the
83
+ oplog size.
84
+
85
+ .. important::
86
+
87
+ The replica set member cannot replicate oplog entries while the
88
+ ``compact`` operation is ongoing. While ``compact`` runs, the
89
+ member may fall so far behind the primary that it cannot resume
90
+ replication. The likelihood of a member becoming "stale" during
91
+ the ``compact`` procedure increases with cluster write throughput,
92
+ and may be further exacerbated by the reduced oplog size.
93
+
94
+ Consider scheduling a maintenance window during which writes are
95
+ throttled or stopped to mitigate the risk of the member becoming
96
+ "stale" and requiring a :ref:`full resync <resync-replica-member>`.
97
+
98
+ Do **not** run ``compact`` against the primary replica set member.
99
+ Connect a :binary:`mongo <bin.mongo>` shell to the primary and run
100
+ :method:`rs.stepDown()`. If successful, the primary steps down and
101
+ closes all open connections. Reconnect the :binary:`mongo <bin.mongo>`
102
+ shell to the member and run the ``compact`` command on the member.
103
+
104
+ The following operation runs the ``compact`` command against the
105
+ ``oplog.rs`` collection:
106
+
107
+ .. code-block:: javascript
108
+
109
+ use local
110
+ db.runCommand({ "compact" : "oplog.rs" } )
111
+
112
+ For clusters enforcing :ref:`authentication <authentication>`,
113
+ authenticate as a user with the :authaction:`compact` privilege
114
+ action on the ``local`` database and the ``oplog.rs`` collection.
115
+ For complete documentation on :dbcommand:`compact` authentication
116
+ requirements, see :ref:`compact-authentication`.
0 commit comments