hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5487) Generic framework for Master-coordinated tasks
Date Wed, 16 Oct 2013 17:45:46 GMT

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

Sergey Shelukhin commented on HBASE-5487:
-----------------------------------------

I don't think it can happen on create. Until all regions are moved to Closed state after being
created (atomically via multi-row tx), table won't leave Creating state. If there's failover
all regions are erased and created from scratch. Create table is rare enough for that to work.

[~enis] Wrt req list, mostly agree, however:
bq. Bulk region operations
Can you please elaborate? Is it the same as modifying several regions' state under multi-row
lock?

bq. Region operations should be isolated from [snip] table operations (disabling / disabled
table, schema changes, etc) and cluster shutdown. AM [snip] should NEVER know about table
state (disable/disabling). 
Strongly disagree with this. If we are doing bunch of balancing and user disables a table
at the same time, we have to handle it.
If user tries to force-assign regions of a table that is halfway thru create, we have to handle
this. 
For alter, we need to reopen regions, which will have to work w/splits and merges (it's covered
in my doc).
For what purpose do you want to isolate them?
AM should not know about details e.g. schema logic, but it should know about logistics.

bq. No master abort when a region’s state cannot be determined. This results in support
cases where master cannot start, and without master things become even worse. We should “quarantine”
the regions if needed absolutely.
That is dangerous. IIRC in my spec I only put master abort if somebody changes table state
under master; but in general, if region is in unknown state it's better to make admin act,
than to just silently "disappear" part of data - that can lead to wrong results.
Perhaps table needs to be quaranteened then.

> Generic framework for Master-coordinated tasks
> ----------------------------------------------
>
>                 Key: HBASE-5487
>                 URL: https://issues.apache.org/jira/browse/HBASE-5487
>             Project: HBase
>          Issue Type: New Feature
>          Components: master, regionserver, Zookeeper
>    Affects Versions: 0.94.0
>            Reporter: Mubarak Seyed
>            Priority: Critical
>         Attachments: Region management in Master5.docx, Region management in Master.pdf
>
>
> Need a framework to execute master-coordinated tasks in a fault-tolerant manner. 
> Master-coordinated tasks such as online-scheme change and delete-range (deleting region(s)
based on start/end key) can make use of this framework.
> The advantages of framework are
> 1. Eliminate repeated code in Master, ZooKeeper tracker and Region-server for master-coordinated
tasks
> 2. Ability to abstract the common functions across Master -> ZK and RS -> ZK
> 3. Easy to plugin new master-coordinated tasks without adding code to core components



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message