Sharding and zones

MongoDB shard keys, zones and the operations on chunks, applied to TeselaDB ranges.

In TeselaDB you do not need a shard key: each collection is split into ranges by size and load. If your application already uses shard keys or zones, the MongoDB commands work the same.

Requirements

A running cluster and a user with the privileges of the sharding commands.
For zones, the shard name of each node, which listShards shows.

Shard key

JavaScript

sh.shardCollection("shop.orders", { customer: 1, _id: 1 });

shardCollection, with a ranged shard key, a hashed one or a compound one, reorders the collection so each document is stored by its shard key. reshardCollection and refineCollectionShardKey change it online.

Uniqueness

_id is unique across the whole cluster and a unique index does not need the shard key as a prefix. In MongoDB it is only unique within each shard.

Zones

A zone restricts the replicas of some shard key intervals to some nodes, for example to keep the data of European customers on EU machines. The shard name of each node is the one listShards shows:

JavaScript

sh.addShardToZone("<shard>", "eu");
sh.updateZoneKeyRange("shop.orders", { region: "eu" }, { region: "eu~" }, "eu");

Chunks and balancer

split, moveChunk, mergeChunks, balancerStart, balancerStop and the config database (config.chunks, config.shards) have MongoDB's shape. Each node appears as a shard in listShards.

Check

In mongosh, db.adminCommand({ listShards: 1 }) returns one shard for each node of the cluster, with the zones you assigned to each one.

Common problems

addShardToZone cannot find the shard because the name is not the one listShards returns for that node.