|
1 | 1 | ---
|
2 |
| -page_title: "Migration Guide: Advanced Cluster New Sharding Schema" |
| 2 | +page_title: "Migration Guide: Advanced Cluster New Sharding Configurations" |
3 | 3 | ---
|
4 | 4 |
|
5 |
| -# Migration Guide: Advanced Cluster New Sharding Schema |
| 5 | +# Migration Guide: Advanced Cluster New Sharding Configurations |
6 | 6 |
|
7 |
| -**Objective**: Use this guide to migrate your existing `advanced_cluster` configurations to the new sharding schema introduced in version 1.18.0. The new sharding schema allows you to scale shards independently. Existing sharding configurations continue to work, although the software issues deprecation messages if you use the legacy schema. |
| 7 | +**Objective**: Use this guide to migrate your existing `advanced_cluster` resources to support new sharding configurations introduced in version 1.18.0. The new sharding configurations allow you to scale shards independently. Existing sharding configurations continue to work, but you will receive deprecation messages if you continue to use them. |
8 | 8 |
|
9 |
| -- [Migration Guide: Advanced Cluster New Sharding Schema](#migration-guide-advanced-cluster-new-sharding-schema) |
10 |
| - - [Overview of schema changes](#overview-of-schema-changes) |
| 9 | +- [Migration Guide: Advanced Cluster New Sharding Configurations](#migration-guide-advanced-cluster-new-sharding-schema) |
| 10 | + - [Changes Overview](#changes-overview) |
11 | 11 | - [Migrate advanced\_cluster type `SHARDED`](#migrate-advanced_cluster-type-sharded)
|
12 | 12 | - [Migrate advanced\_cluster type `GEOSHARDED`](#migrate-advanced_cluster-type-geosharded)
|
13 | 13 | - [Migrate advanced\_cluster type `REPLICASET`](#migrate-advanced_cluster-type-replicaset)
|
14 | 14 | - [Use Independent Shard Scaling](#use-independent-shard-scaling)
|
15 | 15 |
|
16 | 16 | <a id="overview"></a>
|
17 |
| -## Overview of schema changes |
| 17 | +## Changes Overview |
18 | 18 |
|
19 | 19 | `replication_specs` attribute now represents each individual cluster's shard with a unique replication spec element.
|
20 |
| -When you use the new sharding schema, the schema no longer uses the existing attribute `num_shards`, and instead the number of shards are defined by the number of `replication_specs` elements. |
| 20 | +When you use the new sharding configurations, it will no longer use the existing attribute `num_shards`, and instead the number of shards are defined by the number of `replication_specs` elements. |
21 | 21 |
|
22 | 22 | <a id="migration-sharded"></a>
|
23 | 23 | ### Migrate advanced_cluster type `SHARDED`
|
@@ -46,7 +46,7 @@ resource "mongodbatlas_advanced_cluster" "test" {
|
46 | 46 | }
|
47 | 47 | ```
|
48 | 48 |
|
49 |
| -In order to update our configuration to the new schema, we will remove the use of `num_shards` and add a new identical `replication_specs` element for each shard. Note that these 2 changes must be done at the same time. |
| 49 | +In order to use our new sharding configurations, we will remove the use of `num_shards` and add a new identical `replication_specs` element for each shard. Note that these 2 changes must be done at the same time. |
50 | 50 |
|
51 | 51 | ```
|
52 | 52 | resource "mongodbatlas_advanced_cluster" "test" {
|
@@ -128,7 +128,7 @@ resource "mongodbatlas_advanced_cluster" "test" {
|
128 | 128 | }
|
129 | 129 | ```
|
130 | 130 |
|
131 |
| -In order to update our configuration to the new schema, we will remove the use of `num_shards` and add a new identical `replication_specs` element for each shard. Note that these two changes must be done at the same time. |
| 131 | +In order to use our new sharding configurations, we will remove the use of `num_shards` and add a new identical `replication_specs` element for each shard. Note that these two changes must be done at the same time. |
132 | 132 |
|
133 | 133 | ```
|
134 | 134 | resource "mongodbatlas_advanced_cluster" "test" {
|
@@ -244,7 +244,7 @@ resource "mongodbatlas_advanced_cluster" "test" {
|
244 | 244 | }
|
245 | 245 | ```
|
246 | 246 |
|
247 |
| -Once the cluster type is adjusted accordingly, we can proceed to add a new shard using the new schema: |
| 247 | +Once the cluster type is adjusted accordingly, we can proceed to add a new shard: |
248 | 248 |
|
249 | 249 | ```
|
250 | 250 | resource "mongodbatlas_advanced_cluster" "test" {
|
@@ -283,7 +283,7 @@ Note: The first time `terraform apply` command is run **after** updating the con
|
283 | 283 | <a id="use-iss"></a>
|
284 | 284 | ### Use Independent Shard Scaling
|
285 | 285 |
|
286 |
| -Use the new sharding schema. Each shard must be represented with a unique replication_specs element and `num_shards` must not be used, as illustrated in the following example. |
| 286 | +Use the new sharding configurations. Each shard must be represented with a unique `replication_specs` element and `num_shards` must not be used, as illustrated in the following example. |
287 | 287 |
|
288 | 288 | ```
|
289 | 289 | resource "mongodbatlas_advanced_cluster" "test" {
|
@@ -353,4 +353,4 @@ resource "mongodbatlas_advanced_cluster" "test" {
|
353 | 353 | }
|
354 | 354 | ```
|
355 | 355 |
|
356 |
| --> **NOTE:** For any cluster leveraging the new schema and defining independently scaled shards, users should also update corresponding `mongodbatlas_cloud_backup_schedule` resource & data sources. This involves updating any existing Terraform configurations of the resource to use `copy_settings.#.zone_id` instead of `copy_settings.#.replication_spec_id`. This is needed as `mongodbatlas_advanced_cluster` resource and data source will no longer have `replication_specs.#.id` present when shards are scaled independently. To learn more, review the [1.18.0 Migration Guide](1.18.0-upgrade-guide.md#transition-cloud-backup-schedules-for-clusters-to-use-zones). |
| 356 | +-> **NOTE:** For any cluster leveraging the new sharding configurations and defining independently scaled shards, users should also update corresponding `mongodbatlas_cloud_backup_schedule` resource & data sources. This involves updating any existing Terraform configurations of the resource to use `copy_settings.#.zone_id` instead of `copy_settings.#.replication_spec_id`. This is needed as `mongodbatlas_advanced_cluster` resource and data source will no longer have `replication_specs.#.id` present when shards are scaled independently. To learn more, review the [1.18.0 Migration Guide](1.18.0-upgrade-guide.md#transition-cloud-backup-schedules-for-clusters-to-use-zones). |
0 commit comments