hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSSION] Items to purge from branch-2 before we cut hbase-2.0.0-beta1.
Date Thu, 02 Nov 2017 16:20:01 GMT
On Thu, Nov 2, 2017 at 5:51 AM, Josh Elser <elserj@apache.org> wrote:

> On 11/1/17 11:33 PM, Stack wrote:
>
>> On Wed, Nov 1, 2017 at 5:08 PM, Vladimir Rodionov<vladrodionov@gmail.com>
>> wrote:
>>
>> There is no way to validate correctness of backup in a general case.
>>>
>>> You can restore backup into temp table, but then what? Read rows
>>> one-by-one
>>> from temp table and look them up
>>>
>>
>>
>> in a primary table? Won't work, because rows can be deleted or modified
>>> since the last backup was done.
>>>
>>>
>>> Replication has a verity table tool.
>>
>> You can ask a cluster not delete rows.
>>
>> You can read at a specific timestamp.
>>
>> Or you could create backups during an extended ITBLL. When ITBLL
>> completes,
>> verify it on src cluster. Create a table from the increment backups.
>> Verify
>> in the restore.
>>
>> Etc.
>>
>> St.Ack
>>
>
> I can definitely see a benefit of a tool which verifies the data collected
> for a backup which:
>
> 1. Is batch in nature
> 2. Is ad-hoc (not intrinsically run for every backup session)
> 3. Relies/is-built on existing tooling (snapshots or other
> verification-like code)
>
> Thanks Stack. I think this is some good teasing of requirements from an
> otherwise very broad and untenable problem statement that we started with
> (which lead to the knee-jerk).
>

To be clear, I wasn't listing requirements. I was having trouble with the
absolute "There is no way to validate correctness of backup in a general
case." which is then seemingly being used to beat down any request for
verification tooling/testing that shows backup/restore works properly.
Good on you Josh,
S

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message