I checked the code. I think the ScopeWalEditFilter is something where for the source cluster you set the scope of that Edit. There you can mention that is is for Global Replication.
Now if you have two peers for the cluster and one of the peers you have specifically asked not to accept edits of a column family then such Edit can be ignored. Did you see addPeers() API that takes a param that represnts a table with Cf list which says what column family's edit can be accepted? Makes sense? Am I missing something here? Regards Ram On Thu, Aug 6, 2015 at 10:41 PM, Ashish Singhi < [email protected]> wrote: > Hi Ted. > Thanks for the response. > > I was talking about WAL edit replication. I guess that is different from > region replica replication, no ? > > Regards, > Ashish > > On Thu, Aug 6, 2015 at 7:54 PM, Ted Yu <[email protected]> wrote: > > > Please take a look at getScopeWALEntryFilter() > > in RegionReplicaReplicationEndpoint.java > > > > You can examine git log of the above file to see related JIRAs. > > > > Cheers > > > > On Thu, Aug 6, 2015 at 5:49 AM, ashish singhi <[email protected]> > > wrote: > > > > > Hello All. > > > > > > By default we are adding both ScopeWALEntryFilter and > > > TableCfWALEntryFilter filter to the list of filters (as part of > > > BaseReplicationEndpoint#getWALEntryfilter) to filter out the WAL > entries > > > that needs to be replicated. > > > Here I am not able to find out the importance of having > > > TableCfWALEntryFilter over ScopeWALEntryFilter. > > > According to me all the entries which needs to be replicated are > already > > > filtered out from ScopeWALEntryFilter. So I do not see any advantage of > > > having TableCfWALEntryFilter. > > > Please let me know If I am missing something. > > > > > > Regards, > > > Ashish Singhi > > > > > > > > >
