[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614920#comment-16614920
]
Josh Elser commented on HBASE-20952:
------------------------------------
{quote}If so, I was wondering if this doc was going to get a revision? (Lets
add link to this doc up at the top of this issue)
{quote}
It's been receiving updates already. I think GDocs will let you see that? Will
link that sucker as well if not already done.
{quote}Is it that he's done more homework that he has these questions or that
he just has a better understanding of how the system works?
{quote}
Well, he's obviously an expert at the brand new sync replication stuff. I'll
happily admit my ignorance around that. The fencing was me missing the
importance of the directory rename. Good outcome from review.
{quote}Is the 'design doc' we talk of above the place to work through his
concerns or is that somewhere else?
{quote}
My assumption was that we would be able to capture this information in the
design doc, and any others that people see as a gap. [~sergey.soldatov] had
mentioned offline yesterday that he thinks some gaps still exist around WAL
splitting – do you understand that well enough to suggest what needs to be
addressed in the doc which is not already there?
> 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
> Attachments: 20952.v1.txt
>
>
> 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).
> Other "systems" inside of HBase that use WALs are replication and
> backup&restore. Replication has the use-case for "tail"'ing the WAL which we
> should provide via our new API. B&R doesn't do anything fancy (IIRC). We
> should make sure all consumers are generally going to be OK with the API we
> create.
> 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)
