Phil Yang has moved on. However we have already used this feature in our
production cluster. It has some problem but basically works. Let me find
another person to pick this issue up and document it.
Thanks.
2017-11-08 7:10 GMT+08:00 Sean Busbey :
> How about serial replication?
>
> https://issu
How about serial replication?
https://issues.apache.org/jira/browse/HBASE-9465
It's an important feature. Closes a significant gap in our DR replication.
But despite making a big change to how our replication works, it's got
no docs. issue been sitting around for ~8 months:
https://issues.apach
Hello,
> There is no way to validate correctness of backup in a general case.
If there is no way to validate correctness, can we trust them ?
> I am waiting for response from feature requester on what they expect from
verification.
A client using hbase backups should be able to justify its custo
On doc,
We have great doc attached to HBASE-7912 (unfortunately, it is a little bit
obsolete now)
On Thu, Nov 2, 2017 at 10:31 AM, Vladimir Rodionov
wrote:
> >>To be clear, I wasn't listing requirements. I was having trouble with
> the
> >>absolute "There is no way to validate correctness of ba
>>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 n
On Thu, Nov 2, 2017 at 5:51 AM, Josh Elser wrote:
> On 11/1/17 11:33 PM, Stack wrote:
>
>> On Wed, Nov 1, 2017 at 5:08 PM, Vladimir Rodionov
>> 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 row
On 11/1/17 11:33 PM, Stack wrote:
On Wed, Nov 1, 2017 at 5:08 PM, Vladimir Rodionov
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? W
That's quite a good argument :) -- there's a difference between
occasional verification for building confidence and full data
verification for every, single, backup (which is how HBASE-19106 read to
me). I still think the latter (thus, 19106, verbatim in its ask) would
be unwieldy; however, the
For what it’s worth, I tried to help doc this feature near the start of my
time working on hbase multiple years ago and got no reply or feedback from
the devs. There are existing JIRAs. Since there was no information, I wrote
the existing docs to give operators and admins *some* path forward for s
On Wed, Nov 1, 2017 at 5:08 PM, Vladimir Rodionov
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
Potential adopters will absolutely want to construct for themselves a
verifiable live exercise. Tooling that lets you do that against a snapshot
would be the way to go, I think. Once you do that exercise, probably a few
times, you can trust the backup solution enough for restore into production,
On Wed, Nov 1, 2017 at 7:45 PM, Josh Elser wrote:
> (This one has been sitting on my mind while doing some non-computer-y
> things this evening; admittedly, in an attempt to NOT think about it. Go
> figure. Let me add to Vlad's previous)
>
> I want to say I still respect that it's the RM's prerog
On 11/1/17 8:22 PM, Sean Busbey wrote:
On Wed, Nov 1, 2017 at 7:08 PM, Vladimir Rodionov
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
(This one has been sitting on my mind while doing some non-computer-y
things this evening; admittedly, in an attempt to NOT think about it. Go
figure. Let me add to Vlad's previous)
I want to say I still respect that it's the RM's prerogative to be the
hammer on what makes a release and what d
Pulling B&R off 2.0 release 5-6 weeks in advance (beta1 timeframe)?
I would say that we have enough time to run scalability tests and finish
doc before beta1 release.
Can we return to this discussion in a 4-5 weeks and then, based on the B&R
state, make a decision?
-Vlad
On Wed, Nov 1, 2017 at
Hurm. Operator facing documentation is a blocker, IMHO, on a feature
being ready to ship. Incomplete documentation is part of why we're
pulling the Spark integration from 2.0. Good documentation takes a
large amount of work. The fact that there's no docs in the guide
already makes me think this nee
For DLR, serial repication is not compatible with DLR as DLR will introduce
holes in sequence id when opening region then serial replication will be
stuck. If we want to get DLR back then we need to find out how to deal with
serial replication first.
2017年11月2日星期四，Stack 写道：
> I want to purge the
Sean
No, this is not our backup description, it is pre-backup era guideline how
to do backup in HBase, using snapshots, copy table etc.
On Wed, Nov 1, 2017 at 5:28 PM, Sean Busbey wrote:
> Vlad,
>
> As someone who hasn't spent much time with the backup/restore feature
> yet, could you help me
Vlad,
As someone who hasn't spent much time with the backup/restore feature
yet, could you help me out on getting a foothold?
Which of these Backup/Restore options is it we're specifically talking about:
http://hbase.apache.org/book.html#ops.backup
On Wed, Nov 1, 2017 at 1:33 PM, Vladimir Rod
On Wed, Nov 1, 2017 at 7:08 PM, Vladimir Rodionov
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 d
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.
Your results mo
As for HBASE-19106, when someone says that it's fundamental, i think they
mean that some kind of validation that backup is correct is necessary, and
i concur.
Saying that something wasn't in initial feature list is hardly a
justification! It's not like the idea was known when initial list was
plann
Came here just to track anything related to Distributed Log Replay which I
am trying to purge. But looks like it's another discussion thread about
hbase-backup.
Am coming here with limited knowledge about the feature (did a review
initially once, lost track after). But then, looks like discussion i
>> HBASE-19106 at least is a fundamental
This new feature was requested 9 days ago (between alpha 3 and alpha 4
releases) It has never been on a list of features we has agreed to
implement for 2.0 release.
When backup started almost 2 years ago, we described what features and
capabilities will be
On 11/1/17 5:52 PM, Stack wrote:
On Wed, Nov 1, 2017 at 12:25 PM, Vladimir Rodionov
wrote:
1. HBASE-19104 - 19109
None of them are basic, Stack. These requests came from SF after discussion
we had with them recently
No single comments is because I was out of country last week.
2. Backup table
On Wed, Nov 1, 2017 at 12:25 PM, Vladimir Rodionov
wrote:
> >>I've not done in-depth research so could be wrong about backup, but from
> my
> >>perch, I've seen the recent filings against backup, HBASE-19104-19109,
> >>which strike me as pretty basic missing facility. The new issues go
> without
On 11/1/17 4:00 PM, Sean Busbey wrote:
On Wed, Nov 1, 2017 at 1:53 PM, Josh Elser wrote:
On 11/1/17 1:32 PM, Stack wrote:
hbase-spark: Purging this makes me tear-up.
We had a talk about this a while back, didn't we? I forget if we had
consensus about having it follow its own release s
On Wed, Nov 1, 2017 at 1:53 PM, Josh Elser wrote:
>
>
> On 11/1/17 1:32 PM, Stack wrote:
>>
>
>> hbase-spark: Purging this makes me tear-up.
>
>
> We had a talk about this a while back, didn't we? I forget if we had
> consensus about having it follow its own release schedule (rather than tying
> i
On 11/1/17 3:25 PM, Vladimir Rodionov wrote:
I've not done in-depth research so could be wrong about backup, but from
my
perch, I've seen the recent filings against backup, HBASE-19104-19109,
which strike me as pretty basic missing facility. The new issues go
without
comment (caveat a single
>> That's not true, we found issues and filed JIRAs. As to how significant
>> they are or not, I defer to the JIRAs for discussion.
Majority of JIRAs filed are trivial. If you do not agree, please post a
link to bugs you consider serious.
The rest are requests for *new functionality* which SF need
>>I've not done in-depth research so could be wrong about backup, but from
my
>>perch, I've seen the recent filings against backup, HBASE-19104-19109,
>>which strike me as pretty basic missing facility. The new issues go
without
>>comment (caveat a single question). I've seen no evidence of extensi
> Can you explain please how did you guys manage to file multiple JIRAs
(trivials mostly) without testing backup/restore?
What the fuck, Vlad.
Obviously we did some testing.
You said "Salesforce team has conducted independent testing and found no
issues with a functionality to my best knowledge.
On 11/1/17 3:00 PM, Stack wrote:
Now that I'm thinking about it, I wonder if that's actually the proper
route forward for hbase-native-client too...
And backup?
For argument's sake, yes, that could be a route forward for it.
Architecturally, it could/should be no different than Phoenix: use
>>I dont' want to get drawn into another unfriendly argument, but this is
>>simply not true. We filed a bunch of JIRAs including one with serious
>>concerns about scalability.
Can you explain please how did you guys manage to file multiple JIRAs
(trivials mostly)
without testing backup/restore?
W
On Wed, Nov 1, 2017 at 11:53 AM, Josh Elser wrote:
>
>
> On 11/1/17 1:32 PM, Stack wrote:
>
>> I want to purge the below list of modules, features, and abandoned code
>> from branch-2 before we make a beta-1 (4-5 weeks I'm thinking). Lets
>> discuss. Some are already scheduled for removal but lis
On Wed, Nov 1, 2017 at 11:33 AM, Vladimir Rodionov
wrote:
> >> hbase-backup: Not done and it doesn't look like it will be done for
> beta-1.
> >>It can come in later in a 2.1 or 3.0 when it is finished.
>
> That is not correct. All blockers have been resolved, the last one has a
> patch which is
On 11/1/17 1:32 PM, Stack wrote:
I want to purge the below list of modules, features, and abandoned code
from branch-2 before we make a beta-1 (4-5 weeks I'm thinking). Lets
discuss. Some are already scheduled for removal but listing anyways for
completeness sake. Pushback or other suggestions
> Salesforce team has conducted independent testing and found no issues
with a functionality to my best knowledge.
I dont' want to get drawn into another unfriendly argument, but this is
simply not true. We filed a bunch of JIRAs including one with serious
concerns about scalability.
On Wed, Nov
>> hbase-backup: Not done and it doesn't look like it will be done for
beta-1.
>>It can come in later in a 2.1 or 3.0 when it is finished.
That is not correct. All blockers have been resolved, the last one has a
patch which is ready to be commited.
Salesforce team has conducted independent testin
I want to purge the below list of modules, features, and abandoned code
from branch-2 before we make a beta-1 (4-5 weeks I'm thinking). Lets
discuss. Some are already scheduled for removal but listing anyways for
completeness sake. Pushback or other suggestions on what else we should
remove are wel
40 matches
Mail list logo
