Details

    • Type: New Feature
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: planned but not scheduled
    • Component/s: Usability
    • Labels:
      None

      Description

      Having 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).

        Activity

        Hide
        farquaad Andre Kaminski added a comment -

        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.

        Show
        farquaad Andre Kaminski added a comment - 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.
        Hide
        alecyu Alexander Yu added a comment -

        My manager is asking to moving out from mongo because of this (the major reason)

        Show
        alecyu Alexander Yu added a comment - My manager is asking to moving out from mongo because of this (the major reason)
        Hide
        asya Asya Kamsky added a comment - - edited

        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:

        • the .ns file
        • every single numbered file for the collection
        • the namespace for every index
        • internal unique names of each collection and index
        • contents of system.namespaces and system.indexes (or their equivalents in the future)
        • other locations I may be missing

        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,
        MongoDB Product Team

        Show
        asya Asya Kamsky added a comment - - edited 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: the .ns file every single numbered file for the collection the namespace for every index internal unique names of each collection and index contents of system.namespaces and system.indexes (or their equivalents in the future) other locations I may be missing 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, MongoDB Product Team
        Hide
        mobafill Alex Kotenko added a comment -

        Hi Asya,

        thanks for detailed answer.

        That's unfortunate but understandable, however, what about WiredTiger storage?

        Regards
        Alex.

        Show
        mobafill Alex Kotenko added a comment - Hi Asya, thanks for detailed answer. That's unfortunate but understandable, however, what about WiredTiger storage? Regards Alex.
        Hide
        asya Asya Kamsky added a comment - - edited

        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

        Show
        asya Asya Kamsky added a comment - - edited 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

          Dates

          • Created:
            Updated:
            Days since reply:
            6 weeks, 1 day ago
            Date of 1st Reply: