Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 16 Oct 2013 17:45:46 +0000 (UTC)
From: "Sergey Shelukhin (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12544478.1330461420810.74731.1381945546265@arcas>
In-Reply-To: <JIRA.12544478.1330461420810@arcas>
References: <JIRA.12544478.1330461420810@arcas>
Subject: [jira] [Commented] (HBASE-5487) Generic framework for
 Master-coordinated tasks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

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

I don't think it can happen on create. Until all regions are moved to Close=
d state after being created (atomically via multi-row tx), table won't leav=
e Creating state. If there's failover all regions are erased and created fr=
om 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' stat=
e under multi-row lock?

bq. Region operations should be isolated from [snip] table operations (disa=
bling / disabled table, schema changes, etc) and cluster shutdown. AM [snip=
] should NEVER know about table state (disable/disabling).=20
Strongly disagree with this. If we are doing bunch of balancing and user di=
sables 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 creat=
e, we have to handle this.=20
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 abou=
t logistics.

bq. No master abort when a region=E2=80=99s state cannot be determined. Thi=
s results in support cases where master cannot start, and without master th=
ings become even worse. We should =E2=80=9Cquarantine=E2=80=9D the regions =
if needed absolutely.
That is dangerous. IIRC in my spec I only put master abort if somebody chan=
ges 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 d=
ata - 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.=20
> Master-coordinated tasks such as online-scheme change and delete-range (d=
eleting 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 cor=
e components


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