[HBASE-20952] Re-visit the WAL API - ASF JIRA

Voters

Watch issue

Watchers

Create sub-task

Link

Clone

Update Comment Author

Replace String in Comment

Update Comment Visibility

Delete Comments

XML

Word

Printable

JSON

Details

Type: Improvement
Status: Resolved
Priority: Major
Resolution: Implemented
Affects Version/s: None
Fix Version/s: None
Component/s: wal
Labels:
None

Description

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.