[MongoDB – Part 4] Hands-On MongoDB Sharding: Deployment and Configuration

I. INTRODUCTION

• Part 1: Configuring a Standalone MongoDB Instance

• Part 2: Configuring a MongoDB Replica Set

• Part 3: MongoDB Sharding — Architecture and Configuration Principles

II. HANDS-ON IMPLEMENTATION

1. Step-by-Step Guide to Setting Up MongoDB Sharding

• The Config Server manages metadata and data distribution information for the sharded cluster.

• Initialize a Config Server Replica Set, typically consisting of three nodes to ensure high availability.

• Set up Replica Sets to represent individual shards.

• Each Replica Set stores a portion of the cluster's data.

• Deploy at least two Replica Sets to support load distribution.

• Use mongos as the router to direct queries to the appropriate shards.

• Connect mongos to the Config Server.

• Add the shard Replica Sets to the cluster through mongos.

• Enable sharding for the database.

• Shard the collections that require it by selecting an appropriate shard key to optimize performance.

• Monitor and analyze shard utilization to ensure data is distributed evenly.

• Use MongoDB commands such as sh.status() to inspect the sharding status.

2. Dockerizing MongoDB Sharding

Deployment Architecture

• VPS 1:
• Hosts the Config Server and mongos.
• Hosts one Shard Replica Set (shard1).

• VPS 2:
• Hosts one Shard Replica Set (shard2).

Install Docker and Docker Compose on Both VPS Instances

1. Install Docker

sudo apt update
sudo apt install docker.io -y
sudo systemctl start docker
sudo systemctl enable docker

2. Install Docker Compose

sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Sample docker-compose.yml Files for Both VPS Instances

VPS 1: Config Server, mongos, and shard1

version: '3.8'

services:
  configsvr:
    image: mongo:6.0
    container_name: configsvr
    command: --configsvr --replSet configReplSet --bind_ip_all
    ports:
      - "27019:27019"
    volumes:
      - config_data:/data/db

  mongos:
    image: mongo:6.0
    container_name: mongos
    command: >
      mongos --configdb configReplSet/configsvr:27019
    ports:
      - "27017:27017"
    depends_on:
      - configsvr

  shard1-a:
    image: mongo:6.0
    container_name: shard1-a
    command: --shardsvr --replSet shard1 --bind_ip_all
    ports:
      - "27021:27021"
    volumes:
      - shard1_data:/data/db

volumes:
  config_data:
  shard1_data:

VPS 2: shard2

version: '3.8'

services:
  shard2-a:
    image: mongo:6.0
    container_name: shard2-a
    command: --shardsvr --replSet shard2 --bind_ip_all
    ports:
      - "27022:27022"
    volumes:
      - shard2_data:/data/db

volumes:
  shard2_data:

Deployment Steps

1. Start Docker Compose on Both VPS Instances

docker-compose up -d

2. Configure the Replica Sets
• Connect to each container:

docker exec -it <container_name> mongo

• Initialize the Replica Sets for the Config Server, shard1, and shard2 as appropriate.

rs.initiate({
  _id: "configReplSet",
  members: [{ _id: 0, host: "configsvr:27019" }]
})

3. Add Shards to the Cluster
• Connect to mongos:

docker exec -it mongos mongo

• Add the shards:

sh.addShard("shard1/shard1-a:27021")
sh.addShard("shard2/shard2-a:27022")

4. Enable Sharding for the Database

sh.enableSharding("myDatabase")
sh.shardCollection("myDatabase.myCollection", { shardKeyField: 1 })

5. Check the Sharding Status

sh.status()

III. PRACTICAL EXPERIENCE

1. Do You Need an Arbiter Node for MongoDB Sharding?

When Should You Use an Arbiter Node in a Sharded Cluster?

1. A shard's Replica Set has an even number of voting members:
• An arbiter can help establish an odd number of votes, allowing the system to elect a primary when some nodes become unavailable.
• For example, suppose a shard has two nodes, A and B. If one node goes down, the remaining node cannot obtain a majority because 1 out of 2 votes is insufficient. Adding an arbiter, C, creates three votes, allowing the remaining data-bearing node to obtain a majority of 2 out of 3 votes.

2. Limited infrastructure resources:
• An arbiter is a lightweight process that does not store data. This can reduce infrastructure costs, especially in environments where resource optimization is important, such as EC2 micro instances.

3. Distributed infrastructure:
• In deployments spanning multiple data centers or availability zones, an arbiter may help resolve voting outcomes during a network partition.
• For example, with four nodes—two in DC1 and two in DC2—an arbiter could be placed in either location to influence which partition can maintain a voting majority and prevent both sides from independently electing a primary.

When Is an Arbiter Node Unnecessary?

• The Replica Set already has an odd number of voting members:
• An arbiter is generally unnecessary because the Replica Set already has an odd number of votes to support primary elections.

• High-performance requirements:
• An arbiter does not store data. If a data-bearing node becomes unavailable, the cluster may need to elect a new primary before normal writes can resume. Depending on the topology, this can affect applications that require low latency or handle high query volumes.

Considerations When Deploying an Arbiter in a Sharded Cluster

1. Avoid placing the arbiter on the same server as another node in the Replica Set:
• If that server goes down, you could lose both a data-bearing node and the arbiter, potentially losing the voting majority.

2. Do not deploy more than one arbiter per Replica Set:
• An arbiter's role is to participate in voting without storing data. Adding multiple arbiters is generally unnecessary and may complicate the configuration.

3. Consider the arbiter's placement during network partitions:
• An arbiter should be placed where it can reliably communicate with the relevant members and where its placement supports the intended failure-domain strategy.

Takeaways

• An arbiter can be useful in certain Replica Set configurations, particularly when infrastructure resources are limited.

• In a sharded cluster, whether an arbiter is appropriate depends on each shard's voting configuration and failure-tolerance requirements.

• However, arbiters should not be used indiscriminately. Their placement and role must be carefully considered to avoid losing a voting majority or introducing configuration issues.

2. Shard Key Selection Strategies

1. Low-Cardinality Shard Key

• Advantages: Easy to understand and implement initially. For example, you could divide shards by geographical regions using ranges such as:
• (-∞, "Antarctica")
• ["Antarctica", "Asia")
• ["Asia", "Australia")
• ...

• Disadvantages: If one shard contains significantly more data than others—for example, because Asia generates much more data—the system may struggle to distribute the workload evenly. Adding another field, such as a combination of continent and country, may improve distribution, but this approach may not be optimal in the long run.

2. Ascending Shard Key

• Advantages:
• Works well for applications that frequently access recent data, such as logs or transaction histories.
• Recent data can be easy to locate when it is stored in the shard responsible for the latest key range.

• Disadvantages:
• New data is continually written to the shard responsible for the highest key values, causing that shard's data range to split repeatedly.
• This can create a significant write hotspot and lead to severe load imbalance, particularly in write-intensive systems.

3. Random Shard Key

• Advantages:
• Can distribute data more evenly across shards from the outset.
• Helps prevent data from becoming concentrated on a small number of shards.

• Disadvantages:
• Random distribution can make queries less efficient when they cannot target a shard using the shard key or an appropriate index.
• During rebalancing, MongoDB may need to migrate chunks across shards, consuming additional time and resources.

4. A Good Shard Key

• Ascending key: Use time-based values, such as date/time, to divide data into appropriate ranges.

• Search key: Combine the time-based field with another field, such as user or category, to improve data distribution and support query patterns.

1. Initially, the shard key is {month, user}, with a single chunk covering the entire key space:
• (-∞, ∞)

2. As data grows, the chunk may split into smaller ranges, such as:
• ((-∞, -∞), ("2011-04", "susan"))
• [("2011-04", "susan"), (∞, ∞)]

3. When a new month begins, data from the previous month may be stored on a less heavily utilized shard, helping reduce the load on the primary shards handling new data.

• Distributes data based on both time and the associated entity.

• Older data does not necessarily need to be redistributed, potentially reducing unnecessary chunk migrations.

Summary

• Low-cardinality shard key: Suitable for smaller systems with relatively stable workloads, provided the selected key can support sufficient data distribution.

• Ascending shard key: Useful for accessing recent data, but requires careful design to avoid creating a write hotspot on the shard handling the highest key values.

• Random shard key: Can improve distribution, but query targeting and rebalancing costs must be considered.

• Good shard key: A carefully designed combination of time-based and query-oriented fields can help balance data distribution and long-term query performance.

IV. CONCLUSION

V. REFERENCES

• https://bigsonata.wordpress.com/2014/06/05/mongodb/

• https://www.openmymind.net/Does-My-Replica-Set-Need-An-Arbiter/

• https://climbtheladder.com/10-mongodb-sharding-best-practices/