[
https://issues.apache.org/jira/browse/HBASE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091886#comment-13091886
]
[email protected] commented on HBASE-1730:
------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1479/
-----------------------------------------------------------
(Updated 2011-08-26 17:21:22.585689)
Review request for Dhruba Borthakur, Ted Yu, Michael Stack, and Jonathan Gray.
Changes
-------
1. Removed the changes to HBaseObjectWritable as Pair is already serializable
2. fixed whitespaces
3. added debug statements
I have not disabled the balancer because the logic for restoring the state of
the balancer breaks for multiple concurrent alter commands.
Summary
-------
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.
https://issues.apache.org/jira/browse/HBASE-1730
Diffs (updated)
-----
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
Testing
-------
I am putting this up for initial review. I have tested the functionality in a
pseudo distributed mode.
Need to run unit tests.
Thanks,
Nileema
> 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
