This topic describes how to create a multi-zone sharded cluster instance. ApsaraDB for MongoDB provides a zone-disaster recovery solution to ensure the reliability and availability of your sharded cluster instance. This solution deploys the components of a sharded cluster instance across three different zones within the same region. These components exchange data with each other over an internal network. If one of the zones becomes unavailable due to force majeure factors such as a power or network failure, the high availability (HA) system automatically switches services over to another zone.

Prerequisites

An Alibaba Cloud account is created. For more information, see Sign up with Alibaba Cloud.

Precautions

  • Sharded cluster instances that run MongoDB 4.4 or later cannot be deployed across multiple zones.
  • If your application is deployed on an Elastic Compute Service (ECS) instance, make sure that your ApsaraDB for MongoDB instance and ECS instance meet the following requirements to ensure network connectivity: For more information about how to view ECS instance information, see View instance information.
    • Your ApsaraDB for MongoDB instance and ECS instance are deployed in the same region, and preferably belong to the same zone. This reduces network latency.
    • Your ApsaraDB for MongoDB instance and ECS instance use the same network type.
      Note
      • VPC is recommended because VPC provides higher security.
      • If the network type is VPC, you must ensure that they use the same VPC ID.
      • If you want to use VPC, but the network type of the ECS instance is classic network, you can change the network type of the ECS instance to VPC. For more information, see Migrate ECS instances from the classic network to a VPC.

Limits

Sharded cluster instances that run MongoDB 4.2 or earlier can be created only in the following zones for multi-zone deployment:
  • China (Shenzhen): Shenzhen Zones (C + D + E).
  • China (Hong Kong): Hongkong Zones (B + C + D).
  • Singapore: Singapore Zones (A + B + C).

Node deployment policies

The following node deployment policies are available for sharded cluster instances:
  • Single-zone deployment: Mongos, shard, and Configserver nodes of a sharded cluster instance are deployed within one zone.
  • Multi-zone deployment: Mongos, shard, and Configserver nodes of a sharded cluster instance are deployed across three different zones.
    • Mongos nodes: Mongos nodes are evenly deployed across all data centers. The sharded cluster instance must contain at least two mongos nodes that are deployed across two different zones. When you add a third mongos node, the node is deployed in the third zone by default. Subsequent nodes to be added are deployed across the three zones in turn.
    • Shard nodes: The primary, secondary, and hidden nodes of a shard node are not deployed in the three zones in sequence. Node zones may change due to manual primary/secondary switchover or automatic HA switchover.
    • Configserver nodes: The primary, secondary, and hidden nodes of a Configserver node are deployed across the three different zones.
Figure 1. Deployment policy for the component nodes in a multi-zone sharded cluster instance

Procedure

  1. Log on to the ApsaraDB for MongoDB console.
  2. In the upper-left corner of the page, select the resource group and region to which the instance belongs.
  3. In the left-side navigation pane, click Sharded Cluster Instances.
  4. On the Sharded Cluster Instances page, click Create Instance.
  5. Set Product Type to Sharded Cluster (Subscription) or Sharded Cluster (Pay-as-you-go).
  6. Set Region.

    You can set Region to China (Shenzhen), China (Hong Kong), or Singapore.

  7. Set Zone.

    You can set Zone to Shenzhen Zones (C + D + E), Hongkong Zones (B + C+ D), or Singapore Zones (A + B + C).

  8. Configure other parameters and purchase the instance. For more information, see Create a sharded cluster instance.

Additional information

You can use the service availability feature to view the deployment of nodes in a sharded cluster instance across zones. You can also switch the node roles of the instance based on your business deployment. This way, your applications can connect to the closest nodes. For more information, see Switch node roles.