DOCSP-26450 Replacearviter-backup operations docs with refs (#2334)

Author: lindseymoore

source/administration/production-notes.txt

@@ -226,12 +226,12 @@ require access, such as application servers, monitoring services, and
 other MongoDB components.
 
 .. important::
-   By default, :doc:`authorization </core/authorization>` is not
+   By default, :ref:`authorization <authorization>` is not
    enabled, and :binary:`~bin.mongod` assumes a trusted environment. Enable
    :setting:`~security.authorization` mode as needed. For more
    information on authentication mechanisms supported in MongoDB as
-   well as authorization in MongoDB, see :doc:`/core/authentication`
-   and :doc:`/core/authorization`.
+   well as authorization in MongoDB, see :ref:`<authentication>`
+   and :ref:`<authorization>`.
 
 For additional information and considerations on security, refer to the
 documents in the :ref:`Security Section <security>`, specifically:

source/core/replica-set-architecture-three-members.txt

@@ -67,7 +67,7 @@ A three member replica set with a two members that store data has:
   secondary can become primary in an :doc:`election
   </core/replica-set-elections>`.
 
-- One :doc:`arbiter </core/replica-set-arbiter>`. The arbiter only
+- One :ref:`arbiter <replica-set-arbiter-configuration>`. The arbiter only
   votes in elections.
 
 .. include:: /images/replica-set-primary-with-secondary-and-arbiter.rst

source/includes/fact-config-server-replica-set-restrictions.rst

@@ -1,7 +1,7 @@
 The following restrictions apply to a replica set configuration when used
 for config servers:
 
-- Must have zero :doc:`arbiters </core/replica-set-arbiter>`.
+- Must have zero :ref:`arbiters <replica-set-arbiter-configuration>`.
 
 - Must have no :doc:`delayed members
   </core/replica-set-delayed-member>`.

source/reference/command/fsyncUnlock.txt

@@ -37,7 +37,7 @@ Definition
 
    :dbcommand:`fsyncUnlock` is an administrative operation. Typically
    you will use :dbcommand:`fsyncUnlock` following a database
-   :doc:`backup operation </core/backups>`.
+   :ref:`backup operation <backup-methods>`.
 
 Syntax
 ------

source/reference/command/logApplicationMessage.txt

@@ -18,7 +18,7 @@ Definition
    .. include:: /includes/note-audit-in-enterprise-only.rst
 
    The :dbcommand:`logApplicationMessage` command allows users to post
-   a custom message to the :doc:`audit </core/auditing>` log. If
+   a custom message to the :ref:`audit <auditing>` log. If
    running with authorization, users must have :authrole:`clusterAdmin`
    role, or roles that inherit from :authrole:`clusterAdmin`, to run
    the command.

source/reference/command/rotateCertificates.txt

@@ -175,7 +175,7 @@ information:
 
 The following performs the same as above, but also writes a custom log
 message at rotation time to the :ref:`log file
-<log-message-destinations>` and :doc:`audit file </core/auditing>`:
+<log-message-destinations>` and :ref:`audit file <auditing>`:
 
 .. code-block:: javascript
 

source/reference/method/db.fsyncLock.txt

@@ -63,7 +63,7 @@ Definition
 
    :method:`db.fsyncLock()` is an administrative command. You can use
    this operation to locks the database and create a window for
-   :doc:`backup operations </core/backups>`.
+   :ref:`backup operations <backup-methods>`.
 
 Behavior
 --------

source/reference/method/db.fsyncUnlock.txt

@@ -37,7 +37,7 @@ Definition
 
    :method:`db.fsyncUnlock()` is an administrative operation. Typically
    you will use :method:`db.fsyncUnlock()` following a database
-   :doc:`backup operation </core/backups>`.
+   :ref:`backup operation <backup-methods>`.
 
    :method:`db.fsyncUnlock()`  has the syntax:
 

source/reference/method/db.rotateCertificates.txt

@@ -173,7 +173,7 @@ information:
 
 The following performs the same as above, but also writes a custom log
 message at rotation time to the :ref:`log file
-<log-message-destinations>` and :doc:`audit file </core/auditing>`:
+<log-message-destinations>` and :ref:`audit file <auditing>`:
 
 .. code-block:: javascript
 

source/replication.txt

@@ -73,14 +73,14 @@ members, see :doc:`/core/replica-set-secondary`.
 In some circumstances (such as you have a primary and a secondary but
 cost constraints prohibit adding another secondary), you may choose to
 add a :binary:`~bin.mongod` instance to a replica set as an
-:doc:`arbiter </core/replica-set-arbiter>`. An arbiter participates in
+:ref:`arbiter <replica-set-arbiter-configuration>`. An arbiter participates in
 :ref:`elections <replica-set-elections>` but does not hold data (i.e.
 does not provide data redundancy). For more information on arbiters,
 see :doc:`/core/replica-set-arbiter`.
 
 .. include:: /images/replica-set-primary-with-secondary-and-arbiter.rst
 
-An :doc:`arbiter </core/replica-set-arbiter>` will always be an arbiter
+An :ref:`arbiter <replica-set-arbiter-configuration>` will always be an arbiter
 whereas a :doc:`primary </core/replica-set-primary>` may step down and
 become a :doc:`secondary </core/replica-set-secondary>` and a
 :doc:`secondary </core/replica-set-secondary>` may become the primary