Your client is writing to a region when the RegionServer crashes. At what point in the write is your
data secure?

A.
From the moment the RegionServer wrote to the WAL (write-ahead log)

B.
From the moment the RegionServer returned the call

C.
From the moment the RegionServer received the call

D.
From the moment the RegionServer wrote to the MemStore

Explanation:
Each RegionServer adds updates (Puts, Deletes) to its write-ahead log (WAL) first,
and then to the Section 9.7.5.1, “MemStore” for the affected Section 9.7.5, “Store”. This ensures
that HBasehas durable writes. Without WAL, there is the possibility of data loss in the case of a
RegionServer failure before each MemStore is flushed and new StoreFiles are written. HLog is the
HBase WAL implementation, and there is one HLog instance per RegionServer.
Note:
In computer science, write-ahead logging (WAL) is a family of techniques for providing atomicity
and durability (two of the ACID properties) in database systems.

In a system using WAL, all modifications are written to a log before they are applied. Usually both
redo and undo information is stored in the log.
The purpose of this can be illustrated by an example. Imagine a program that is in the middle of
performing some operation when the machine it is running on loses power. Upon restart, that
program might well need to know whether the operation it was performing succeeded, halfsucceeded, or failed. If a write-ahead log were used, the program could check this log and
compare what it was supposed to be doing when it unexpectedly lost power to what was actually
done. On the basis of this comparison, the program could decide to undo what it had started,
complete what it had started, or keep things as they are.
WAL allows updates of a database to be done in-place. Another way to implement atomic updates
is with shadow paging, which is not in-place. The main advantage of doing updates in-place is that
it reduces the need to modify indexes and block lists.