[
https://issues.apache.org/jira/browse/PHOENIX-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5651:
-----------------------------------
Fix Version/s: 5.1.0
> IndexScrutiny does not handle TTL/row-expiry
> --------------------------------------------
>
> Key: PHOENIX-5651
> URL: https://issues.apache.org/jira/browse/PHOENIX-5651
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.1, 4.14.3
> Reporter: Priyank Porwal
> Assignee: Swaroopa Kadam
> Priority: Major
> Fix For: 5.1.0, 4.15.1, 4.16.0
>
> Attachments: PHOENIX-5651.4.x-HBase-1.3.patch,
> PHOENIX-5651.4.x-HBase-1.3.v1.patch, PHOENIX-5651.4.x-HBase-1.3.v2.patch,
> PHOENIX-5651.master.v1.patch, PHOENIX-5651.master.v2.patch
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> If a data-table has TTL on it, it's indexes inherit the TTL too. Hence when
> we run IndexScrutiny on such tables and it's indexes, scrutiny's attempts to
> find matching index rows for near-expiry data rows results in no-matches
> since the index row gets expired before the read from data-region mapper. The
> same happens in the MR job for the other direction Index->Data.
> This does not impact correctness of indexing design, but makes it very
> inconvenient to get a clean scrutiny run. All reported invalid rows have to
> be matched against the table TTL, which is non-trivial exercise.
> IndexScrutiny itself could detect such expired rows when the matching pair is
> not found and not report them as INVALID_ROWS. Perhaps a new counter for
> EXPIRED_ROWS should be added as well for better visibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
