[
https://issues.apache.org/jira/browse/HBASE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-1880.
--------------------------
Fix Version/s: 0.21.0
Resolution: Fixed
OK Clint. I see the HStore edits now. I was looking for the HRegion changes.
HRegion seems to have evolved significantly from when your patch was applied.
I can see ghost outlines of what you added in HRegion. Resolving. We can open
new issue if this still an issue. Thanks.
> DeleteColumns are not recovered properly from the write-ahead-log
> -----------------------------------------------------------------
>
> Key: HBASE-1880
> URL: https://issues.apache.org/jira/browse/HBASE-1880
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.20.0, 0.20.1, 0.21.0
> Reporter: Clint Morgan
> Priority: Critical
> Fix For: 0.21.0
>
> Attachments: 1880-v2.patch, 1880-v3.patch, 1880-v4.patch, 1880.patch
>
>
> I found a couple of issues:
> - The timestamp is being set to now after it has been written to the wal. So
> if the WAL was flushed on that write, it gets in with ts of MAX_INT and is
> effectively lost.
> - Even after that fix, I had issues getting the delete to apply properly. In
> my case, the WAL had a put to a column, then a DeleteColumn for the same
> column. The DeleteColumn KV had a later timestamp, but it was still lost on
> recovery. I traced around a bit, and it looks like the current approach of
> just using an HFile.writer to write the set of KVs read from the log will not
> work. There is special logic in MemStore for deletes that needs to happen
> before writing. I got around this by just adding to memstore in the log
> recovery process. Not sure if there are other implications of this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
