hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-1730) Near-instantaneous online schema and table state updates
Date Fri, 26 Aug 2011 17:25:32 GMT

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

jiraposter@reviews.apache.org commented on HBASE-1730:

This is an automatically generated e-mail. To reply, visit:

(Updated 2011-08-26 17:25:21.197997)

Review request for hbase, Dhruba Borthakur, Ted Yu, Michael Stack, and Jonathan Gray.


When the master receives an alter table call (addColumn, modifyColumn, deleteColumn, modifyTable),
it updates the .tableinfo and then closes all the regions of that table. The patch includes:

1. Changes to reopen the regions when any of the above operations are performed. 
2. Best effort is made to preserve the locality of regions by assigning it a region plan before
closing it. 
3. Throttling logic that ensures that only a configurable number of regions are closed per
region server at a time. 
4. alter command in the hbase shell will block until all the regions are updated, providing
a status "x/y regions updated" every second. 
5. alter_async command that works exactly like alter, except that it does not block for completion
or provide the status. 
6. alter_status <table_name> which is a sync call and blocks to provide the "x/y regions
updated" status per second until all regions are updated. 
7. modification in the unit test for enabling alter without disabling the table.

This addresses bug HBASE-1730.


  src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java 5965919 
  src/main/ruby/shell.rb 1ec330f 
  src/main/ruby/shell/commands/alter.rb 1dd43ad 
  src/main/ruby/shell/commands/alter_async.rb PRE-CREATION 
  src/main/ruby/shell/commands/alter_status.rb PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/master/handler/TableEventHandler.java 09891aa 
  src/main/ruby/hbase/admin.rb 4460d6e 
  src/main/java/org/apache/hadoop/hbase/master/HMaster.java 9784195 
  src/main/java/org/apache/hadoop/hbase/master/handler/ClosedRegionHandler.java ae43837 
  src/main/java/org/apache/hadoop/hbase/master/handler/TableAddFamilyHandler.java 6332953

  src/main/java/org/apache/hadoop/hbase/master/BulkReOpen.java PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java b5d65ce 
  src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java 0c9ecce 
  src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java c0aa024 
  src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java 49d1e7c 

Diff: https://reviews.apache.org/r/1479/diff


I am putting this up for initial review. I have tested  the functionality in a pseudo distributed
Need to run unit tests.



> Near-instantaneous online schema and table state updates
> --------------------------------------------------------
>                 Key: HBASE-1730
>                 URL: https://issues.apache.org/jira/browse/HBASE-1730
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Purtell
>            Assignee: stack
>            Priority: Critical
>             Fix For: 0.92.0
>         Attachments: 1730-v2.patch, 1730-v3.patch, 1730.patch, HBASE-1730.patch
> We should not need to take a table offline to update HCD or HTD. 
> One option for that is putting HTDs and HCDs up into ZK, with mirror on disk catalog
tables to be used only for cold init scenarios, as discussed on IRC. In this scheme, regionservers
hosting regions of a table would watch permanent nodes in ZK associated with that table for
schema updates and take appropriate actions out of the watcher. In effect, schema updates
become another item in the ToDo list.
> {{/hbase/tables/<table-name>/schema}}
> Must be associated with a write locking scheme also handled with ZK primitives to avoid
situations where one concurrent update clobbers another. 

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message