DOCS-14695-Upgrading language strength with regards to hidden delayed…

source/core/replica-set-delayed-member.txt

@@ -39,11 +39,16 @@ Delayed members:
   members. Set the priority to 0 to prevent a delayed member from
   becoming primary.
 
-- **Should be** :ref:`hidden <replica-set-hidden-members>`
+- **Must be** :ref:`hidden <replica-set-hidden-members>`
   members. Always prevent applications from seeing and querying
   delayed members.
 
-- *Do* vote in :term:`elections <election>` for primary, if :rsconf:`members[n].votes` is set to 1.
+- *Do* vote in :term:`elections <election>` for primary, if 
+  :rsconf:`members[n].votes` is set to 1. Ensuring that delayed members 
+  are non-voting by setting :rsconf:`members[n].votes` to 0 can help 
+  improve performance.
+
+.. include:: /includes/important-delayed-replica-set-members.rst
 
 Behavior
 ~~~~~~~~

source/core/replica-set-hidden-member.txt

@@ -39,8 +39,10 @@ Clients will not distribute reads with the appropriate :doc:`read
 preference </core/read-preference>` to hidden members. As a result, these
 members receive no traffic other than basic replication. Use hidden
 members for dedicated tasks such as reporting and
-backups. :doc:`Delayed members </core/replica-set-delayed-member>`
-should be hidden.
+backups.
+
+.. include:: /includes/important-delayed-replica-set-members.rst
+
 
 In a sharded cluster, :binary:`~bin.mongos` do not interact with hidden
 members.

source/includes/important-delayed-replica-set-members.rst

@@ -0,0 +1,34 @@
+.. important::
+
+   If your replica set contains :doc:`delayed members
+   </core/replica-set-delayed-member>` ensure that the delayed
+   members are hidden and non-voting. 
+
+   Hiding delayed replica set members prevents applications from seeing 
+   and querying delayed data without a direct connection to that member.
+   Making delayed replica set members non-voting means they will not 
+   count towards acknowledging write operations with write concern 
+   :writeconcern:`"majority"`.
+
+   If you do not hide delayed members and one or more nodes 
+   become unavailable, the replica set has to wait for the delayed 
+   member and the commit point lags. A lagged commit point can lead to
+   performance issues.
+
+   For example, consider a Primary-Secondary-Delayed replica set
+   configuration where the delayed secondary is voting with a 10
+   minute delay.
+
+   With one non-delayed secondary unavailable, the degraded configuration
+   of Primary-Delayed must wait at least 10 minutes to acknowledge a write
+   operation with :writeconcern:`"majority"`.The majority commit point 
+   will take longer to advance, leading to cache pressure similar 
+   performance issues with a
+   :ref:`Primary with a Secondary and an Arbiter<rs-architecture-psa>`
+   (PSA) replica set.
+
+   For more information on the majority commit point, see 
+   :doc:`Causal Consistency and Read and Write Concerns
+   </core/causal-consistency-read-write-concerns>`. For additional 
+   details on resolving performance issues see the
+   :ref:`replica set maintenance tutorial<performance-issues-psa>`.