Checking the WALs on HDFS, there are very old WALs, from a year ago... Does
anyone have any idea how to handle this issue in production?
-rw-r--r-- 2 hbase hadoop 20684288 2023-10-09 08:26
/hbase/oldWALs/rzv-db14-hd.%2C16020%2C1674973593505.1696810047993
-rw-r--r-- 2 hbase hadoop 15
Have you tried to read these WAL files by WALPrettyPrinter? What is
the error from WALPrettyPrinter while reading these files?
Hamado Dene 于2024年9月16日周一 16:15写道：
>
> Checking the WALs on HDFS, there are very old WALs, from a year ago... Does
> anyone have any idea how to handle this issue in pro
Thanks for your response.
If I try to read the WALs with the following command:
hbase org.apache.hadoop.hbase.wal.WALPrettyPrinter
/hbase/oldWALs/rzv-db13-hd.%2C16020%2C1684871532555.1696811057371
I don't get any error... The file seems to be read correctly. In fact, at the
end of the reading
The staktrace you posted is messed up so it is not easy to find out
which file actually blocks the replication progress...
Could you please double check the WAL file which blocks the
replication? Is it really one of these old WAL files?
Thanks.
Hamado Dene 于2024年9月16日周一 21:57写道：
>
> Thanks for
I deduced that it was one of the old WALs because, from the UI, I see that
these old WALs are not being replicated. However, I'll do another round of
checks to see if I can find something more. Would enabling debug help me find
more information?
Thanks again for your help.
Replication Status
Hi,
I am a newcomer to HBase, and I would like to ask about the behavior
of StoreScanner when scanning data. If the
`ScanQueryMatcher.compareKeyForNextColumn` receives a null ColumnHint,
the logic executed is completely the same as `compareKeyForNextRow`.
What is the benefit of doing this?
see:
