[SERVER-9780] Secondaries (priority=0) able to specify filter criteria for the data they receive from the primary Created: 24/May/13 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Matt Kalan | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 4 |
| Labels: | tertiary | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
This is useful in cases in which Mongo is being used for distributing data, not just using replication for high-availability. One way of doing this would be that secondaries can specify a query for the data they want to receive from the primary. This is an extension and further refinement of SERVER-1559. |
| Comments |
| Comment by Abhilash Mannathanil [ 29/May/19 ] |
|
Any updates on this issue? We have a use case where we want to replicate only portion of the data to a disaster recovery site. In the absence of this, its forced to run separate instances where the locally significant data is written to one instance(s) and globally significant data is written to another instance, which is replicated to a disaster recovery site. |
| Comment by Joe Enzminger [ 10/Apr/19 ] |
|
There are three use cases where this would be highly desirable: 1) Backups - in a disaster recovery scenario, we often don't need to recover our larger collections quickly. We need our "state" data up and running fast, and then we can come in behind and rebuild transaction information. Being able to set up a hidden node for backups that doesn't replicate the entire database enables this nicely. It also allows us to get this node "up" more quickly since it doesn't have to replicate the large collections during the initial sync. We current
2) Reporting/Business Intelligence - same scenario. It allows us to get new nodes built for reporting/BI that don't have to necessarily replicate data that isn't used for reporting.
3) Event Generation - using streams or the oplog to generate events is a fantastic side effect of the Mongo architecture. However, using a secondary that is being used for fault tolerance is somewhat dangerous. We typically use a hidden, priority 0 node for this in our architecture. For these nodes, the applications using them generally only use a very small amount of the data. Being able to blacklist collections would be desirable.
|
| Comment by Tess Avitabile (Inactive) [ 08/Oct/18 ] |
|
Hi venkata.vishwanath.reddy.kothakapu@hsbc.co.in, This is not something we are currently actively working on, in lieu of other higher priority projects, but it is something we would like to do in the future. To help us understand your pain and to ensure the appropriate priority of this ticket for future releases, can you expand on your use case? Why is this feature valuable to you? Regards, Tess |
| Comment by Vishu Kothakapu [ 08/Oct/18 ] |
|
Any updates on this issue please ? This feature will remove unnecessary manual coding/testing and makes it much simpler in use cases, where there may be restrictions applied as the data belongs to a different countries than the country hosting the replicaset nodes.. |