hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vladrodio...@gmail.com>
Subject Re: [DISCUSSION] Items to purge from branch-2 before we cut hbase-2.0.0-beta1.
Date Thu, 02 Nov 2017 17:31:38 GMT
>>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."

I am waiting for response from feature requester on what they expect from
verification.
Until then, I would rephrase my statement: "I do not see how we can perform
correct verification ..."

On Thu, Nov 2, 2017 at 9:20 AM, Stack <stack@duboce.net> wrote:

> 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