[
https://issues.apache.org/jira/browse/HBASE-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849738#action_12849738
]
Jonathan Gray commented on HBASE-2376:
--------------------------------------
The initial idea is that we'd introduce a new per-family configuration,
something like TTKAV (Time To Keep All Versions). This setting would define
how far back you would be able to perform this snapshot. In practice, it might
be something like 1 day or 1 week, but could be configured. This setting would
ensure that no versions are deleted until outside the TTKAV. Once outside that
range, the original TTL and MaxVersions settings would be enforced (on major
compactions).
The second piece would be a special SnapshotScanner that took a timestamp and
returned data as it was at that timestamp. This stamp would of course have to
be less than now() and greater than now() - TTKAV. It would have the smarts to
basically toss out anything with a newer stamp, including deletes.
The reason for introducing a new parameter is that you must keep all versions
of everything in order to perform the back-in-time snapshot, but you don't want
to force constraints on how you would use the normal maxVersions/TTL parameters
to clear out multiple versions of stuff during major compactions (once outside
the snapshotable time window).
> Add special SnapshotScanner which presents view of all data at some time in
> the past
> ------------------------------------------------------------------------------------
>
> Key: HBASE-2376
> URL: https://issues.apache.org/jira/browse/HBASE-2376
> Project: Hadoop HBase
> Issue Type: New Feature
> Components: client, regionserver
> Affects Versions: 0.20.3
> Reporter: Jonathan Gray
>
> In order to support a particular kind of database "snapshot" feature which
> doesn't require copying data, we came up with the idea for a special
> SnapshotScanner that would present a view of your data at some point in the
> past. The primary use case for this would be to be able to recover
> particular data/rows (but not all data, like a global rollback) should they
> have somehow been messed up (application fault, application bug, user error,
> etc.).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
