1 files changed, 98 insertions, 0 deletions
diff --git a/src/third_party/wiredtiger/src/docs/durability.dox b/src/third_party/wiredtiger/src/docs/durability.dox
new file mode 100644
index 00000000000..30683335978
--- /dev/null
+++ b/src/third_party/wiredtiger/src/docs/durability.dox
@@ -0,0 +1,98 @@
+/*! @m_page{{c,java},durability,Commit-level durability}
+
+WiredTiger supports checkpoint durability by default, and optionally
+commit-level durability when logging is enabled. In most applications,
+commit-level durability impacts performance more than checkpoint
+durability; checkpoints offer basic operation durability across
+application or system failure without impacting performance (although
+the creation of each checkpoint is a relatively heavy-weight operation).
+See @ref checkpoint for information on checkpoint durability.
+
+Commit-level durability is implemented using a write-ahead log and is
+enabled using the \c log=(enabled) configuration to ::wiredtiger_open.
+When logging is enabled, WiredTiger writes records to the log for each
+transaction.
+
+Transactions define which updates are made durable together; see
+@ref transactions for details.  By default, log records are buffered in memory
+when written by WT_SESSION::commit_transaction.  See
+@ref durability_group_commit for information about durability options.
+
+When the transactional log is enabled, calling ::wiredtiger_open
+automatically performs a recovery step when opening the database that
+applies whatever changes from the log are required to bring the database
+up to date with the most recent transactional state.  This recovery step
+may require extensions be available when it runs (for example, collators
+and compression).  Therefore, applications doing recovery must configure
+extensions with the \c extensions keyword to ::wiredtiger_open consistently
+whenever re-opening the database.
+
+Recovery is required after the failure of any thread of control in the
+application, where the failed thread might have been executing inside
+of the WiredTiger library or open WiredTiger handles have been lost.  In
+most applications, if any thread of control exits unexpectedly, the
+application will close and re-open the database.
+
+@section durability_checkpoint Checkpoints
+
+Checkpoints of the database should still be performed periodically when
+commit-level durability is configured, either explicitly from the
+application or periodically based on elapsed time or data size with the
+\c checkpoint configuration to ::wiredtiger_open.
+
+Database checkpoints are necessary for two reasons: First, log files can
+only be archived after a checkpoint completes, and so the frequency of
+checkpoints determines the disk space required by log files.  Second,
+checkpoints bound the time required for recovery to complete after
+application or system failure by limiting the log records that need to
+be processed.
+
+@section durability_backup Backups
+
+With logging enabled, partial backups (backups where not all of the
+database objects are copied), may result in error messages during
+recovery, because data files referenced in the logs might not be found.
+Applications should either copy all objects and log files if
+commit-level durability of the copied database is required, or
+alternatively, copy only selected objects when backing up and not copy
+log files at all, then fall back to checkpoint durability when switching
+to the backup.
+
+@section durability_bulk Bulk loads
+
+@copydoc doc_bulk_durability
+
+@section durability_archiving Log file archival
+
+WiredTiger log files are named "WiredTigerLog.[number]" where "[number]"
+is a 10-digit value, for example, WiredTigerLog.0000000001".  The log
+file with the largest number in its name is the most recent log file
+written.  The log file size can be set using the \c log configuration
+to ::wiredtiger_open.
+
+By default, WiredTiger automatically removes log files no longer
+required for recovery.  Applications wanting to archive log files
+instead must disable log file removal using the \c log=(archive=false)
+configuration to ::wiredtiger_open.
+
+Log files may be removed or archived after a checkpoint has completed,
+as long as there's not a backup in progress.  Immediately after the checkpoint
+has completed, only the most recent log file is needed for recovery, and all
+other log files can be removed or archived.  Note that there must always
+be at least one log file for the database.
+
+Open log cursors prevents WiredTiger from automatically removing log files.
+Therefore, we recommend proactively closing log cursors when done with them.
+Applications manually removing log files should take care that no log cursors
+are opened in the log when removing files or errors may occur when trying
+to read a log record in a file that was removed.
+
+@section durability_tuning Tuning commit-level durability
+
+@subsection durability_group_commit Group commit
+@copydoc doc_tune_durability_group_commit
+
+@subsection durability_flush_config Flush call configuration
+@copydoc doc_tune_durability_flush_config
+
+ */