Skip to content

Commit 55909fa

Browse files
mdb-ashleymdb-ashley
authored
Merge pull request #2557 from i80and/DOP-3487-v4.4
[v4.4 BACKPORT] DOP-3487: Remove moribund instances of '.. cssclass:: checklist'
2 parents f6d8df1 + 8a5ea1f commit 55909fa

File tree

2 files changed

+245
-277
lines changed

2 files changed

+245
-277
lines changed

‎source/administration/production-checklist-development.txt‎

Lines changed: 91 additions & 101 deletions
Original file line numberDiff line numberDiff line change
@@ -20,14 +20,12 @@ deployment.
2020
Data Durability
2121
~~~~~~~~~~~~~~~
2222

23-
.. cssclass:: checklist
23+
- Ensure that your replica set includes at least three data-bearing voting
24+
members and that your write operations use ``w: majority`` :doc:`write
25+
concern </reference/write-concern>`. Three data-bearing voting members are
26+
required for replica-set wide data durability.
2427

25-
- Ensure that your replica set includes at least three data-bearing voting
26-
members and that your write operations use ``w: majority`` :doc:`write
27-
concern </reference/write-concern>`. Three data-bearing voting members are
28-
required for replica-set wide data durability.
29-
30-
- Ensure that all instances use :doc:`journaling </core/journaling>`.
28+
- Ensure that all instances use :doc:`journaling </core/journaling>`.
3129

3230
Schema Design
3331
~~~~~~~~~~~~~
@@ -38,118 +36,110 @@ facilitates iterative development and polymorphism. Nevertheless,
3836
collections often hold documents with highly homogeneous
3937
structures. See :doc:`/core/data-models` for more information.
4038

41-
.. cssclass:: checklist
42-
43-
- Determine the set of collections that you will need and the
44-
indexes required to support your queries. With the exception of
45-
the ``_id`` index, you must create all indexes explicitly: MongoDB
46-
does not automatically create any indexes other than ``_id``.
47-
48-
- Ensure that your schema design supports your deployment type: if
49-
you planning to use :term:`sharded clusters <sharded cluster>` for
50-
horizontal scaling, design your schema to include a strong shard
51-
key. The shard key affects read and write performance by
52-
determining how MongoDB partitions data. See: :doc:`Impacts of
53-
Shard Keys on Cluster Operations </core/sharding-shard-key>`
54-
for information about what qualities a shard key should possess.
55-
You cannot change the shard key once it is set.
56-
57-
- Ensure that your schema design does not rely on indexed arrays that
58-
grow in length without bound. Typically, best performance can
59-
be achieved when such indexed arrays have fewer than 1000 elements.
60-
61-
- Consider the document size limits when designing your schema.
62-
The :limit:`BSON Document Size` limit is 16MB per document. If
63-
you require larger documents, use :doc:`GridFS </core/gridfs>`.
39+
- Determine the set of collections that you will need and the
40+
indexes required to support your queries. With the exception of
41+
the ``_id`` index, you must create all indexes explicitly: MongoDB
42+
does not automatically create any indexes other than ``_id``.
43+
44+
- Ensure that your schema design supports your deployment type: if
45+
you planning to use :term:`sharded clusters <sharded cluster>` for
46+
horizontal scaling, design your schema to include a strong shard
47+
key. The shard key affects read and write performance by
48+
determining how MongoDB partitions data. See: :doc:`Impacts of
49+
Shard Keys on Cluster Operations </core/sharding-shard-key>`
50+
for information about what qualities a shard key should possess.
51+
You cannot change the shard key once it is set.
52+
53+
- Ensure that your schema design does not rely on indexed arrays that
54+
grow in length without bound. Typically, best performance can
55+
be achieved when such indexed arrays have fewer than 1000 elements.
56+
57+
- Consider the document size limits when designing your schema.
58+
The :limit:`BSON Document Size` limit is 16MB per document. If
59+
you require larger documents, use :doc:`GridFS </core/gridfs>`.
6460

6561
Replication
6662
~~~~~~~~~~~
6763

68-
.. cssclass:: checklist
69-
70-
- Use an odd number of voting members to ensure that elections
71-
proceed successfully. You can have up to 7 voting members. If you
72-
have an *even* number of voting members, and constraints, such as
73-
cost, prohibit adding another secondary to be a voting member, you
74-
can add an :term:`arbiter` to ensure an odd number of votes. For
75-
additional considerations when using an arbiter for a 3-member
76-
replica set (P-S-A), see :doc:`/core/replica-set-arbiter`.
64+
- Use an odd number of voting members to ensure that elections
65+
proceed successfully. You can have up to 7 voting members. If you
66+
have an *even* number of voting members, and constraints, such as
67+
cost, prohibit adding another secondary to be a voting member, you
68+
can add an :term:`arbiter` to ensure an odd number of votes. For
69+
additional considerations when using an arbiter for a 3-member
70+
replica set (P-S-A), see :doc:`/core/replica-set-arbiter`.
7771

78-
.. note::
72+
.. note::
7973

80-
.. include:: /includes/extracts/arbiters-and-pvs-with-reference.rst
74+
.. include:: /includes/extracts/arbiters-and-pvs-with-reference.rst
8175

82-
- Ensure that your secondaries remain up-to-date by using
83-
:doc:`monitoring tools </administration/monitoring>` and by
84-
specifying appropriate :doc:`write concern
85-
</reference/write-concern>`.
76+
- Ensure that your secondaries remain up-to-date by using
77+
:doc:`monitoring tools </administration/monitoring>` and by
78+
specifying appropriate :doc:`write concern
79+
</reference/write-concern>`.
8680

87-
- Do not use secondary reads to scale overall read throughput. See:
88-
`Can I use more replica nodes to scale`_ for an overview of read
89-
scaling. For information about secondary reads, see:
90-
:doc:`/core/read-preference`.
81+
- Do not use secondary reads to scale overall read throughput. See:
82+
`Can I use more replica nodes to scale`_ for an overview of read
83+
scaling. For information about secondary reads, see:
84+
:doc:`/core/read-preference`.
9185

92-
.. _Can I use more replica nodes to scale: http://askasya.com/post/canreplicashelpscaling
86+
.. _Can I use more replica nodes to scale: http://askasya.com/post/canreplicashelpscaling
9387

9488
Sharding
9589
~~~~~~~~
9690

97-
.. cssclass:: checklist
98-
99-
- Ensure that your shard key distributes the load evenly on your shards.
100-
See: :doc:`/core/sharding-shard-key` for more information.
101-
102-
- Use :ref:`targeted operations <sharding-mongos-targeted>`
103-
for workloads that need to scale with the number of shards.
104-
105-
- **For MongoDB 3.4 and earlier**, read from the primary nodes for
106-
:ref:`non-targeted or broadcast <sharding-mongos-broadcast>`
107-
queries as these queries may be sensitive to `stale or orphaned
108-
data
109-
<http://blog.mongodb.org/post/74730554385/background-indexing-on-se condaries-and-orphaned>`_.
110-
111-
- | **For MongoDB 3.6 and later**, secondaries no longer return orphaned
112-
data unless using read concern :readconcern:`"available"` (which
113-
is the default read concern for reads against secondaries when not
114-
associated with :ref:`causally consistent sessions <sessions>`).
115-
116-
| Starting in MongoDB 3.6, all members of the shard replica set
117-
maintain chunk metadata, allowing them to filter out orphans
118-
when not using :readconcern:`"available"`. As such,
119-
:ref:`non-targeted or broadcast <sharding-mongos-broadcast>`
120-
queries that are not using :readconcern:`"available"` can be
121-
safely run on any member and will not return orphaned data.
122-
123-
| The :readconcern:`"available"` read concern can return
124-
:term:`orphaned documents <orphaned document>` from secondary
125-
members since it does not check for updated chunk metadata.
126-
However, if the return of orphaned documents is immaterial to an
127-
application, the :readconcern:`"available"` read concern provides
128-
the lowest latency reads possible among the various read concerns.
129-
130-
- :doc:`Pre-split and manually balance chunks
131-
</tutorial/create-chunks-in-sharded-cluster>` when inserting large
132-
data sets into a new non-hashed sharded collection. Pre-splitting
133-
and manually balancing enables the insert load to be distributed
134-
among the shards, increasing performance for the initial load.
91+
- Ensure that your shard key distributes the load evenly on your shards.
92+
See: :doc:`/core/sharding-shard-key` for more information.
93+
94+
- Use :ref:`targeted operations <sharding-mongos-targeted>`
95+
for workloads that need to scale with the number of shards.
96+
97+
- **For MongoDB 3.4 and earlier**, read from the primary nodes for
98+
:ref:`non-targeted or broadcast <sharding-mongos-broadcast>`
99+
queries as these queries may be sensitive to `stale or orphaned
100+
data
101+
<http://blog.mongodb.org/post/74730554385/background-indexing-on-se condaries-and-orphaned>`_.
102+
103+
- | **For MongoDB 3.6 and later**, secondaries no longer return orphaned
104+
data unless using read concern :readconcern:`"available"` (which
105+
is the default read concern for reads against secondaries when not
106+
associated with :ref:`causally consistent sessions <sessions>`).
107+
108+
| Starting in MongoDB 3.6, all members of the shard replica set
109+
maintain chunk metadata, allowing them to filter out orphans
110+
when not using :readconcern:`"available"`. As such,
111+
:ref:`non-targeted or broadcast <sharding-mongos-broadcast>`
112+
queries that are not using :readconcern:`"available"` can be
113+
safely run on any member and will not return orphaned data.
114+
115+
| The :readconcern:`"available"` read concern can return
116+
:term:`orphaned documents <orphaned document>` from secondary
117+
members since it does not check for updated chunk metadata.
118+
However, if the return of orphaned documents is immaterial to an
119+
application, the :readconcern:`"available"` read concern provides
120+
the lowest latency reads possible among the various read concerns.
121+
122+
- :doc:`Pre-split and manually balance chunks
123+
</tutorial/create-chunks-in-sharded-cluster>` when inserting large
124+
data sets into a new non-hashed sharded collection. Pre-splitting
125+
and manually balancing enables the insert load to be distributed
126+
among the shards, increasing performance for the initial load.
135127

136128
Drivers
137129
~~~~~~~
138130

139-
.. cssclass:: checklist
140-
141-
- Make use of connection pooling. Most MongoDB drivers support
142-
connection pooling. Adjust the connection pool size to suit your
143-
use case, beginning at 110-115% of the typical number of concurrent
144-
database requests.
131+
- Make use of connection pooling. Most MongoDB drivers support
132+
connection pooling. Adjust the connection pool size to suit your
133+
use case, beginning at 110-115% of the typical number of concurrent
134+
database requests.
145135

146-
- Ensure that your applications handle transient write and read errors
147-
during replica set elections.
136+
- Ensure that your applications handle transient write and read errors
137+
during replica set elections.
148138

149-
- Ensure that your applications handle failed requests and retry them if
150-
applicable. Drivers **do not** automatically retry failed requests.
139+
- Ensure that your applications handle failed requests and retry them if
140+
applicable. Drivers **do not** automatically retry failed requests.
151141

152-
- Use exponential backoff logic for database request retries.
142+
- Use exponential backoff logic for database request retries.
153143

154-
- Use :method:`cursor.maxTimeMS()` for reads and :ref:`wc-wtimeout` for
155-
writes if you need to cap execution time for database operations.
144+
- Use :method:`cursor.maxTimeMS()` for reads and :ref:`wc-wtimeout` for
145+
writes if you need to cap execution time for database operations.

0 commit comments

Comments
 (0)