hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
Date Tue, 30 Jan 2018 00:50:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344302#comment-16344302

stack commented on HBASE-17852:

{quote}The majority of this code (but not all) went into master in HBASE-19568 btw.
The majority of 'HBASE-17852 Add Fault tolerance to HBASE-14417 (Support bulk loaded files
in incremental backup)', a contentious issue, went into another commit named 'HBASE-19568 Restore
of HBase table using incremental backup doesn't restore rows from an earlier incremental backup'
with no outline of what made it and what did not, and no changeset explaination. There is
no release note. The two JIRAs are not even linked.
{quote}Nope, it turned out that this patch (HBASE-17852) also fixes the issue raised in HBASE-19568,
that is why it was committed (with refactoring code stripped down). No conspiracy here. 
But hang on, now the patch here on 'fault tolerance' fixes issues over in the 'restore rows'
issue, -HBASE-19568?-

I can see how [~appy] might arrive at his assessment.

On the 'declarations', the first offers options free of context or explanation.

This one I find interesting:

 # Use procedure framework:  Short answer - no. I will wait until procv2 becomes more mature
and robust. I do not want to build new feature on a foundation of a new feature. Too risky
in my opinion. NO

....when we are talking about a hbase3 (possibly) feature and when there is no alternative.

Anyway, keeping it short.


> Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
> ------------------------------------------------------------------------------------
>                 Key: HBASE-17852
>                 URL: https://issues.apache.org/jira/browse/HBASE-17852
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>            Priority: Major
>             Fix For: 3.0.0
>         Attachments: HBASE-17852-v10.patch, screenshot-1.png
> Design approach rollback-via-snapshot implemented in this ticket:
> # Before backup create/delete/merge starts we take a snapshot of the backup meta-table
(backup system table). This procedure is lightweight because meta table is small, usually
should fit a single region.
> # When operation fails on a server side, we handle this failure by cleaning up partial
data in backup destination, followed by restoring backup meta-table from a snapshot. 
> # When operation fails on a client side (abnormal termination, for example), next time
user will try create/merge/delete he(she) will see error message, that system is in inconsistent
state and repair is required, he(she) will need to run backup repair tool.
> # To avoid multiple writers to the backup system table (backup client and BackupObserver's)
we introduce small table ONLY to keep listing of bulk loaded files. All backup observers will
work only with this new tables. The reason: in case of a failure during backup create/delete/merge/restore,
when system performs automatic rollback, some data written by backup observers during failed
operation may be lost. This is what we try to avoid.
> # Second table keeps only bulk load related references. We do not care about consistency
of this table, because bulk load is idempotent operation and can be repeated after failure.
Partially written data in second table does not affect on BackupHFileCleaner plugin, because
this data (list of bulk loaded files) correspond to a files which have not been loaded yet
successfully and, hence - are not visible to the system 

This message was sent by Atlassian JIRA

View raw message