Hello community, I’m new to mongoDB.
I want to implement transaction feature to one of my small project.
is it possible && okay to have below structure of replica set to minimize number of nodes?
server1 - Web application server + mongos(router) + primary
server2 - secondary
server3 - secondary
Hi @Joohoon_Maeng,
Welcome to the MongoDB Community.
It’s good practice to keep mongos (router) on the application server. But keeping primary on the application server wouldn’t be a good option I believe.
Why it’s not a good option:
Both of above points will require amount of RAM possibly equal to your working data set if you want to get best performance.
In the case that you’ve mentioned, The application server would be already taking up some of your RAM to process the request / response. So it would be a good option to keep your Primary on separate node.
You’ve mentioned mongos but haven’t mentioned config server? I assume you’re running config server on the separate instance as well if you’re intended to run / apply sharding.
I am sure that you would have already checked on why to shard and when to shard. If not, This documentation will help you to decide considering the factors mentioned on that page. https://docs.mongodb.com/manual/sharding/.
I hope it answers your question!
Wow! this is a mind blowing answer!
Thank you.
Can I ask one more question? is it okay to have config on the application server also?
It’ll look like :
application server - mongos / config
server1 - primary
server2 - secondary
server3 - secondary
You’re welcome @Joohoon_Maeng.
The good option would be to have config server separate and you should also setup replica set for your config server (while running in production) so you can have one node always available in case of any failure.
Thanks,
Viraj
@Joohoon_Maeng
Sharding config requires a full replicaset so you’'ll need another 3 db hosts for that.
If you are not sharding anytime soon stick with a simple replicaset and scale it up until you hit bottlenecks.
I want to add some clarifications to what @viraj_thakrar wrote.
Yes, all read operations, when using default readConcern and readPreference, will be performed on the primary. However, all data bearing nodes in a replica set (not only the primary) handle all the write operations and also have all the indexes.
Hi @chris
If I’m not sharding, meaning I won’t need a config server. I see.
So in this case I’ll need 3 nodes for dbs, 4 total including WAS.
Thank you!
Hi @steevej
Can you elaborate little more on ‘all data bearing nodes in a replica set handle all the write operations’ ?
according to the docs(https://docs.mongodb.com/manual/core/replica-set-write-concern/), it seems primary by default is the one handles write data operation.
The sole purpose of having secondaries (data bearing) and replication is that your data is replicated. So if the primary update document d1, then this update must be replicated on all secondaries. Otherwise your data is not replicated so you lose the update if the primary goes down.
Closed on Feb 14, 2021
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.
| Topic | Replies | Views | Activity |
|---|---|---|---|
| Mongodb docker vm.max_map_count is too low even if set to 524288 | 1 | 2.0k | May 2024 |
| MongoDB 2.6.11 on CentOS 6.5 to MongoDB 6.0.15 upgrade | 0 | 389 | Jun 2024 |
| Fresh Debian Bookworm, unable to run MongoDB 7.0 | 1 | 122 | Oct 2024 |
| Increased disk load after upgrading to mongodb 6.0 + Ubuntu 22.04 | 0 | 51 | Sep 2024 |
| Error when trying to install mongodb-community@7.0 on macOS 11 via Homebrew | 0 | 146 | Oct 2024 |
