@@ -57,10 +57,6 @@ metadata table is atomically updated to reference the new checkpoint.
57
57
Once the new checkpoint is accessible, WiredTiger frees pages from the
58
58
old checkpoints.
59
59
60
- Starting in MongoDB 5.0, you can use the
61
- :parameter:`minSnapshotHistoryWindowInSeconds` parameter to control how
62
- long WiredTiger keeps the snapshot history.
63
-
64
60
Using WiredTiger, even without :ref:`journaling
65
61
<storage-wiredtiger-journal>`, MongoDB can recover from the last
66
62
checkpoint; however, to recover changes made after the last checkpoint,
@@ -70,6 +66,24 @@ run with :ref:`journaling <storage-wiredtiger-journal>`.
70
66
71
67
.. include:: /includes/wiredtiger-node-nojournal.rst
72
68
69
+ .. _storage-snapshot-history:
70
+
71
+ Snapshot History Retention
72
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
73
+
74
+ Starting in MongoDB 5.0, you can use the
75
+ :parameter:`minSnapshotHistoryWindowInSeconds` parameter to specify how
76
+ long WiredTiger keeps the snapshot history.
77
+
78
+ Increasing the value of :parameter:`minSnapshotHistoryWindowInSeconds`
79
+ increases disk usage, because the server must maintain the history of
80
+ older modified values within the specified time window. The amount of
81
+ disk space used depends on your workload, with higher volume workloads
82
+ requiring more disk space.
83
+
84
+ MongoDB maintains the snapshot history in the ``WiredTigerHS.wt`` file,
85
+ located in your specified :setting:`~storage.dbPath`.
86
+
73
87
.. _storage-wiredtiger-journal:
74
88
75
89
Journal
0 commit comments