Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-12322

Support user-definable MongoDB Cluster Name



    • Type: New Feature
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Sharding
    • Labels:


      Add MongoDB sharded clusters to the current set of supported, user-definable “named resources” and components (these currently include replicasets, databases, collections, roles, etc.) This allows private cloud providers to enable users with a specific named resource, in this case a cluster by name, while abstracting the user from the components that comprise a dynamically managed and provisioned cluster.

      Most relational databases provide such a concept using a combination of administration, CLI and tool support, internal database service awareness of cluster changes, and meta-management .

      There is also a concept of providing external awareness of cluster name and component structure via existing directory or service-based resources. For example, PostGres provides this via service names, which can be used in the connection string and tied to an external look-up via LDAP.

      Requirement – phase 1

      • Support user-definable cluster names as “named resources” in the same/similar way other resources (replicasets, databases, collections, users, etc.) are supported.
      • Cluster will be aware of its cluster name.
      • User/clients should only interact/connect with the cluster name. The database service should maintain the cluster host:port list and ensure that changes are propagated with little/no effect on existing users or connections.
      • CLI should provide interface to query and return topology/inventory and status of a specified cluster name (lookup key).
      o MongoS nodes – top level
      o Would be helpful to also return shard/mongod/config server information below the mongos nodes
      o State of the cluster as failures/configuration changes occur

      Requirement – phase 2 (this should spawn a separate, linked SERVER ticket)

      Enable MongoDB cluster name and underlying inventories to be “advertised” and accessed via external look-up directory services (such as LDAP, Zookeeper, etc.)

      • The primary use case is to enable external access to cluster status and topology changes without connecting directly to MongoDB. This enables informed connections to cluster inventory components for monitoring, maintenance, availability




            backlog-server-sharding Backlog - Sharding Team
            rob.young@10gen.com Rob Young
            0 Vote for this issue
            4 Start watching this issue