[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16624075#comment-16624075
]
Josh Elser commented on HBASE-20952:
------------------------------------
[~stack], [~Apache9], (and others!) I know you are all super busy. If you get a
chance to look at the new doc that I Ted and I worked on, that'd be greatly
appreciated:
[https://docs.google.com/document/d/1o552MkKq9wF3BXY2nVcsCXBAImUH6r132Cxv9WHL3D8/edit]
My hope is that this will make the high-level picture a bit clearer. Great
review would be if we missed any implementation specific details in HBase WRT
WALs and how they're used, or if we have any architectural goals in mind which
we didn't state. After that, My hope would be to start making iterative changes
in a feature branch to work towards this vision.
Finally, I do think it would be good to define a checkpoint on that feature
branch with iterative changes to avoid the "mega-patch" pain we often find
ourselves in. I'd be curious to hear if you have any ideas as to how we can get
some good peer review without being too intrusive/heavy on your lives.
> 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)
