hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-50) Snapshot of table
Date Mon, 09 Aug 2010 12:12:23 GMT

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

HBase Review Board commented on HBASE-50:
-----------------------------------------

Message from: "Chongxin Li" <lichongxin@zju.edu.cn>


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/SnapshotLogCleaner.java, line 22
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4140#file4140line22>
bq.  >
bq.  >     worth noting that this class is not thread-safe? I don't know if these classes
need to be thread safe, but you're using an unsynchronized hashset. Also, since refreshHLogsAndSearch
clears hlogs before re-adding stuff, it needs to be synchronized more than just using a synchronized
collection.

This class is only instantiated once by LogsCleaner so it can be seen as a singleton per master.


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/SnapshotMonitor.java, line 116
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4141#file4141line116>
bq.  >
bq.  >     does ZKW automatically re-watch the nodes for you, here?
bq.  >     
bq.  >     Also, how does this interact with region server failure? We just assume that
the snapshot will timeout and abort, instead of proactively detecting?

Yes, the ZKW automatically re-watch the nodes.

For snapshot abort, if any region server fails to perform the snapshot, it will remove corresponding
ready and finished nodes under snapshot directory. This would notify the master snapshot failure
and further abort snapshot on all region servers via ZK

For snapshot timeout, it is not detected here. In method waitToFinish, the snapshot status
is checked at a regular time (3 seconds here). If this method timeout, exception would be
thrown and master will abort the snapshot over the cluster.


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/TableSnapshot.java, line 132
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4143#file4143line132>
bq.  >
bq.  >     is there a process that scans for cases where the reference count has gotten
out of sync?
bq.  >     I'm worried about a case where a snapshot is half-done, and then it fails, so
the snapshot is considered aborted, but we never clean up the references because META has
been incremented.

This is added in META scanner. Since scanning reference files is expensive, only a few regions
are checked and synchronized in one scan. A last checking time is added so that all reference
regions are guaranteed to be checked eventually


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java, line 1403
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4153#file4153line1403>
bq.  >
bq.  >     these checks are inherently racy

Then remove it?


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java, line 585
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4148#file4148line585>
bq.  >
bq.  >     this seems prone to collision if it's multithreaded, since the exists check
and the use of the filename aren't atomic

Then how to guarantee atomicity? This unique file name should be unique respecting existing
files and files which are already compacted and deleted. Otherwise there might be a name collision
in archive directory for HFiles


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/HSnapshotDescriptor.java, line 132
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4130#file4130line132>
bq.  >
bq.  >     since we're using the snapshot name as a directory name in HDFS, it has to be
a UTF8 string, so why not just keep it as a String above too?

I implemented this class following HTableDescriptor. And even for table name, it is usually
used as a byte array instead of String


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/io/Reference.java, line 61
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4134#file4134line61>
bq.  >
bq.  >     to keep compatibility with current storefiles, "entire" should be value 2, and
bottom should be 0
bq.  >     
bq.  >     while we're at it, maybe rename these to be all caps - Range.TOP, Range.BOTTOM,
etc

Have been renamed in the latest revision


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/HMaster.java, lines 918-919
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4138#file4138line918>
bq.  >
bq.  >     should this be an exception, rather than a result code? ie is it normal to fail?

Currently all results except ALl_FINISH would throw an exception.


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/HMaster.java, line 925
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4138#file4138line925>
bq.  >
bq.  >     do we have a race here? what if the table gets enabled while the snapshot is
being processed? it seems we need some locking here around table status and snapshot modification

Why do we have a race here? I think we can't call HMaster.enableTable during the execution
of this method, right? TableDelete is implemented in the same way, the table would not get
enabled when it is being deleted, isn't it?


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/SnapshotLogCleaner.java, line 47
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4140#file4140line47>
bq.  >
bq.  >     do we have a race here between the listStatus and creating a snapshot?

I've done this modification in the latest revision. SnapshotLogCleaner's cache is refreshed
after listStatus of LogsCleaner and LogCleaner only cleans the archived logs, creating a new
snapshot would not use the archived logs.


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/SnapshotLogCleaner.java, line 115
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4140#file4140line115>
bq.  >
bq.  >     do we really want to swallow this IOE?

This implements a method from the interface. The method declaration does not throw any exceptions.


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/SnapshotMonitor.java, line 40
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4141#file4141line40>
bq.  >
bq.  >     this is basically a singleton per-master, right? not per-snapshot? ie this is
created at master startup and destroyed at master shutdown, and can coordinate multiple snapshots
over its lifetime? would be good to document how this fits into the overall design, and perhaps
refactor into one part that is master-global and another part that is created once per-snapshot.

This class has been refactored into two parts


bq.  On 2010-08-02 13:41:35, Todd Lipcon wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/master/SnapshotMonitor.java, line 169
bq.  > <http://review.cloudera.org/r/467/diff/2/?file=4141#file4141line169>
bq.  >
bq.  >     assert that we're in ALLREADY state here?

right


- Chongxin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/467/#review618
-----------------------------------------------------------





> Snapshot of table
> -----------------
>
>                 Key: HBASE-50
>                 URL: https://issues.apache.org/jira/browse/HBASE-50
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Billy Pearson
>            Assignee: Li Chongxin
>            Priority: Minor
>         Attachments: HBase Snapshot Design Report V2.pdf, HBase Snapshot Design Report
V3.pdf, HBase Snapshot Implementation Plan.pdf, Snapshot Class Diagram.png
>
>
> Havening an option to take a snapshot of a table would be vary useful in production.
> What I would like to see this option do is do a merge of all the data into one or more
files stored in the same folder on the dfs. This way we could save data in case of a software
bug in hadoop or user code. 
> The other advantage would be to be able to export a table to multi locations. Say I had
a read_only table that must be online. I could take a snapshot of it when needed and export
it to a separate data center and have it loaded there and then i would have it online at multi
data centers for load balancing and failover.
> I understand that hadoop takes the need out of havening backup to protect from failed
servers, but this does not protect use from software bugs that might delete or alter data
in ways we did not plan. We should have a way we can roll back a dataset.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message