Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 17 May 2012 20:00:09 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1114326516.10549.1337284809456.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1668935946.21895.1336055089462.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5926) Delete the master znode after a
 master crash
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-5926:
------------------------------

bq. We need the content. For the regionserver, the content is the znode path. For the master it's the full ServerName (stringified).

Does it have to be full path?  Can it not just be the node name?  Thats safe to put in the fs?  Master servername stringified should be safe in the fs too.

Yeah, version.
                
> Delete the master znode after a master crash
> --------------------------------------------
>
>                 Key: HBASE-5926
>                 URL: https://issues.apache.org/jira/browse/HBASE-5926
>             Project: HBase
>          Issue Type: Improvement
>          Components: master, scripts
>    Affects Versions: 0.96.0
>            Reporter: nkeywal
>            Assignee: nkeywal
>            Priority: Minor
>             Fix For: 0.96.0
>
>         Attachments: 5926.v10.patch, 5926.v6.patch, 5926.v8.patch, 5926.v9.patch
>
>
> This is the continuation of the work done in HBASE-5844.
> But we can't apply exactly the same strategy: for the region server, there is a znode per region server, while for the master & backup master there is a single znode for both.
> So if we apply the same strategy as for a regionserver, we may have this scenario:
> 1) Master starts
> 2) Backup master starts
> 3) Master dies
> 4) ZK detects it
> 5) Backup master receives the update from ZK
> 6) Backup master creates the new master node and become the main master
> 7) Previous master script continues
> 8) Previous master script deletes the master node in ZK
> 9) => issue: we deleted the node just created by the new master
> This should not happen often (usually the znode will be deleted soon enough), but it can happen.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira