[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632087#comment-16632087
]
stack commented on HBASE-20952:
-------------------------------
bq. The point of this doc was to make sure we had a clear picture of all
"WAL-related" things in HBase and what their roles & responsibilities were.
Sorry. I did not get that that was the point reading the doc. The preamble
drops just when it is about to make the point of what the doc is for. It is
followed by three sections: "Components of WAL System", "Evolving individual
WAL system components", and "Limitation". The first seems to be for the
'WAL-related' listing you suggest. The second's section implies a listing of
how hbase will be changed ('Evolving') but it seems to be just a continuation
of the listing ...
Yeah, sorry, I'm lost on what the doc is supposed to be doing.
I also made notes on imprecision and stuff I thought incorrect.
Thanks.
> Re-visit the WAL API
> --------------------
>
> Key: HBASE-20952
> URL: https://issues.apache.org/jira/browse/HBASE-20952
> Project: HBase
> Issue Type: Improvement
> 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)
