hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Devaraj Das (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
Date Wed, 09 Nov 2016 06:57:58 GMT

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

Devaraj Das commented on HBASE-14141:
-------------------------------------

[~vrodionov] is there a way in which we can reliably identify the WALs that need to be kept
track of, when a request for an incremental backup comes. Like, if there are multiple WALs,
and some of them are part of a backup set or something, and some are not, can we make that
distinction, and store the metadata about these. We could totally stay out of the business
of doing anything WAL specific, but we should just be able to query some metadata state about
which specific WALs we should back up when a request for an incremental backup comes... The
default implementation could be returning all the WALs that are currently present in the WAL
directory, and they are all backed up (this is what we have today).
I guess it's an extension to what you say above, but am trying to see if things can be simplified.
So am proposing we flip it around, and say that if someone wants to take backups, they need
to plan for it, and set up WALs appropriately.

> HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup
tables
> --------------------------------------------------------------------------------------------
>
>                 Key: HBASE-14141
>                 URL: https://issues.apache.org/jira/browse/HBASE-14141
>             Project: HBase
>          Issue Type: New Feature
>    Affects Versions: 2.0.0
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>              Labels: backup
>             Fix For: 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message