[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:
Depends
Related
is related to SERVER-1559 Ability for a replica set node to onl... Backlog
is related to SERVER-39566 Questions related to Filtered Replica... Closed
Assigned Teams:
Replication
Participants:
Case:

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

Generated at Thu Feb 08 03:21:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.