[SERVER-34885] Add ability to throttle or rate limit copyDatabase operation Created: 08/May/18  Updated: 06/Dec/22  Resolved: 11/May/18

Status: Closed
Project: Core Server
Component/s: Admin, Storage
Affects Version/s: 3.0.15
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: asdf01 Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32381 The copyDatabase shell helper should ... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

It would be good if we could speed limit the copyDatabase operation.  Currently when we do this the mongo database seems to try to do this operation as fast as possible which makes the server unusable for other operations.  

 

We have a multi tenanted setup with hundreds of databases running on the same database server.  This copyDatabase operation essentially brings all customer environments to a standstill.  



 Comments   
Comment by Asya Kamsky [ 14/May/18 ]

michael.qiu@wdtl.com,

You can achieve similar semantics to copydb by using 

mongodump --archive -d <database-name> | mongorestore --archive

There is a brief description of using Linux pipes to copy the output of one to the other (in the context of Atlas) here but it will work with any two clusters.

If you want to copy a database within the same instance renaming it, you can use mongodump piped to to mongorestore method with --nsFrom --nsTo options to rename.

Comment by asdf01 [ 13/May/18 ]

Hi @ian.whalen

What is copyDb being deprecated in favour of?  I couldn't find any publically available documentation on this topic.  Does the successor of copyDb have any rate limiting throttling capability?  Thanks.

Comment by Ian Whalen (Inactive) [ 11/May/18 ]

Hey michael.qiu@wdtl.com copyDB is being deprecated with the 4.0.0 release, so we do not plan on making any changes/improvements to it.

Generated at Thu Feb 08 04:38:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.