You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2010/05/24 18:56:25 UTC

[jira] Resolved: (HBASE-1880) DeleteColumns are not recovered properly from the write-ahead-log

     [ 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.