[SERVER-16928] Allow one mongod to replay many oplogs from many servers Created: 19/Jan/15  Updated: 12/Feb/15  Resolved: 12/Feb/15

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: marian badinka Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:

 Description   

We have many small mongodb servers. The request is to have online copies (slaves) of all databases in one place/server

There is option in mongod:
--slave; --source [server:port]

This option could be extended with possibility to use:
--source1 [server:port],--source1db [db], --source1collection [coll] etc etc etc
to allow read oplog from many Master servers and REPLAY them on the target server.
This solution would allow customers to build ONE archive server with ONE mongod running and holding online copies (slaves, rs) from many many databases/collections.

thanks \marian



 Comments   
Comment by marian badinka [ 12/Feb/15 ]

Hi there, this topic can be closed.

I have found a way how to resolve this "idea" by using existing options in mongodb.

1. All the source servers (f.e. server1, server2) must be started with --master and some reasonable --oplogSize
– master switch is there due to write permissions to the databases. Can be replaced by rs.slaveOk() from mongo shell.

2. the ArchiveMongoDB server (where all chosen databases should be replicated) must be started with --master --slave and reasonable --oplogSize.

3. login to the ArchiveMongoDB via mongo --host ARCHIVE_SERVER.
4. use local;
5. db.sources.insert(

{host:"server1:port", only:"choosen database name1"}

)
6. db.sources.insert(

{host:"server2:port", only:"choosen database name2"}

)
--if all databases are to be replicated than "only:" can be bypassed
7. repeat steps 5, 6

it was tested with 2.8 mongodb version.

Regards \ Marian

Generated at Thu Feb 08 03:42:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.