You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
:ref:`Auto-scaling <cluster-autoscaling>` allows you to dynamically allocate resources based on
25
-
growing workload demands. This feature ensures that you only pay for the resources you use. By
26
-
configuring auto-scaling within predefined limits, you can effectively manage fluctuations in data
27
-
processing needs, maintain optimal performance, and achieve cost efficiency. {+service+}
28
-
offers cluster auto-scaling for all tiers except for the highest tier. Auto-scaling enables
29
-
clusters to automatically adjust their tier, storage capacity, or both in response to real-time
30
-
use. {+service+} analyzes the CPU and memory utilization to determine when and whether to scale
31
-
the cluster tier up and down. You can also specify a range of maximum and minimum cluster sizes
32
-
that their cluster can automatically scale to. {+service+} won't scale a cluster if the new
33
-
tier falls outside of your specified size range or if memory usage would exceed the capacity of
34
-
the new tier.
35
-
36
-
Auto-scaling is throttled with a delay to scale a cluster tier up or down. As such, it is ideal
37
-
for a steadily growing or declining application load, not sudden spikes where the database is
38
-
inundated with use. If your workload is spikey or you are expecting a large increase in traffic
39
-
because of an event or launch, we recommend you pre-scale using a script.
40
-
41
-
{+service+} deployment templates provide you with horizontal and vertical scaling options. Upgrading
42
-
an {+service+} cluster to the next available {+service+} tier is available through the {+service+}
43
-
control plane GUI or the
21
+
Auto-scaling enables clusters to automatically adjust their tier, storage capacity, or both, in
22
+
response to real-time use. {+service+} analyzes the CPU and memory utilization to determine when
23
+
and whether to scale the cluster tier up and down. See :ref:`Cluster tier scaling <cluster-autoscaling>`
24
+
to learn more about the conditions under which {+service+} scales up or down your cluster nodes. You can
25
+
also specify a range of maximum and minimum cluster sizes that your cluster can automatically scale
26
+
to. {+service+} won't scale a cluster if the new tier falls outside of your specified size range or
27
+
if your memory usage would exceed the capacity of the new tier. Auto-scaling is throttled with a delay
28
+
to scale a cluster tier up or down. Therefore, it is best suited for a steadily growing or declining
29
+
application load, not sudden spikes in which the database is being inundated with usage. If your
30
+
workload experiences frequent spikes or if you are expecting a large increase in traffic because of an
31
+
event or a launch, MongoDB recommends that you pre-scale programmatically.
32
+
33
+
{+service+} deployment templates, as referenced in the :ref:`Recommended Deployment Topologies <arch-center-deployment-topologies>`,
34
+
provide you with horizontal and vertical scaling options. Specifically, sharding distributes data across
35
+
numerous machines, which is useful when no single server can handle your workloads. Sharding follows a
36
+
shared-nothing architecture, a distributed computing architecture where none of the nodes share any
37
+
resources with each other. See :ref:`Choose a Shard Key <sharding-choose-a-shard-key>` to learn more
38
+
about the ideal choice of shard key that allows MongoDB to distribute documents evenly throughout your cluster
39
+
while faciliating common query patterns. Furthermore, see `Performance Best Practices: Sharding <https://www.mongodb.com/blog/post/performance-best-practices-sharding>`__
40
+
to learn about the key sharding strategies, such as ranged sharding, hashed sharding, and zoned sharding.
41
+
42
+
Upgrading an {+service+} cluster to the next available {+service+} tier is available through the
43
+
{+service+} control plane GUI or the
44
44
`Atlas Administration API <https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/operation/upgradeSharedCluster>`__.
45
-
Changing an {+service+} tier, either upscaling or downscaling, is performed in a
46
-
rolling fashion and allows zero downtime. Horizontal scaling occurs manually post-deployment. Some
47
-
cluster templates require sharded clusters. Starting with MongoDB version 8.0, you may make use of
48
-
:manual:`embedded config servers </reference/command/transitionFromDedicatedConfigServer>` to reduce
45
+
Changing an {+service+} tier, either upscaling or downscaling, allows zero downtime, and is performed
46
+
in a rolling fashion, which involves electing a secondary member as a replacement, promoting this secondary
47
+
member to become the new primary, then restoring or replacing the failing member
48
+
to ensure that the cluster is returned to its target configuration as soon as possible. Horizontal
49
+
scaling occurs post-deployment based on Administrator action, which can be triggered from a programmatic
50
+
script. Some cluster templates require sharded clusters. Starting with MongoDB version 8.0, you may make
51
+
use of :manual:`embedded config servers </reference/command/transitionFromDedicatedConfigServer>` to reduce
49
52
costs associated with config servers on small sharded clusters.
50
53
51
54
The low CPU option in {+service+} helps applications that require higher memory but not as much
@@ -55,7 +58,8 @@ the same cluster size, reducing costs for workloads that are memory-intensive bu
55
58
Data tiering and archival allows you to archive data at low-cost storage while still enabling
56
59
queries alongside live cluster data, which is particularly useful for long-term record retention.
57
60
To optimize this process, MongoDB recommends that you automate data archiving with simple, configurable
58
-
rules. Also, for scenarios where data retention is not a priority, {+service+} offers the option to
61
+
rules. See :ref:`Archive Data <manage-online-archive>` to learn more about the criteria that you can specify
62
+
in an archiving rule. For scenarios where data retention is not a priority, {+service+} offers the option to
59
63
automatically delete unused data based on date criteria. For infrequently accessed data, :manual:`TTL indexes <core/index-ttl/>`
60
64
are special single-field indexes that automatically delete documents from a collection after a specified
61
65
period or at a set clock time. This is particularly useful for data like logs, session information,
@@ -69,10 +73,6 @@ consumption by following actionable recommendations to enhance your query perfor
69
73
you can leverage intelligent index recommendations provided by {+service+} to further improve data
70
74
retrieval efficiency and minimize the resources needed for database operations.
71
75
72
-
The {+service+} CLI also helps you manage both local and cloud environments efficiently, automating
73
-
tasks and scaling resources as needed. This setup enables testing and development locally, minimizing
74
-
unnecessary cloud usage.
75
-
76
76
Recommendations
77
77
~~~~~~~~~~~~~~~
78
78
@@ -82,10 +82,6 @@ non-production environments.
82
82
83
83
For staging and production environments, we recommend that you:
84
84
85
-
- Always deploy with a
86
-
router-based, single-shard cluster. This future-proofs your cluster
87
-
and minimizes disruptions in the event that you need to horizontally
88
-
scale by sharding collections in the future with application load growth.
89
85
- Enable auto-scaling for compute and storage for instances where your
90
86
application grows organically from small to medium.
0 commit comments