[
https://issues.apache.org/jira/browse/HBASE-20734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560069#comment-16560069
]
Andrew Purtell commented on HBASE-20734:
----------------------------------------
I don't like the idea of doing an extra check at every region open either, but
consider:
* If the change would stymie a rolling upgrade then it can't go in
* If a change on a patch or minor requires a separate tool or script to run
before upgrade, then I think the change breaks our compatibility guidelines and
could not go in
* One round trip to the NN is not _that_ expensive
So unless this fix is to be committed only to master, for future HBase 3, then
I think we need to be backwards compatible by checking for both the expected
location after this fix and the prior expected location.
If we had some kind of feature flag facility for region metadata, then after
doing this check once we could set a flag and then avoid doing the filesystem
check if the flag is set. That kind of change might be possible to introduce
into new minor releases.
> Colocate recovered edits directory with hbase.wal.dir
> -----------------------------------------------------
>
> Key: HBASE-20734
> URL: https://issues.apache.org/jira/browse/HBASE-20734
> Project: HBase
> Issue Type: Improvement
> Components: MTTR, Recovery, wal
> Reporter: Ted Yu
> Assignee: Zach York
> Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20734.branch-1.001.patch
>
>
> During investigation of HBASE-20723, I realized that we wouldn't get the best
> performance when hbase.wal.dir is configured to be on different (fast) media
> than hbase rootdir w.r.t. recovered edits since recovered edits directory is
> currently under rootdir.
> Such setup may not result in fast recovery when there is region server
> failover.
> This issue is to find proper (hopefully backward compatible) way in
> colocating recovered edits directory with hbase.wal.dir .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
