[SERVER-701] Ability to rename databases Created: 04/Mar/10 Updated: 06/Apr/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Erik Jones | Assignee: | Brian Lane |
| Resolution: | Unresolved | Votes: | 210 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Participants: |
Aaron Silverman, airs0urce, Alexander Yu, Alex Kotenko, Amey Potnis, Andre Kaminski, Andrey Hohutkin, Anup Katariya, Asya Kamsky, Bjorn Harvold, Brian Konash, Brian Lane, Christian Tonhäuser, Dan Dascalescu, Dissatisfied Former User, DJ van Wyk, Doug Hudson, Erik Jones, Gavin Aiken, Graham Frank, Guillermo, Ifor Williams, Ilya Shaisultanov, Janos Brezniczky, John Lyon-Smith, joosep jaagosild, Justin Patrin, kabir mehta, Lance Legel, Maciej Gajewski, Michael Korbakov, Nicolau Leal Werneck, reda, rgpublic, Rob Colella, SherryUmmen, Steven Vannelli, Svetoslav Milenov, Uli Sesselmann, Viktor Hedefalk, Vyacheslav Stroy, Ygor Lemos
|
||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
Issue Status as of Apr 9, 2015 [UPDATE Sep 10, 2019] ---------------------- We are aware of how painful and long it is to rename a database in MongoDB. Unfortunately, this is not an simple feature for us to implement due to the way that database metadata is stored in the original (default) storage engine. In MMAPv1 files, the namespace (e.g.: dbName.collection) that describes every single collection and index includes the database name, so to rename a set of database files, every single namespace string would have to be rewritten. This impacts:
This is just to accomplish a rename of a single database in a standalone mongod instance. For replica sets the above would need to be done on every replica node, plus on each node every single oplog entry that refers this database would have to be somehow invalidated or rewritten, and then if it's a sharded cluster, one also needs to add these changes to every shard if the DB is sharded, plus the config servers have all the shard metadata in terms of namespaces with their full names. There would be absolutely no way to do this on a live system. To do it offline, it would require re-writing every single database file to accommodate the new name, and at that point it would be as slow as the current "copydb" command. Asya Kamsky, Original descriptionHaving the ability to rename databases would be nice. That would allow things like cloning a database with straight file copies plus a rename (to avoid having to wait on index builds when using db.copyDatabase). |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Brian Lane [ 09/Sep/19 ] |
|
Hi amcgregor, Thanks for the feedback. I have created Feel free to comment on -Brian |
| Comment by Dissatisfied Former User [ 05/Sep/19 ] |
|
The initial recommendation in the absence of the ability to rename (for technical reasons which are entirely solvable with a for loop…) to use copyDatabase is problematic. Given copyDatabase has been hard-deprecated. (Hard as in: it no longer works, even with a warning; it fails with an assertion error.) What's particularly worse is that while the assertion provides a link to the relevant change log, that change log makes a recommendation that it does not follow through with an example. Use mongodump and mongorestore! I'd love to. How? Given I have BSON files exported to directory-per-db and --gzip --archive backups, and attempting to use the {-d} option to target an alternate database issues:
C'mon, now. That suggestion / recommendation is outlandish when I'm not attempting to filter which database or collections are restored, I'm only trying to specify the destination database to populate. (This message might make sense during mongodump, where you probably are trying to filter, but not on restore.) Which, after deeper investigation, should utilize nsFrom and nsTo, no? Thus the change log should point developers at the mongorestore reference "recipe" for "Change Collections' Namespaces during Restore", specifically. Or, even better, provide a concrete equivalent example to the old process. |
| Comment by airs0urce [ 08/Mar/19 ] |
|
It takes a long time to move collection by collection in new database. Would be good to get ability to rename DB without copying all the data around. |
| Comment by Janos Brezniczky [ 20/Jul/18 ] |
|
Again (and again) a year gone - any news perhaps? |
| Comment by Ygor Lemos [ 30/Oct/17 ] |
|
Any news on this for wiredtiger on MongoDB 3.4+ ? |
| Comment by Uli Sesselmann [ 10/Mar/16 ] |
|
Almost a year has passed - are there any news on this topic? |
| Comment by Asya Kamsky [ 09/Apr/15 ] |
|
Hi Alex, WredTiger storage engine fortunately keeps the metadata only in limited number of places. However, we support (and encourage) migration between storage engines via the replica set, by being able to run different storage engines on different nodes. We basically make a promise that any operation you perform on the primary will be able to replicate successfully to the other members. Having said that, we are considering the future and what the implications of supporting a command that would not work on all the storage engines would be. As you might imagine, we have to be extremely careful around this, so as not to break things unexpectedly. In addition, we are very hesitant to add support for any commands which work on some configurations and don't on others (for example, we really want to make sure that we never add new commands that only work "unsharded" and then break when you move to a sharded cluster). Asya |
| Comment by Alex Kotenko [ 09/Apr/15 ] |
|
Hi Asya, thanks for detailed answer. That's unfortunate but understandable, however, what about WiredTiger storage? Regards |
| Comment by Asya Kamsky [ 09/Apr/15 ] |
|
Folks, We are aware of how painful and long it is to rename a database in MongoDB. Unfortunately, this is not an simple feature for us to implement due to the way that database metadata is stored in the original (default) storage engine. In MMAPv1 files, the namespace (e.g.: dbName.collection) that describes every single collection and index includes the database name, so to rename a set of database files, every single namespace string would have to be rewritten. This impacts:
This is just to accomplish a rename of a single database in a standalone mongod instance. For replica sets the above would need to be done on every replica node, plus on each node every single oplog entry that refers this database would have to be somehow invalidated or rewritten, and then if it's a sharded cluster, one also needs to add these changes to every shard if the DB is sharded, plus the config servers have all the shard metadata in terms of namespaces with their full names. There would be absolutely no way to do this on a live system. To do it offline, it would require re-writing every single database file to accommodate the new name, and at that point it would be as slow as the current "copydb" command. Asya Kamsky, |
| Comment by Alexander Yu [ 06/Apr/15 ] |
|
My manager is asking to moving out from mongo because of this (the major reason) |
| Comment by Andre Kaminski [ 06/Apr/15 ] |
|
Seriously this is classified as minor feature?!!! I am currently evaluating MongoDB for one of my clients, and, in all fairness, cannot recommend it as mature product with such basic functionality missing. |
| Comment by Lance Legel [ 10/Mar/15 ] |
|
Pretty ridiculous that a simple functionality like this is not provided... |
| Comment by Alex Kotenko [ 02/Mar/15 ] |
|
I'm writing again here (already upvoted) to confirm that we still need this. I've managed to rename one problematic database and it was a real pain to do that. I will not dare to do this on the second one as it's few terabytes large and it will take ages. Philosophy of NoSQL in general and MongoDB particularly is about moving quickly without thorough long-term planning, allowing early mistakes and allowing to easily fix them later when you know what your architecture actually is. Not being able to easily fix database naming is not only a nuisance and a bugger, it's a major system inconsistency and goes across Mongo's "Flexible Data Model" mission statement. Being unable to rename database is not a flexible data model. |
| Comment by Andrey Hohutkin [ 02/Mar/15 ] |
|
It is urgent feature. Extremely needed for DB maintenance. |
| Comment by Svetoslav Milenov [ 16/Feb/15 ] |
|
How many votes are enough for this to be considered? |
| Comment by Alex Kotenko [ 19/Jan/15 ] |
|
Upvoted. I need to rename two databases right now, due to early project mistakes that now causing terms confusion. And seems like there is no easy way to do that. |
| Comment by John Lyon-Smith [ 18/Dec/14 ] |
|
Hello! Anybody in there...? Pretty please? |
| Comment by Guillermo [ 08/Dec/14 ] |
|
Please add this feature, a future database server must rename his databases. Thanks! |
| Comment by Alexander Yu [ 27/Nov/14 ] |
|
I've needed this features. |
| Comment by Rob Colella [ 12/Nov/14 ] |
|
Please add this feature as it is critical and should be standard in an enterprise environment. |
| Comment by SherryUmmen [ 10/Oct/14 ] |
|
so with my vote we have 150 votes; could this feature be considered in near future please. Or atleast an efficient workaround, rather we always copy everything? I am using C# Driver where _server.CopyDatabase() is also Obselete. |
| Comment by Vyacheslav Stroy [ 19/Jun/14 ] |
|
Please implement this feature. It would save a lot of time not only for production environment. It takes realy a lot of time to restore databse from production backup, devs would be much happier with such handy command. |
| Comment by DJ van Wyk [ 12/Mar/14 ] |
|
Very good point @Dan_Dascalescu. I would hate to see what our maintenance guys think when you copy that much data in a production environment. |
| Comment by Dan Dascalescu [ 07/Mar/14 ] |
|
Adding my voice to this. I would much rather have a "rename" function, than having to wait for db.copyDatabase() to complete on my 2TB database. Not to mention that you might not have enough disk space for two copies of your database, or you might needlessly pay for it. |
| Comment by rgpublic [ 26/Nov/13 ] |
|
@Ilya: According to this (http://stackoverflow.com/questions/15303409/how-to-rename-a-database-using-mongomapper-in-ruby) the db.rename Funktion is only a shell-specific wrapper for copyDatabase/dropDatabase. A real "rename" like proposed in this JIRA ticket doesn't exist yet. |
| Comment by Ilya Shaisultanov [ 26/Nov/13 ] |
|
How come that in the shell I can say db.rename('newname') and it works but I cannot do the same in the mongo shell script? |
| Comment by Nicolau Leal Werneck [ 09/Oct/13 ] |
|
I would like not just renaming, but also creating an "alias" would be nice. So for example we can have multiple dumps from some database with different names (their dates), but then have an alias that points to the most recent of them... |
| Comment by Viktor Hedefalk [ 07/Sep/13 ] |
|
+1 |
| Comment by Aaron Silverman [ 19/Aug/13 ] |
|
Renaming would be great for large databases |
| Comment by kabir mehta [ 31/May/13 ] |
|
+1 Please add this feature! I get a monthly dataset and was hoping to slide my datasets to preserve historical data. I'm shocked this isn't supported. We really need this. Thanks. |
| Comment by Justin Patrin [ 31/May/13 ] |
|
+1 I'll add that the ability to do this while the server is down would be sufficient for my needs. I would think/hope that this should be as simple as renaming the files on the filesystem and updating some kind of internal metadata. A workaround or hack until the online in-server feature is finished would be acceptable. I have already implemented all sorts of what I see as hacks when restoring a sharded cluster. I have to manually update all sorts of metadata in the config db to make a restored cluster work, even without renaming databases. |
| Comment by Amey Potnis [ 10/May/13 ] |
|
+1 |
| Comment by Anup Katariya [ 27/Apr/13 ] |
|
+1 |
| Comment by Brian Konash [ 04/Apr/13 ] |
|
+1 |
| Comment by Ifor Williams [ 28/Feb/13 ] |
|
+1 Getting the name right first time - isn't Agile |
| Comment by Maciej Gajewski [ 29/Oct/12 ] |
|
+1 |
| Comment by Graham Frank [ 24/Sep/12 ] |
|
+1 for this feature as well. It's confusing to think it isn't already supported and is only a minor priority issue. |
| Comment by reda [ 02/Aug/12 ] |
|
this a medium priority requirement, i think it's an essential feature. |
| Comment by joosep jaagosild [ 17/Jul/12 ] |
|
Another +1 for this new feature. |
| Comment by Gavin Aiken [ 11/Jul/12 ] |
|
This would definitely give some flexibility in moving data around quickly as systems grow. Example use case - in EC2 (and many raid systems) you can take a quick snapshot of a running mongo db and create a new disk vol on another server almost immediately. So if you want to move a big collection onto its own server with almost no downtime, you do the snapshot procedure, drop the collection from the original server/db and drop all the other unwanted collections from the copied snapshotted db on the new server. It would be good to then rename the db on the new server as a final step to avoid confusion, and to avoid having to copy the data out and in again which could take hours. Otherwise you have the same db name on 2 different servers but with different collections in each. |
| Comment by Christian Tonhäuser [ 24/Jan/12 ] |
|
+1 for being able to rename databases. |
| Comment by Bjorn Harvold [ 20/Nov/11 ] |
|
I'd like to see this feature supported as well. |
| Comment by Michael Korbakov [ 26/Sep/11 ] |
|
Any plans for including it into coming releases? Having it solved would help us migrating to sharded MongoDB cluster. |
| Comment by Doug Hudson [ 24/Aug/11 ] |
|
We get replacement datasets periodically and it would be helpful to just rename a db to some archived name, and keep using the original db name (without the fuss of copy/export/import and configuration management of db names). |