I understand each of the terms but I do not understand very well if they can work simultaneously.

In my case, for example, I have a machine with 20GB and I would like to know which is the best configuration if I have to use both the replication and the sharding

  • 1
    Do you only have a single machine? What are your goals as far as using replication and sharding (i.e. scaling performance, adding data redundancy, mimicking a production environment, learning MongoDB, ...)? – Stennie Mar 27 at 1:33
  • It is only to have the concept and simulate it since it is an end-of-career project and I can not acquire as many servers as would be necessary. – manubermu Mar 27 at 13:48
  • Thanks for the extra context on your goal. You can deploy all of the components for a sharded cluster in a single environment for testing or development purposes, but keep in mind that all will be competing for the same server resources. Are you trying to simulate any specific scenarios or just after a minimal test configuration given limited resources? If you don't need to test failover/redundancy you could use single-node replica sets for your shard servers and config servers. – Stennie Apr 1 at 1:03
  • One tip: you should explicitly set --wiredTigerCacheSizeGB to a value that allows your mongod processes to co-exist happily in the same host environment. Each mongod instance needs memory for WiredTiger's internal cache (working set for data in memory) as well as available memory for O/S and filesystem cache. The assumption is that only one mongod instance is running in a host environment, so the default cache size is the larger of either 50% of (RAM - 1 GB) or 256MB. – Stennie Apr 1 at 1:03

In my case, for example, I have a machine with 20GB and I would like to know which is the best configuration if I have to use both the replication and the sharding.

The Replication & Sharding both terms are different from each other. As Replication creates additional copies of the data and allows for automatic failover to another node. A replica set in MongoDB is a group of mongod processes that maintain the same data set. Replica sets provide redundancy and high availability, and are the basis for all production deployments.

And sharding allows for horizontal scaling of data writes by partitioning data across multiple servers using a shard key.

As sharded cluster the set of nodes comprising a sharded MongoDB deployment. A sharded cluster consists of config servers, shards, and one or more mongos routing processes.

The briefly you can say that a MongoDB sharded cluster consists of the following components:

  • shard: Each shard contains a subset of the sharded data. As of MongoDB 3.6, shards must be deployed as a replica set.
  • mongos: The mongos acts as a query router, providing an interface between client applications and the sharded cluster.
  • config servers: Config servers store metadata and configuration settings for the cluster. As of MongoDB 3.4, config servers must be deployed as a replica set (CSRS).

For example the standard replica set deployment for production system is a three-member replica set.

In your environment you have 20GB of Data. Suppose that you are configuring & accumulate your 20GB data with 3 node replica set then sharding also require 3 node. That means for sharding total node will be require 6 nodes. The replica set node depends on your infrastructure requirement. for replica set selection of even or odd number of members node determination you shall find here

for further your ref Replication Sharding Difference between Sharding And Replication on MongoDB and here

  • My idea is to have a main Sharded Cluster divided into two, Sharded A and Sharded B. Each Sharded, both A and B will have a set of primary replica and two secondary ones. Would it be fine like that? – manubermu Mar 26 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.