Great, and I changed my vote to -0 because Stack made a good argument that making more changes would invalidate review up to this point, and I trust this will be resolved before release.
On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser <els...@apache.org> wrote: > Sorry Andrew, let me clarify as that didn't come out right. > > I didn't mean that isn't a conversation worth having _now_, just that I > was intentionally avoiding it in my previous email because I didn't > understand the scope of those issues that Vlad had identified. I wanted to > better understand what they were really meant for a user before coming to > my own decision about whether or not I think they are blockers. > > That aside, I would agree with you that HBASE-15227 sounds like a real > blocker. Forcing a new full backup for every table sounds really bad -- > that's not the kind of experience we'd want a user to have. > > Andrew Purtell wrote: > >> I'm going to intentional avoid addressing the discussion of shipping >>> >> partial features (related, but not relevant at the moment). >> >> Then we are not having the same conversation, because it is precisely >> because this is a vote for this feature to go into 2.0, which is already >> overdue, so should be released yesterday, that I took mention of "blocker" >> at face value. At least one of them seems to certainly approach this >> definition. It will be not user friendly, to say the least, to use this in >> a large scale deployment with HBASE-15227 unfinished. HBASE-15227 >> currently >> has a severity of BLOCKER. Despite what is going on in our politics, words >> matter and we do not get to redefine them for convenience. >> >> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0? >> Because Vlad offered to reduce its severity to make me feel better? >> Currently the description on the issue is "System must be tolerant to >> faults. Backup operations MUST be atomic (no partial completion state in >> system table)" Sounds like a blocker to me, indeed. It is an honest >> assessment and I don't think anyone is doing the community a favor by >> trying to walk that back. >> >> >> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<els...@apache.org> wrote: >> >> I took a moment to read through the "blockers" as originally identified by >>> Vlad, and (to echo Enis' take) I read the majority of them as being >>> blockers not for the next release, but for a "full-fledged feature". I'm >>> going to intentional avoid addressing the discussion of shipping partial >>> features (related, but not relevant at the moment). >>> >>> HBASE-15227 is actually the one that bothers me the most, with >>> HBASE-17133 >>> coming in close behind. Vlad, is there any documentation you can point me >>> to about what the current issues are with the current implementation? For >>> example, what happens now if the system has some kind of "partial >>> completion state"? >>> >>> Documentation is one of those that is really hard to judge. We want to >>> get >>> this code out for people to use (and to free up our strained dev >>> resources), but what good is some feature if the docs are >>> missing/incomplete? >>> >>> I think I could stomach the docs being inaccurate (with a clear >>> disclaimer >>> that the chapter is incomplete -- that's a 5min task). But, I think I >>> need >>> an answer about how the feature handles our common dist-sys category of >>> problems before I can consider whether I'm ok with the feature hitting >>> 2.0... >>> >>> I'll also try to throw up a few nodes and play with it to address the >>> problem as an (ignorant) user ;) >>> >>> >>> Andrew Purtell wrote: >>> >>> I don't like that issues were identified as "blockers" but now there is >>>> an >>>> attempt to walk that back. >>>> >>>> I don't like that development of this feature has lingered for a long >>>> time >>>> in this unfinished state when this work could have been done by now, now >>>> that we are trying to get a 2.0 out the door. Because this is a >>>> volunteer >>>> project I cannot make any demand that it should be done, but I can >>>> certainly look at the current state and be nonplussed. This will be yet >>>> another half finished thing in 2.0 when this merge happens. Promises to >>>> finish the unfinished work are nice but not currency. Commits are >>>> currency. >>>> I hope at least the fault tolerance changes can be completed and >>>> committed >>>> before we spin a 2.0 RC, and without causing a 2.0 release to slip >>>> further. >>>> >>>> Also, marking something experimental should be done on the merits of >>>> that >>>> evaluation, not simply to justify dropping unfinished work into a >>>> release >>>> branch. >>>> >>>> I will change my vote to -0. >>>> >>>> >>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<e...@apache.org> >>>> wrote: >>>> >>>> I think there is some misconception of using the term "blockers" for >>>> >>>>> referring to those jiras. My understanding is that those three jiras >>>>> are >>>>> blockers for the backup functionality to be more mature and more >>>>> usable. >>>>> But they are not release blockers. Let's say we merged the code in, and >>>>> for >>>>> some reason those did not get addressed in time. We can still do the >>>>> 2.0 >>>>> release without having to wait for the commits. We can instead mark the >>>>> "backup" feature as experimental with known issues and go on with the >>>>> release. In that sense they are not real release blockers. >>>>> >>>>> We are proposing the merge at this time because of the above that >>>>> maintaining this in a branch is becoming extremely costly and not >>>>> productive for the HBase community. Realistically, we cannot have the >>>>> luxury of having to wait another couple of months and doing yet another >>>>> giant round of reviews because the code base is a moving target. >>>>> >>>>> Enis >>>>> >>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<d...@hortonworks.com> >>>>> wrote: >>>>> >>>>> Vlad, on the first point, I think what Stack is saying is that creating >>>>> >>>>>> the new branch (as Ted did) ignores the feedback incorporated thus far >>>>>> in >>>>>> the iterations of the mega-patch. That's a wrong way to go. >>>>>> On the separation into a backup module, again, that was reverted to >>>>>> ease >>>>>> reviews of the mega-patch, and was noted as work to be done later. I >>>>>> >>>>>> think >>>>> >>>>> Stack just wants to make the list of remaining work more complete by >>>>>> >>>>>> citing >>>>> >>>>> that as pending work. >>>>>> ________________________________________ >>>>>> From: Vladimir Rodionov<vladrodio...@gmail.com> >>>>>> Sent: Monday, March 13, 2017 3:09 PM >>>>>> To: dev@hbase.apache.org >>>>>> Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing >>>>>> 3/11/2017 >>>>>> >>>>>> It ignores the feedback >>>>>> >>>>>>> If I "ignore" feedback, I put my comment - why? I am always open for >>>>>>> >>>>>> further discussions. If reviewer does not insist on a particular >>>>>> request >>>>>> >>>>>> - >>>>> >>>>> it will be dropped. I think it is fair. >>>>>> >>>>>> he list is incomplete because a bunch of >>>>>> >>>>>>> follow-ons came of the review cycle (including moving backup/restore >>>>>>>> >>>>>>>> out >>>>>>> >>>>>> of >>>>>> >>>>>> core to live in its own module). >>>>>>> For those who were not following our lengthy conversation on a review >>>>>>> >>>>>> board, separation of a backup code into a separate module has been >>>>>> done last year, but has been reverted back by request of a reviewer. >>>>>> >>>>>> >>>>>> -Vladimir >>>>>> >>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote: >>>>>> >>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote: >>>>>> >>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yuzhih...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> HBASE-14123 branch has been created, with Vlad's mega patch v61. >>>>>>>> >>>>>>>>> The patch put up for VOTE here was done on a branch. The call to >>>>>>>>> >>>>>>>> merge >>>>>>> >>>>>> seems to have been premature given the many cycles of review and test >>>>>> >>>>>>> that >>>>>>> >>>>>>> happened subsequent (The cycles burned a bunch of dev resource). >>>>>>>> >>>>>>>> The patch as is is now in a state where it is too big for our infra; >>>>>>>> >>>>>>>> rb >>>>>>> >>>>>> and JIRA are creaking under the size and # of iterations. >>>>>> >>>>>>> Adding finish of new JIRAs to this merge implies a new round of >>>>>>>> >>>>>>>> review >>>>>>> >>>>>> and >>>>>> >>>>>>> test of an already massive patch. Who is going to do this work? >>>>>>>> >>>>>>>> Going back to a new branch seems wrong route to take. >>>>>>>> >>>>>>>> St.Ack >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> To be more explicit, this patch was developed on a branch and then a >>>>>>>> >>>>>>> bunch >>>>>> >>>>>> of dev resources were burned getting it into a state where it could be >>>>>>> merged to master. Going back to a branch to bulk up the merge so it >>>>>>> includes more JIRAs than the many it already incorporates is the >>>>>>> wrong >>>>>>> direction for us to be headed in. It ignores the feedback given and >>>>>>> the >>>>>>> work done by Vladimir slimming down an already over-broad scope. It >>>>>>> is >>>>>>> >>>>>>> also >>>>>> >>>>>> predicated on abundant review and testing resource being on tap to >>>>>>> >>>>>>> cycle >>>>>> on >>>>>> >>>>>> a feature that is useful, but non-core. >>>>>>> >>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what >>>>>>> is >>>>>>> still to do though IIRC, the list is incomplete because a bunch of >>>>>>> follow-ons came of the review cycle (including moving backup/restore >>>>>>> >>>>>>> out >>>>>> of >>>>>> >>>>>> core to live in its own module). >>>>>>> >>>>>>> The patch needs three votes to merge. I am not against merge but I am >>>>>>> >>>>>>> not >>>>>> voting for the patch because I do have any more time to spend on this >>>>>> >>>>>>> non-core feature and feel that a vote will have me assume a >>>>>>> >>>>>>> responsibility >>>>>> >>>>>> I will not shirk. >>>>>>> >>>>>>> S >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> FYI >>>>>>>> >>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yuzhih...@gmail.com> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>> >>>>>>> Thanks for the feedback, Andrew. >>>>>> >>>>>>> How about the following plan: >>>>>>>>>> >>>>>>>>>> create branch HBASE-14123 off of master with mega patch v61 as the >>>>>>>>>> >>>>>>>>>> first >>>>>>>>> >>>>>>>> commit (reviewed by Stack and Enis) >>>>>>>> >>>>>>>>> Vlad and I continue development (the 3 blockers) based on >>>>>>>>>> >>>>>>>>>> HBASE-14123 >>>>>>>>> >>>>>>>> branch >>>>>>> >>>>>>>> when all of the blockers get +1 and merged into HBASE-14123 >>>>>>>>>> >>>>>>>>>> branch, >>>>>>>>> >>>>>>>> we >>>>>> >>>>>> propose to community for merging into branch-2 (master branch, if >>>>>>> >>>>>>>> branch-2 >>>>>>>>> >>>>>>>>> doesn't materialize for whatever reason) again >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell< >>>>>>>>>> >>>>>>>>>> apurt...@apache.org> >>>>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>>>> Thanks for the offer but I like that you were honest about >>>>>>>>>> compiling >>>>>>>>>> >>>>>>>>> a >>>>>>> >>>>>>> list >>>>>>>> >>>>>>>>> of issues that you thought were blockers for release. Since this >>>>>>>>>>> >>>>>>>>>>> proposal >>>>>>>>>> is a merge into 2.0, and we are trying to release 2.0, I am -1 on >>>>>>>>>> this >>>>>>>>>> >>>>>>>>> merge until those blockers are addressed. >>>>>>>> >>>>>>>>> I had a look at the list. >>>>>>>>>>> >>>>>>>>>>> I think the documentation issue is important but not actually a >>>>>>>>>>> >>>>>>>>>>> blocker. >>>>>>>>>> That may be a controversial opinion, but documentation can be >>>>>>>>>> back-filled >>>>>>>>>> worst case. So take HBASE-17133 off the list. >>>>>>>>>> >>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and >>>>>>>>>>> >>>>>>>>>>> HBASE-15227. >>>>>>>>>> >>>>>>>>> They >>>>>>> >>>>>>>> all have patches attached to the respective JIRAs so completing >>>>>>>>>> this >>>>>>>>>> >>>>>>>>> work >>>>>>> >>>>>>>> won't be onerous. Get these committed and I will lift my -1. The >>>>>>>>>> others >>>>>>>>>> >>>>>>>>> who >>>>>>>> >>>>>>>>> voted +1 on this thread surely can help with that. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov< >>>>>>>>>>> vladrodio...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares >>>>>>>>>>> you, >>>>>>>>>>> >>>>>>>>>> Andrew >>>>>> >>>>>>> [image: [image: 🙂]] >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell< >>>>>>>>>>>> apurt...@apache.org >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>> >>>>>>>> I know the merge of this feature has lagged substantially. I >>>>>>>>>>>> think >>>>>>>>>>>> >>>>>>>>>>> that >>>>>>>> >>>>>>>>> is >>>>>>>>>>>> >>>>>>>>>>>> regrettable but on another thread we are lamenting that 2.0 >>>>>>>>>>>>> >>>>>>>>>>>>> is >>>>>>>>>>>> >>>>>>>>>>> already >>>>>> >>>>>>> late. Unless I misunderstand, this is a proposal to merge >>>>>>>>>> >>>>>>>>>>> something >>>>>>>>>>>> >>>>>>>>>>> with >>>>>>>> >>>>>>>>> known blockers into trunk before we branch it for 2.0 which >>>>>>>>>>>> will >>>>>>>>>>>> >>>>>>>>>>> effectively prevent that release because these blockers will >>>>>>> >>>>>>>> be >>>>>>>>>>>> >>>>>>>>>>> there. I >>>>>> >>>>>>> am >>>>>>>>>>>> >>>>>>>>>>>> inclined to veto. Probably we should not propose branch >>>>>>>>>>>>> >>>>>>>>>>>>> merges >>>>>>>>>>>> >>>>>>>>>>> into >>>>>> >>>>>>> code >>>>>>>> >>>>>>>>> we >>>>>>>>>>>> >>>>>>>>>>>> are trying to get out the door with known blockers. Why not >>>>>>>>>>>>> >>>>>>>>>>>>> do >>>>>>>>>>>> >>>>>>>>>>> that >>>>>> >>>>>>> work >>>>>>>> >>>>>>>>> first? It seems an obvious question. Perhaps I am missing >>>>>>>>>>>> something. >>>>>>>>>>>> >>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not >>>>>>>>>> >>>>>>>>>>> into >>>>>>>>>>>> >>>>>>>>>>> the >>>>>> >>>>>>> 2.0 >>>>>>>> >>>>>>>>> branch, I would vote +1 for branch merge even with known >>>>>>>>>> >>>>>>>>>>> blockers >>>>>>>>>>>> >>>>>>>>>>> pending. >>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov< >>>>>>>>>>>>> >>>>>>>>>>>>> vladrodio...@gmail.com> >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> They are not blockers for merge - only for 2.0. GA >>>>>>>>>>>>> >>>>>>>>>>>>>> As I said already the feature is usable right now >>>>>>>>>>>>>> We would like to continue working on master and we would >>>>>>>>>>>>>> >>>>>>>>>>>>>> like >>>>>>>>>>>>> >>>>>>>>>>>> to >>>>>> >>>>>> see >>>>>>> >>>>>>>> a >>>>>>>>>> >>>>>>>>>>> commitment from community >>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 10, 2017, at 11:16 AM, Andrew Purtell< >>>>>>>>>>>>>> >>>>>>>>>>>>>> apurt...@apache.org >>>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 >>>>>>>>>>>>> >>>>>>>>>>>>>> release. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> If we have identified blockers, why merge this before they >>>>>>>>>> >>>>>>>>>>> are >>>>>>>>>>>>>> >>>>>>>>>>>>> in? >>>>>>> >>>>>>>> Otherwise we can't release 2.0, and it is overdue. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov< >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> vladrodio...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, HBase folks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For your consideration today is Backup/Restore feature for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>> >>>>>>>>>>>>>> HBAse >>>>>>>>>> >>>>>>>>>>> 2.0. >>>>>>>>>>>>> >>>>>>>>>>>>>> Backup code is available as a mega patch in HBASE-14123 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (v61), >>>>>>>>>>>>>>> >>>>>>>>>>>>>> applies >>>>>>> >>>>>>>> cleanly to the current master, all test PASS, patch has no >>>>>>>>>>>> >>>>>>>>>>>>> other >>>>>>>>>>>>>>> >>>>>>>>>>>>>> issues. >>>>>>>> >>>>>>>>> The patch has gone through numerous rounds of code reviews >>>>>>>>>>>>> >>>>>>>>>>>>>> and >>>>>>>>>>>>>>> >>>>>>>>>>>>>> has >>>>>>> >>>>>>>> probably >>>>>>>>>> >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA >>>>>>>>>>>>>>> (HBASE-14123) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> :) >>>>>>>> >>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123, >>>>>>>>>> >>>>>>>>>>> 14414) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Two >>>>>>>>>> >>>>>>>>>>> first >>>>>>>>>>>> >>>>>>>>>>>>> are complete, third one is still in progress. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>> hbase >>>>>>> >>>>>>>> command >>>>>>>>>> >>>>>>>>>>> and, from the client side, is accessible through >>>>>>>>>>>>>>> command-line >>>>>>>>>>>>>>> >>>>>>>>>>>>>> only >>>>>>> >>>>>>>> Operations: >>>>>>>>>> >>>>>>>>>>> * Create full backup on a list of tables or backup set >>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> set >>>>>>>>>>>>>>> >>>>>>>>>>>>>> * Restore list of tables from a given backup image >>>>>>> >>>>>>>> * Show current backup progress >>>>>>>>>>>>>>>> * Delete backup image and all related images >>>>>>>>>>>>>>>> * Show history of backups >>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> table >>>>>>>>>>>>>>> >>>>>>>>>>>>>> to/from >>>>>> >>>>>>> backup >>>>>>>>>>>> >>>>>>>>>>>>> set, etc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In the current implementation, the feature is already >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> usable, >>>>>>>>>>>>>>> >>>>>>>>>>>>>> meaning >>>>>>> >>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>>> users can backup tables and restore them using provided >>>>>>>>>>>>>>> command-line >>>>>>>>>>>>>>> >>>>>>>>>>>>>> tools. >>>>>>>>>>>> >>>>>>>>>>>>> Both: full and incremental backups are supported. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This work is based on original work of IBM team >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (HBASE-7912). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> The >>>>>>> >>>>>>>> full >>>>>>>>>> >>>>>>>>>>> list >>>>>>>>>>>> >>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three >>>>>>>>>>>>>>> umbrella >>>>>>>>>>>>>>> >>>>>>>>>>>>>> JIRAs: >>>>>>>>>> >>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and >>>>>>>>>>>>>>> HBASE-14414 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> (Phase 3 >>>>>> >>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> all >>>>>>>>>>>>> >>>>>>>>>>>>>> resolved ones made it into the patch) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *** What are the remaining work items >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> HBASE-14414. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR >>>>>>>>>>>>> >>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> ***** BLOCKER >>>>>>>>>> >>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> available) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup >>>>>>>>>>>> >>>>>>>>>>>>> images >>>>>>>>>>>>>>> >>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on >>>>>>>> >>>>>>>>> backup >>>>>>>>>>>>>>> >>>>>>>>>>>>>> to >>>>>>>>>> >>>>>>>>>>> include only edits from backup tables (Patch available) >>>>>>>>>>>> >>>>>>>>>>>>> * HBASE-17133 Backup documentation >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ***** CRITICAL >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> remaining >>>>>>>>>>>>>>> >>>>>>>>>>>>>> work >>>>>>> >>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state >>>>>>>>>> >>>>>>>>>>> will >>>>>>>>>>>>>>> >>>>>>>>>>>>>> be >>>>>>>> >>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it >>>>>>>>>> >>>>>>>>>>> depends >>>>>>>>>>>>>>> >>>>>>>>>>>>>> on >>>>>>>> >>>>>>>>> resource >>>>>>>>>> >>>>>>>>>>> availability >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> >>>>>>>>>>>>>> be >>>>>>>> >>>>>>>>> closed/deleted after the merge. >>>>>>>>>> >>>>>>>>>>> We want backup to be a GA feature in 2.0 >>>>>>>>>>>>>>>> We are going to support full backward compatibility for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> backup >>>>>>>>>>>>>>> >>>>>>>>>>>>>> tool in >>>>>>> >>>>>>>> 2.0 >>>>>>>>>>>> >>>>>>>>>>>>> and onwards. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> **** Configuration >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> >>>>>>>>>>>>>> configuration >>>>>> >>>>>>> properties must be added to hbase-site.xml: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> hbase.backup.enable=true >>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org. >>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner >>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org. >>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> LogRollMasterProcedureManager >>>>>>>>>>>>>>> >>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org. >>>>>>>> >>>>>>>>> apache.hadoop.hbase.backup.regionserver. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> LogRollRegionServerProcedureMa >>>>>>>>>>>>>>> >>>>>>>>>>>>>> nager >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> work, >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code >>>>>>> >>>>>>>> reviews >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Special thanks to Ted Yu for his co-development work. >>>>>>> >>>>>>>> References: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (original >>>>>>>>>>>>>>> >>>>>>>>>>>>>> IBM, >>>>>> >>>>>>> contains >>>>>>>> >>>>>>>>> design doc) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase >>>>>> >>>>>>> 2) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase >>>>>> >>>>>>> 3) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00 >>>>>> >>>>>>> -0800 GMT) on March 11th on whether or not we should >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> merge >>>>>>>>>>>>>>> >>>>>>>>>>>>>> this >>>>>> >>>>>>> into >>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>>> current master. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Vladimir Rodionov >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Andy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you are given a choice, you believe you have acted >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> freely. - >>>>>>>>>>>>>> >>>>>>>>>>>>> Raymond >>>>>>> >>>>>>>> Teller (via Peter Watts) >>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> - Andy >>>>>>>>>>>>> >>>>>>>>>>>>> If you are given a choice, you believe you have acted >>>>>>>>>>>>> >>>>>>>>>>>>> freely. - >>>>>>>>>>>> >>>>>>>>>>> Raymond >>>>>> >>>>>>> Teller (via Peter Watts) >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> - Andy >>>>>>>>>>> >>>>>>>>>>> If you are given a choice, you believe you have acted freely. - >>>>>>>>>>> >>>>>>>>>>> Raymond >>>>>>>>>> >>>>>>>>> Teller (via Peter Watts) >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>> >>>> >> >> -- Best regards, - Andy If you are given a choice, you believe you have acted freely. - Raymond Teller (via Peter Watts)
