DOCSP-33986 fsync lock after crash (#5140) (#5164)

* DOCSP-33986 fsync lock after crash

* Adjusts text

* Adjusts text

* Fixes per Jeff

* Fixes per Jeff

Author: kennethdyer

source/reference/command/fsync.txt

@@ -144,6 +144,34 @@ each shard and returns the results, which includes the ``lockCount`` for each.
    and cluster. To reduce the lock count, use the :dbcommand:`fsyncUnlock`
    command.
 
+Fsync Locks after Failures
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Fsync locks execute on the primary in a replica set or sharded cluster.
+
+If the primary goes down or becomes unreachable due to network issues, the
+cluster :ref:`elects <replica-set-elections>` a new primary from the available
+secondaries. If a primary with an fsync lock goes down, the new primary does
+**not** retain the fsync lock and can handle write operations.  When elections
+occur during backup operations, the resulting backup may be inconsistent or
+unusable.
+
+To recover from the primary going down:
+
+#. Run the :dbcommand:`fsyncUnlock` command until the lock count reaches zero
+   to release the lock on all nodes.
+
+#. Issue the :dbcommand:`fsync` command to reestablish the fsync lock on the
+   cluster.
+
+#. Restart the backup.
+
+
+Additionally, fsync locks are persistent.  When the old primary comes online
+again, you need to use the :dbcommand:`fsyncUnlock` command to release the lock
+on the node.
+
+
 Examples
 --------
 

source/reference/method/db.fsyncLock.txt

@@ -64,6 +64,37 @@ Behavior
 
 .. include:: /includes/extracts/wt-fsync-lock-compatibility.rst
 
+
+Fsync Locks after Failures
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Fsync locks execute on the primary in a replica set or sharded cluster.
+
+
+If the primary goes down or becomes unreachable due to network issues, the
+cluster :ref:`elects <replica-set-elections>` a new primary from the available
+secondaries. If a primary with an fsync lock goes down, the new primary does
+**not** retain the fsync lock and can handle write operations.  When elections
+occur during backup operations, the resulting backup may be inconsistent or
+unusable.
+
+To recover from the primary going down:
+
+
+#. Run the :method:`db.fsyncUnlock` method until the lock count reaches zero
+   to release the lock on all nodes.
+
+#. Issue the :method:`db.fsyncLock` command to reestablish the fsync lock on the
+   cluster.
+
+#. Restart the backup.
+
+
+Additionally, fsync locks are persistent.  When the old primary comes online
+again, you need to run the :method:`db.fsyncUnlock` command to release the
+lock on the node.
+
+
 Example
 -------