[
https://issues.apache.org/jira/browse/HBASE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324535#comment-14324535
]
Ted Yu commented on HBASE-12561:
--------------------------------
+1
> Replicas of regions can be cached from different instances of the table in
> MetaCache
> ------------------------------------------------------------------------------------
>
> Key: HBASE-12561
> URL: https://issues.apache.org/jira/browse/HBASE-12561
> Project: HBase
> Issue Type: Sub-task
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: hbase-12561-v1.patch
>
>
> In testing, we have observed that if a client caches some regions with
> replicas in MetaCache, and then the table is recreated, the cache does not
> get invalidated. Upon caching more entries from a new instance of the table
> we can have entries for replicas from different instances of a table
> (remember that metacache is row based)
> On async wal replay (HBASE-11568), we have an elaborate mechanism to track
> region replica locations and skip replaying wal entries if the current region
> replica is not the same region replica from the original wal edit. This
> prevents replaying entries of older tables with the same name to the region
> replicas as well as replaying older entries from split (or merged) regions
> from old parent to new daughters.
> Trace level logging in my test setup showed that we were skipping some
> entries because of a case, where we would have region locations (of the same
> range) cached from different instances of the table (meaning some replicas
> are from already deleted table vs some entries from new table). This was
> causing superfluous skipping entries.
> The fix can be when we are merging entries for the same range, we simply
> check the other entries and delete those that do not match the new region id.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
