Merge pull request #260516 from khelanmodi/node-to-shard

Updated docs to say Shards instead of Nodes

Author: v-regandowner

articles/cosmos-db/mongodb/migrate-databricks.md

@@ -12,7 +12,7 @@ ms.date: 08/26/2021
 # Migrate data from MongoDB to an Azure Cosmos DB for MongoDB account by using Azure Databricks
 [!INCLUDE[MongoDB](../includes/appliesto-mongodb.md)]
 
-This migration guide is part of series on migrating databases from MongoDB to Azure CosmosDB API for MongoDB. The critical migration steps are [pre-migration](pre-migration-steps.md), migration, and [post-migration](post-migration-optimization.md), as shown below.
+This migration guide is part of series on migrating databases from MongoDB to Azure Cosmos DB API for MongoDB. The critical migration steps are [pre-migration](pre-migration-steps.md), migration, and [post-migration](post-migration-optimization.md), as shown below.
 
 :::image type="content" source="./media/pre-migration-steps/overall-migration-steps.png" alt-text="Diagram of migration steps":::
 
@@ -132,7 +132,7 @@ df.write.format("mongo").mode("append").option("uri", targetConnectionString).op
 
 The migration performance can be adjusted through these configurations:
 
-- **Number of workers and cores in the Spark cluster**: More workers mean more compute nodes to execute tasks.
+- **Number of workers and cores in the Spark cluster**: More workers mean more compute shards to execute tasks.
 
 - **maxBatchSize**: The `maxBatchSize` value controls the rate at which data is saved to the target Azure Cosmos DB collection. However, if the maxBatchSize is too high for the collection throughput, it can cause [rate limiting](prevent-rate-limiting-errors.md) errors.
 

articles/cosmos-db/mongodb/quickstart-dotnet.md

@@ -105,7 +105,7 @@ dotnet add package MongoDb.Driver
 Before you start building the application, let's look into the hierarchy of resources in Azure Cosmos DB. Azure Cosmos DB has a specific object model used to create and access resources. The Azure Cosmos DB creates resources in a hierarchy that consists of accounts, databases, collections, and docs.
 
 :::image type="complex" source="media/quickstart-dotnet/resource-hierarchy.png" alt-text="Diagram of the Azure Cosmos DB hierarchy including accounts, databases, collections, and docs.":::
-    Hierarchical diagram showing an Azure Cosmos DB account at the top. The account has two child database nodes. One of the database nodes includes two child collection nodes. The other database node includes a single child collection node. That single collection node has three child doc nodes.
+    Hierarchical diagram showing an Azure Cosmos DB account at the top. The account has two child database shards. One of the database shards includes two child collection shards. The other database shard includes a single child collection shard. That single collection shard has three child doc shards.
 :::image-end:::
 
 You'll use the following MongoDB classes to interact with these resources:

articles/cosmos-db/mongodb/quickstart-nodejs.md

@@ -105,7 +105,7 @@ npm install mongodb dotenv
 Before you start building the application, let's look into the hierarchy of resources in Azure Cosmos DB. Azure Cosmos DB has a specific object model used to create and access resources. The Azure Cosmos DB creates resources in a hierarchy that consists of accounts, databases, collections, and docs.
 
 :::image type="complex" source="media/quickstart-nodejs/resource-hierarchy.png" alt-text="Diagram of the Azure Cosmos DB hierarchy including accounts, databases, collections, and docs.":::
-    Hierarchical diagram showing an Azure Cosmos DB account at the top. The account has two child database nodes. One of the database nodes includes two child collection nodes. The other database node includes a single child collection node. That single collection node has three child doc nodes.
+    Hierarchical diagram showing an Azure Cosmos DB account at the top. The account has two child database shards. One of the database shards includes two child collection shards. The other database shard includes a single child collection node. That single collection shard has three child doc shards.
 :::image-end:::
 
 You'll use the following MongoDB classes to interact with these resources:

articles/cosmos-db/mongodb/quickstart-python.md

@@ -126,7 +126,7 @@ This quickstart will create a single Azure Cosmos DB account using the API for M
 Let's look at the hierarchy of resources in the API for MongoDB and the object model that's used to create and access these resources. The Azure Cosmos DB creates resources in a hierarchy that consists of accounts, databases, collections, and documents.
 
 :::image type="complex" source="media/quickstart-nodejs/resource-hierarchy.png" alt-text="Diagram of the Azure Cosmos DB hierarchy including accounts, databases, collections, and docs.":::
-    Hierarchical diagram showing an Azure Cosmos DB account at the top. The account has two child database nodes. One of the database nodes includes two child collection nodes. The other database node includes a single child collection node. That single collection node has three child doc nodes.
+    Hierarchical diagram showing an Azure Cosmos DB account at the top. The account has two child database shards. One of the database shards includes two child collection shards. The other database shard includes a single child collection shard. That single collection shard has three child doc shards.
 :::image-end:::
 
 Each type of resource is represented by a Python class. Here are the most common classes:

articles/cosmos-db/mongodb/vcore/failover-disaster-recovery.md

@@ -39,13 +39,13 @@ Automatic backups are retained in various intervals based on whether the cluster
 
 ## Design for high availability
 
-High availability (HA) should be enabled for critical Azure Cosmos DB for MongoDB vCore clusters running production workloads. In an HA-enabled cluster, each node serves as a primary along with a hot-standby node provisioned in another availability zone. Replication between the primary and the secondary node is synchronous by default. Any modification to the database is persisted on both the primary and the secondary (hot-standby) nodes before a response from the database is received.
+High availability (HA) should be enabled for critical Azure Cosmos DB for MongoDB vCore clusters running production workloads. In an HA-enabled cluster, each shard serves as a primary along with a hot-standby shard provisioned in another availability zone. Replication between the primary and the secondary shard is synchronous by default. Any modification to the database is persisted on both the primary and the secondary (hot-standby) shards before a response from the database is received.
 
-The service maintains health checks and heartbeats to each primary and secondary node of the cluster. If a primary node becomes unavailable due to a zone or regional outage, the secondary node is automatically promoted to become the new primary and a subsequent secondary node is built for the new primary. In addition, if a secondary node becomes unavailable, the service auto creates a new secondary node with a full copy of data from the primary.
+The service maintains health checks and heartbeats to each primary and secondary shard of the cluster. If a primary shard becomes unavailable due to a zone or regional outage, the secondary shard is automatically promoted to become the new primary and a subsequent secondary shard is built for the new primary. In addition, if a secondary shard becomes unavailable, the service auto creates a new secondary shard with a full copy of data from the primary.
 
-If the service triggers a failover from the primary to the secondary node, connections are seamlessly routed under the covers to the new primary node.
+If the service triggers a failover from the primary to the secondary shard, connections are seamlessly routed under the covers to the new primary shard.
 
-Synchronous replication between the primary and secondary nodes guarantees no data loss if there's a failover.
+Synchronous replication between the primary and secondary shards guarantees no data loss if there's a failover.
 
 ### Configure high availability
 

articles/cosmos-db/mongodb/vcore/high-availability.md

@@ -15,15 +15,15 @@ ms.date: 08/28/2023
 
 [!INCLUDE[MongoDB vCore](../../includes/appliesto-mongodb-vcore.md)]
 
-High availability (HA) avoids database downtime by maintaining standby replicas of every node in a cluster. If a node goes down, Azure Cosmos DB for MongoDB vCore switches incoming connections from the failed node to its standby replica.
+High availability (HA) avoids database downtime by maintaining standby replicas of every shard in a cluster. If a shard goes down, Azure Cosmos DB for MongoDB vCore switches incoming connections from the failed shard to its standby replica.
 
 ## How it works
 
-When HA is enabled, Azure Cosmos DB for MongoDB vCore runs one replica node for each primary node in the cluster. The primary and its replica use synchronous replication. The service detects failures on primary nodes and fails over to the replica nodes with zero data loss. The MongoDB connection string remains the same.
+When HA is enabled, Azure Cosmos DB for MongoDB vCore runs one replica shard for each primary shard in the cluster. The primary and its replica use synchronous replication. The service detects failures on primary shards and fails over to the replica shards with zero data loss. The MongoDB connection string remains the same.
 
-When HA is enabled, HA replica nodes are provisioned in a different availability zone from their primary nodes, if the region supports multiple zones and has available capacity. HA replicas don't receive requests from clients unless their primary node fails.
+When HA is enabled, HA replica shards are provisioned in a different availability zone from their primary shards, if the region supports multiple zones and has available capacity. HA replicas don't receive requests from clients unless their primary shard fails.
 
-Even without HA enabled, each node has its own locally redundant storage (LRS) with three synchronous replicas maintained by Azure Storage service. If there's a single replica failure, the Azure Storage service detects the failure, and transparently re-creates the relevant data. For LRS storage durability, see metrics on [this page](../../../storage/common/storage-redundancy.md#summary-of-redundancy-options).
+Even without HA enabled, each shard has its own locally redundant storage (LRS) with three synchronous replicas maintained by Azure Storage service. If there's a single replica failure, the Azure Storage service detects the failure, and transparently re-creates the relevant data. For LRS storage durability, see metrics on [this page](../../../storage/common/storage-redundancy.md#summary-of-redundancy-options).
 
 ## Configure high availability
 

articles/cosmos-db/mongodb/vcore/how-to-scale-cluster.md

@@ -57,7 +57,7 @@ You can increase the storage size to give your database more room to grow. For e
 
 1. To increase the storage size, select the new size from the drop-down menu.
 
-   :::image type="content" source="media/how-to-scale-cluster/configure-storage.png" alt-text="Screenshot of the storage per node option in the Scale page of a cluster.":::
+   :::image type="content" source="media/how-to-scale-cluster/configure-storage.png" alt-text="Screenshot of the storage per shard option in the Scale page of a cluster.":::
 
     > [!NOTE]
     > This change is performed live to the cluster without downtime. Also, storage size can only be increased, not decreased.
@@ -66,7 +66,7 @@ You can increase the storage size to give your database more room to grow. For e
 
 ## Enable or disable high availability
 
-You can enable or disable high availability (HA) to suit your needs. HA avoids database downtime by maintaining replica nodes of every primary node in a cluster. If a primary node goes down, incoming connections are automatically redirected to its replica node, ensuring that there's minimal downtime.
+You can enable or disable high availability (HA) to suit your needs. HA avoids database downtime by maintaining replica shards of every primary shard in a cluster. If a primary shard goes down, incoming connections are automatically redirected to its replica shard, ensuring that there's minimal downtime.
 
 1. To enable or disable HA, toggle the checkbox option.
 

articles/cosmos-db/mongodb/vcore/media/quickstart-portal/configure-scale.png

@@ -53,7 +53,7 @@ resource cluster 'Microsoft.DocumentDB/mongoClusters@2022-10-15-preview' = {
     nodeGroupSpecs: [
         {
             kind: 'Shard'
-            nodeCount: 1
+            shardCount: 1
             sku: 'M40'
             diskSizeGB: 128
             enableHa: false
@@ -71,6 +71,8 @@ resource firewallRules 'Microsoft.DocumentDB/mongoClusters/firewallRules@2022-10
   }
 }
 ```
+> [!NOTE]
+> Kindly note that in the above code, shardGroupSpecs is called nodeGroupSpecs. 
 
 Two Azure resources are defined in the Bicep file:
 

articles/cosmos-db/mongodb/vcore/quickstart-bicep.md

@@ -51,9 +51,9 @@ Create a MongoDB cluster by using Azure Cosmos DB for MongoDB vCore.
 
     | Setting | Value |
     | --- | --- |
-    | **Node count** | Single node |
+    | **Shard count** | Single shard |
     | **Cluster tier** | M30 Tier, 2 vCores, 8-GiB RAM |
-    | **Storage per node** | 128 GiB |
+    | **Storage per shard** | 128 GiB |
 
 1. Leave the **High availability** option unselected. In the high availability (HA) acknowledgment section, select **I understand**. Finally, select **Save** to persist your changes to the cluster tier.