Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 23 May 2012 09:25:41 +0000 (UTC)
From: "chunhui shen (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1826663670.11000.1337765141818.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <525385461.2672.1337588621480.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Updated] (HBASE-6059) Replaying recovered edits would make
 deleted data exist again
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HBASE-6059?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

chunhui shen updated HBASE-6059:
--------------------------------

    Attachment: HBASE-6059v5.patch

Find the bug which cause TestShell failed.

Store#rowAtOrBeforeFromStoreFile=EF=BC=8C
we should do it considering empty store file now=EF=BC=8C else it will thro=
w NPW
{code}
Store#rowAtOrBeforeFromStoreFile
private void rowAtOrBeforeFromStoreFile(final StoreFile f,
                                          final GetClosestRowBeforeTracker =
state)
      throws IOException {
    StoreFile.Reader r =3D f.getReader();
    if (r =3D=3D null) {
      LOG.warn("StoreFile " + f + " has a null Reader");
      return;
    }
     }
+    if (r.getEntries() =3D=3D 0) {
+      LOG.warn("StoreFile " + f + " is a empty store file");
+      return;
+    }
    // TODO: Cache these keys rather than make each time?
    byte [] fk =3D r.getFirstKey();
{code}

Mmodify it in the patchV5 and passed the TestShell now.
               =20
> Replaying recovered edits would make deleted data exist again
> -------------------------------------------------------------
>
>                 Key: HBASE-6059
>                 URL: https://issues.apache.org/jira/browse/HBASE-6059
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: chunhui shen
>            Assignee: chunhui shen
>         Attachments: HBASE-6059-testcase.patch, HBASE-6059.patch, HBASE-6=
059v2.patch, HBASE-6059v3.patch, HBASE-6059v4.patch, HBASE-6059v5.patch
>
>
> When we replay recovered edits, we used the minSeqId of Store, It may cau=
se deleted data appeared again.
> Let's see how it happens. Suppose the region with two families(cf1,cf2)
> 1.put one data to the region (put r1,cf1:q1,v1)
> 2.move the region from server A to server B.
> 3.delete the data put by step 1(delete r1)
> 4.flush this region.
> 5.make major compaction for this region
> 6.move the region from server B to server A.
> 7.Abort server A
> 8.After the region is online, we could get the deleted data(r1,cf1:q1,v1)
> (When we replay recovered edits, we used the minSeqId of Store, because c=
f2 has no store files, so its seqId is 0, so the edit log of put data will =
be replayed to the region)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira