MongoDB collections, clusters and replica sets explained

Anyone starting with MongoDB runs into three words that sound like synonyms: collection, cluster and replica set. They live at different levels. One describes how your data is organized, another describes how it is copied between servers, and the third is a nickname for the whole thing.

Knowing the difference prevents practical mistakes: writing the wrong connection string, expecting a secondary to always have the latest data, or thinking you need sharding when all you needed was one more copy. If you are new to the database itself, start with What is MongoDB.

What is a collection in MongoDB?#

MongoDB stores data in documents (BSON format, similar to JSON). Documents live in collections, and collections live in a database. In SQL terms, a collection is a table and a document is a row, with one important difference: by default, documents in the same collection do not need to have the same fields.

use shop
db.customers.insertMany([
  { name: "Ada", age: 36 },
  { name: "Linus", languages: ["C", "Rust"] },
  { title: "No name", tags: [] }
])

The three documents above live side by side in the customers collection. That gives you freedom early in a project, but it also lets malformed data slip in.

Does a collection have to be created first?#

No. MongoDB creates the database and the collection on the first write. insertOne creates the collection if it does not exist, and so does createIndex. This implicit creation uses the default options.

When you want to set options up front, create it explicitly with createCollection. A common use is schema validation:

db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "email"],
      properties: {
        name: { bsonType: "string" },
        email: { bsonType: "string", pattern: "^.+@.+$" }
      }
    }
  }
})

To change the options later, use the collMod command. Validation can reject the write (validationAction: "error") or only log a warning ("warn"). If your data has a stable shape, it pays to turn validation on early.

What is a replica set?#

A replica set is a group of mongod processes that maintain the same data set. Each process belongs to exactly one replica set. The roles are:

• Primary: receives all writes.
• Secondaries: hold copies of the data and apply the primary's changes asynchronously.
• Arbiter: votes in elections but stores no data. It exists for when cost rules out a third full server, and it adds no data redundancy.

The primary records every change in the oplog (operation log), and the secondaries read that log to stay in sync with it. Because copying is asynchronous, a secondary can be a few moments behind.

How many members, and why?#

The documentation recommends at least three members. The recommended layout is primary, secondary, secondary (P-S-S), with three full copies of the data. The cheaper alternative is primary, secondary, arbiter (P-S-A): the arbiter only votes, so there is a single spare copy and fault tolerance is lower.

The reason for three is voting. With three voters, a majority is two. If one server goes down, the other two still form a majority and keep working. With two voters, losing one leaves the other alone, without a majority.

What happens when the primary goes down?#

If the primary stops communicating with the rest of the set for longer than electionTimeoutMillis (10 seconds by default), an eligible secondary calls an election. With default settings, the median time to elect a new primary typically does not exceed 12 seconds, including failure detection.

During that window there is no primary, so writes fail or wait. Current drivers automatically retry certain writes once (retryable writes), which hides part of the problem from your application. Lowering electionTimeoutMillis detects failures faster, but can trigger needless elections during network latency spikes.

How does a replica set affect reads and writes?#

By default, the client reads from the primary. You can read from secondaries with readPreference, accepting that the data may lag because of asynchronous replication. Transactions that read data must use primary.

For important writes, use w: "majority". The write is only acknowledged after it has replicated to a majority of voting members, so it survives a primary switch. With w: 1, a write acknowledged only by the primary can be rolled back if the primary fails before replicating.

What is a cluster in MongoDB?#

"Cluster" is not a component with a single definition. It is the word for the set of servers behind your database, and its meaning depends on context:

• Cluster as a replica set. On many hosted database services, "create a cluster" gives you a replica set. This is the most common case.
• Sharded cluster. In the MongoDB manual, the term refers to the sharding architecture: several shards (each should be a replica set), mongos routers that accept client connections, and config servers that store the metadata.

In short: every shard is a replica set, but not every replica set is a sharded cluster.

When does sharding make sense?#

Sharding splits a collection into pieces (chunks) across several shards, and a balancer moves those pieces around to even out the load. It addresses two limits of vertical scaling (a bigger server): a CPU saturated by too many queries, and data larger than RAM.

The cost is operational complexity. The shard key needs care: you can reshard a collection (since MongoDB 5.0), but the process is slow and resource-heavy. Queries without the shard key are sent to every shard. Before going there, exhaust better indexes, leaner queries and more RAM. Sharding does not replace replication: high availability still comes from the replica set, since each shard is one.

How does a replica set show up in the connection string?#

In the connection string you list the members and give the set's name, so the driver can find out which one is the primary:

mongodb://user:password@host1:27017,host2:27017,host3:27017/shop?replicaSet=rs0&w=majority

The mongodb+srv:// format discovers the server list through a DNS lookup, so you give a single host name, and it enables TLS by default. Special characters in the username or password (such as $ : / ? # [ ] @) must be percent-encoded: @ becomes %40. To see the connection in code, read How to connect MongoDB to Node.js.

When don't you need to worry about this?#

If your database is hosted by a service, the topology (how many members, where they live) is usually decided by whoever provides the database, and you use the connection string they give you. It is still worth knowing the terms, because w: "majority" and readPreference change how your application behaves. To compare the document model with tables, see SQL vs NoSQL.

How to do this on Square Cloud#

Square Cloud offers MongoDB hosting starting on the Standard plan, always on a recent version. You create the database in the dashboard, and it is provisioned in seconds in the same datacenter as your applications, with an average latency of about 1 ms. TLS is required, using the certificate you download from the dashboard.

The hosted MongoDB is a single node (standalone), without a replica set: there are no secondary members, no elections and no replicaSet in the connection string. Use the URL the dashboard gives you and rely on snapshots, not replicas, to recover data. Collections, documents and indexes work as described above.

You take manual snapshots of the database whenever you want, and on every plan that includes databases you also get an automatic daily snapshot, kept for 7 days (the most recent for up to 30 days). You can restore any snapshot to the same database, to another one of the same engine or to a new database.

See the details on MongoDB hosting.