[
https://issues.apache.org/jira/browse/HBASE-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479545#comment-13479545
]
Kannan Muthukkaruppan commented on HBASE-7011:
----------------------------------------------
Stack: Yes, that was one of the questions I posed in HBASE-6980, and decided to
fork off the issue into this JIRA. Todd's theory is this flush marker is a
write to the HLog just to ensure the RS has not been fenced off by master
(because master thought this RS was dead).
Todd wrote: <<< If I remember correctly, there is a reason for the flush
marker: it ensures that the RS hasn't been fenced on HDFS – i.e that it hasn't
lost its connection to ZK and already had its log splitting started. The reason
this is important is that, otherwise, it could move on to delete old log
segments, which would potentially break the log split process.>>>
My response: <<< If RS zk expires, and master initiates recovery/log splitting,
then the first step is to rename the log directory from .logs/rs to
.logs/rs-splitting. And then the lease recovery is done on the individual files
within the directory. Because of the directory name, any attempt by the old RS
to delete any old log files (in the old path) should fail. Therefore, still not
seeing the value of writing the flush marker.>>>
> log rolling and cache flushing should be able to proceed in parallel
> --------------------------------------------------------------------
>
> Key: HBASE-7011
> URL: https://issues.apache.org/jira/browse/HBASE-7011
> Project: HBase
> Issue Type: Improvement
> Reporter: Kannan Muthukkaruppan
> Assignee: Kannan Muthukkaruppan
>
> Today, during a memstore flush (snapshot of memstore + flushing to disk), log
> rolling cannot happen. This seems like a bad design, and an unnecessary
> restriction.
> Possible reasons cited for this in code are:
> (i) maintenance of the lastSeqWritten map.
> (ii) writing a "completed-cache-flush" marker into the same log before the
> roll.
> It seems that we can implement a new design for (i) to avoid holding the lock
> for the entire duration of the flush. And the motivation for (ii) is not even
> clear. We should reason this out, and make sure we can relax the restriction.
> [See related discussion in HBASE-6980.]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
