10 results found

1. Bidirectional Data Replication beetween two or more clusters

   In order to provide active-active deployments on multiple datacenter without need to shard data and route trafic based on shard-key. Develop a bidirectional replication with a conflict resolution method , for example , timestamp-based.

   18 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Data Replication from one MongoDB Cluster to another MongoDB Cluster

   Create an option for the user to replicate data from one MongoDB Cluster to another MongoDB Cluster inside the account. We don't need to migrate data, I need replicate data from an Production Cluster to an Dev/Test Cluster. Thanks.

   8 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Elevate hidden replica to a voting member when quorum is lost for a Replica Set

   The MongoDB engine should allow for hidden members in a replica set to be automatically elevated to a voting member. When quorum is lost and can't be met, the hidden replica is automatically reconfigured to a voting member to obtain quorum.
   When the failed voting member comes back online and catches up the hidden replica is demoted back to a normal hidden member.

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Replication  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Use dedicated interface for replication and balancing

   Like many other big database system, MongoDB may support to specify dedicated interfaces for replication and/or for the balancer (sharding)

   Currently you can configure replication sets and shards members only by single hostname/IP-Address, i.e. all data is transmitted over the same network interface.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Ability to replicate the data within a cluster to another cluster

   Two different scenarios. One scenario is to have a DR cluster. 2 independant clusters that are one way synced. As of right now, a custom CDC solution (custom code + Kafka) is needed to achieve this.
   Another is because of latency and the requirement for data to be stored in 2 different data center, 2 indepentant mongoDB clusters that are two way synced. As of right now, a custom CDC solution (custom code + Kafka) is needed to achieve this.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Scheduled stepdown for smoother primary election

   Stepdown is a great tool that allows us to keep clusters operating smoothly. We use it for example when we want to perform some maintenance work on the host where the primary is currently running, to perform a rolling upgrade, and in many other cases we need to switch the primary to another node.

   While usually electing a new primary is fast enough, for clusters with very high write traffic, it sometimes unfortunately leads to write errors on the application side. The reason is that drivers need to disconnect from the previous primary and connect to the new one, and this takes time. All write attempts at this time end with an error. Of course those operations can be retried after a short time, but it seems to me that this situation could be avoided fairly easily.

   Here's my idea:
   - We add an optional parameter to the stepDown method, let’s name it: electionEffectiveTimeSeconds. If we do not set it, stepDown works normally - as before,

   • The new primary is elected, but the cluster and drivers do not use it as a primary yet, instead they wait for electionEffectiveTimeSeconds seconds after the election is done,

   • Until then, the previous primary handles write operations,

   • In the meantime, all cluster nodes and drivers receive information about the new primary and when the change will take effect - based on electionEffectiveTimeSeconds,

   • This will allow all parties to properly prepare for the switchover, which should minimize the time of unavailability of the primary,

   • When the time expires, clusters and drivers change primaries to the new node.

   The key element will be to determine the optimal range for this new parameter. On the one hand, it must be big enough to give enough of time to spread the information through the cluster and drivers. On the other hand, it must not be too long, because there is a risk that - during that time - the new elected primary will catch a lag and will not be able to become a primary. In this case, however, it could try one more time, and if that fails also, then perform a normal stepdown for a third time.

   I think this method would be useful during all stepdowns, which are planned in advance and it is not necessary to happen immediately.

   Stepdown is a great tool that allows us to keep clusters operating smoothly. We use it for example when we want to perform some maintenance work on the host where the primary is currently running, to perform a rolling upgrade, and in many other cases we need to switch the primary to another node.

   While usually electing a new primary is fast enough, for clusters with very high write traffic, it sometimes unfortunately leads to write errors on the application side. The reason is that drivers need to disconnect from the previous primary and connect to the new one, and… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. allow mongosync to migrate few field from source to destination for collection in database

   right now mongosync will migrate all the fields from source to destination based on filter or non filter setting but there is no way to move few field out of all field for all document

   to migrate few field from source to destination for collection in database with default primary key field (_ID )

   requesting the feature in new mongosync version

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Raise an error when "majority" writes not possible

   This topic is related to https://www.mongodb.com/docs/v6.0/tutorial/mitigate-psa-performance-issues/ in a PSA ReplicaSet configuration.

   When you try to execute a command with writeConcern {w: "majority"} in a three-member Primary-Secondary-Arbiter configuration where one data bearing node is not available, then the command hangs forever - unless the missing member becomes available again or you reconfigure the ReplicaSet to {votes: 0, priority: 0} on the non-available member.

   Instead of waiting forever, MongoDB should rollback the change and raise an error. This behavior should apply mainly for operations where {w: "majority"} is set implicitly and cannot be changed by the user, for example at "renameCollection" issued on 'mongos'. You may introduce a new optional parameter which controls whether the command waits forever (the current behavior) or raises an error after a given timeout.

   This topic is related to https://www.mongodb.com/docs/v6.0/tutorial/mitigate-psa-performance-issues/ in a PSA ReplicaSet configuration.

   When you try to execute a command with writeConcern {w: "majority"} in a three-member Primary-Secondary-Arbiter configuration where one data bearing node is not available, then the command hangs forever - unless the missing member becomes available again or you reconfigure the ReplicaSet to {votes: 0, priority: 0} on the non-available member.

   Instead of waiting forever, MongoDB should rollback the change and raise an error. This behavior should apply mainly for operations where {w: "majority"} is set implicitly and cannot be changed by the user, for example at "renameCollection" issued… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. URL Decode `readPreferenceTags`

   If a url encoded value is set to readPreferenceTags it will be ignored causing for instance connecting to analytics node impossible from tooling that correctly encodes the urls.

   It can look like this for instance: readPreferenceTags=nodeType:ANALYTICS becomes readPreferenceTags=nodeType%3AANALYTICS

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Replication  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Mongo replicaset init sync issue

    When we have large size mongo replica set, we may have to take out each nodes for maintenance for few hrs or days.

    In that case we have to increase size of Oplog to keep several days of transactions to resync nodes after maintanance.

    If the RS headroom falls below oplog window, then we have blow away data and do init sync to add node back after maintanence.

    The problem with very large size Oplog, will slow down any Change Stream process. Also it will occupy un neccasary space within collections.

    Can mongo offer alternative way to constantly dump oplog data to local file system? Then we can use this data to re-apply transactions, to sync failed nodes, instead of doing init sync. Some thing similar to archichive log mechanism for redo log, Oracle uses.

    This will avoid init sync issue for very large replica sets.

    Thanks
    Rama Arumugam

    When we have large size mongo replica set, we may have to take out each nodes for maintenance for few hrs or days.

    In that case we have to increase size of Oplog to keep several days of transactions to resync nodes after maintanance.

    If the RS headroom falls below oplog window, then we have blow away data and do init sync to add node back after maintanence.

    The problem with very large size Oplog, will slow down any Change Stream process. Also it will occupy un neccasary space within collections.

    Can mongo offer alternative way to constantly dump oplog… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Replication  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close