[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16558805#comment-16558805
]
Josh Elser commented on HBASE-20952:
------------------------------------
{quote}I definitely have some thoughts on this. I'll try to summarize and put
it here, but in general making the interface as basic as possible would be the
easiest to work with IMO.
{quote}
+1
{quote}Old request is reexamination of the WALEdit/WALKey entities because they
are fat objects that duplicate attributes. Would be sweet if these got a review
as part of this work (maybe its out of scope).
{quote}
Can try to lob this in, too.
{quote}There is too much here as it is (needs digging).
{quote}
Yeah, this is my biggest worry. We have a very basic {{WAL.Reader}} interface
now, but I worry about the implementation details pushed into AbstractFSWal
{quote}Will multiwal be supported?
{quote}
My hope would be that we can make WAL-per-Region work as that will simplify
recovery code greatly (and MTTR as you stated earlier). If that's the case, I
wouldn't expect multiwal to give much benefit here.
We'll have to visit multiwal anyways (to update for API), but, right now, my
gut is telling me that it wouldn't have much relevance for the Ratis LogService
wal.
> Re-visit the WAL API
> --------------------
>
> Key: HBASE-20952
> URL: https://issues.apache.org/jira/browse/HBASE-20952
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: Josh Elser
> Priority: Major
>
> Take a step back from the current WAL implementations and think about what an
> HBase WAL API should look like. What are the primitive calls that we require
> to guarantee durability of writes with a high degree of performance?
> The API needs to take the current implementations into consideration. We
> should also have a mind for what is happening in the Ratis LogService (but
> the LogService should not dictate what HBase's WAL API looks like RATIS-272).
> The API may be "OK" (or OK in a part). We need to also consider other methods
> which were "bolted" on such as {{AbstractFSWAL}} and
> {{WALFileLengthProvider}}. Other corners of "WAL use" (like the
> {{WALSplitter}} should also be looked at to use WAL-APIs only).
> We also need to make sure that adequate interface audience and stability
> annotations are chosen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
