>
> Did you look read-side? It doesn't give up on a block that is without
> dictionary or a dictionary that is incomplete. It reads the compressed
> block w/o aid of dictionary anyways?
>
So as far as I see from this code (
https://github.com/apache/hbase/blob/7877e09b6023c80e8bacd25fb8e0b9273ed7d258/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALCellCodec.java#L171),
WAL compression isn't actually block based, it's entry based and the
dictionary doesn't need to be flushed explicitly as it's written out as
data is written. As I understand it goes something like this for
compression path:
1. if data is in LRU in-memory dictionary, it will return the index of it
to write to the WAL
2. if data is not in LRU dictionary, it will add the data to the
dictionary, increment index, but still return NOT_IN_DICTIONARY (
https://github.com/apache/hbase/blob/025ddce868eb06b4072b5152c5ffae5a01e7ae30/hbase-common/src/main/java/org/apache/hadoop/hbase/io/util/LRUDictionary.java#L53)
to be written to WAL with the length of data and data itself (which is
essentially the entry that encodes the dictionary in WAL)
Then, on the read path, it will recreate the dictionary as it reads the
stream:
1. if it sees NOT_IN_DICTIONARY, add it to dictionary and increment index
2. otherwise it's an index of previously added data entry already in the
dictionary, so it can just look it up there.
This is a pretty neat algorithm where it makes sure that the implicit
dictionary is always written out before the data, am I understanding it
correctly? I just fail to see where "we failed persist the amended
dictionary" part is coming from in the doc, there's no amendments that are
done anywhere in the code.
On Tue, Apr 21, 2020 at 6:18 PM Stack wrote:
> On Tue, Apr 14, 2020 at 1:16 PM Andrey Elenskiy
> wrote:
>
> > Hello,
> >
> > I'm trying to understand the extent of the following issue mentioned in
> > "WAL Compression" doc:
> https://hbase.apache.org/book.html#wal.compression
> >
> > A possible downside to WAL compression is that we lose more data from the
> > > last block in the WAL if it ill-terminated mid-write. If entries in
> this
> > > last block were added with new dictionary entries but we failed persist
> > the
> > > amended dictionary because of an abrupt termination, a read of this
> last
> > > block may not be able to resolve last-written entries.
> >
> >
> > Does it mean there's a potential data loss even if the clients of
> > regionserver received an ack?
>
>
>
> Yes.
>
> The ack to client says the data made it out to the WAL successfully, not if
> the last compressed block is properly terminated.
>
>
>
> > First mention of this issue I noticed here:
> >
> >
> https://issues.apache.org/jira/browse/HBASE-18504?focusedCommentId=16127767&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16127767
> > However, I couldn't find anything like that mentioned in the issue that
> > introduced the WAL compression (
> > https://issues.apache.org/jira/browse/HBASE-4608).
> >
> > I've also poked around the code of how compression is done (
> >
> >
> https://github.com/apache/hbase/blob/7877e09b6023c80e8bacd25fb8e0b9273ed7d258/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALCellCodec.java#L171
> > )
> > and not able to see how "failed to persist the amended dictionary" case
> can
> > happen. It seems like there's no explicit dictionary stored at all and
> > instead writing the data entries continuously records the dictionary on
> the
> > fly. If data is not in a dictionary it's written out explicitly so it
> > shouldn't be lost.
> >
> >
> I think the doc probably detached from implementation describing general
> block-based compression where decompress w/o dictionary is non-starter.
>
> Did you look read-side? It doesn't give up on a block that is without
> dictionary or a dictionary that is incomplete. It reads the compressed
> block w/o aid of dictionary anyways?
>
>
>
> > Could you please clarify the situation where data loss after receiving an
> > ack can happen when using wal compression?
> >
> >
> Hopefully above gives sense of how the deviance you are wallowing in came
> about.
>
> Good on you Andrey,
>
> S
>
>
>
>
> > Thanks,
> > Andrey
> >
>
