[
https://issues.apache.org/jira/browse/HBASE-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256861#comment-13256861
]
stack commented on HBASE-5547:
------------------------------
Is the problem in #1 the client waiting on acks from all the regionservers?
Does it need to do this? Can it not just set the state up in zk and then just
move on (You have this in your patch already if I remember rightly). Do you
want the RS's acknowledging that they have been set into backup mode? They
could set a flag up in zk but this gets torturous when say we add a new feature
that wants to do some thing similar.
If we had a dynamic Configuration system, one that didn't require roll of table
to set the table 'read-only' or 'in-back-up mode', would that help here?
One option #2, yeah, its a pain going to zk for each WAL when there is this
callback mechanism that all RS are subscribed to anyways. For sure could poll
zk the first time but should then cache the setting and only drop it later if a
callback says it changed.
Agree roll of table to set the backup flag is much too heavyweight.
> Don't delete HFiles when in "backup mode"
> -----------------------------------------
>
> Key: HBASE-5547
> URL: https://issues.apache.org/jira/browse/HBASE-5547
> Project: HBase
> Issue Type: New Feature
> Reporter: Lars Hofhansl
> Assignee: Jesse Yates
>
> This came up in a discussion I had with Stack.
> It would be nice if HBase could be notified that a backup is in progress (via
> a znode for example) and in that case either:
> 1. rename HFiles to be delete to <file>.bck
> 2. rename the HFiles into a special directory
> 3. rename them to a general trash directory (which would not need to be tied
> to backup mode).
> That way it should be able to get a consistent backup based on HFiles (HDFS
> snapshots or hard links would be better options here, but we do not have
> those).
> #1 makes cleanup a bit harder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
