[
https://issues.apache.org/jira/browse/HBASE-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-1761:
-------------------------
Attachment: 1761-v4.patch
This patch works. Review please though its kinda tough to do.
Added tests. It simplifies the whole getClosestAtOrBefore cutting out loads of
superfluous (seeming) code. Now we don't keep open a wide range of possible
candidates and deletes as we worm down through memstore and storefiles, instead
we go for the wanted row and stop trying if we go past current candidate. We
only replace candidate if new one is better (close).
Tries to make the logic same in memstore as it is in store for storefile but
the scanner in hfile fights against us. We need to flip it so it scans to
asked-for-row or just after rather than just before as it does now.. The just
before was done to support getClosest originally and it was optimal when old
style deletes where a delete shadowed the thing it was deleting -- same r/c/ts
coordinates -- but with new deletes where delete family is first-in-row, then
we have to back up too far to be sure we get all elements in the row.
> getclosest doesn't understand delete family; manifests as "HRegionInfo was
> null or empty in .META" A.K.A the BS problem
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1761
> URL: https://issues.apache.org/jira/browse/HBASE-1761
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: stack
> Fix For: 0.20.0
>
> Attachments: 1761-v2.patch, 1761-v3.patch, 1761-v4.patch, 1761.patch
>
>
> getclosestatorbefore was not converted to deal with the new delete types. It
> only knows how to process old style deletes. Usually all is well as edits
> come in but its possible to get into state where you have persisted in one
> file a deletefamily for all in meta and in the file behind it, there are
> entries on the info family. Since closest doesn't understand deletefamily,
> it will return the Put rows only for the subsequent getfull, which knows how
> to work with deletefamilies fail.
> Once this happens, table is hosed. Seen on Bradford Stephens upload and at
> Powerset. "Fix" is flush and major compact. Gives impression that hbase is
> 'delicate'. Fixing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
