hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject the master role after ZK (was: Re: HBase failover)
Date Wed, 07 Jan 2009 20:04:03 GMT
> From: Jean-Daniel Cryans 
>
> With ZK in 0.20, a cluster restart won't be necessary.
> Since the ROOT address will be stored in ZK, the clients
> will practically never communicate with the master and
> the region servers will just keep serving regions. If
> the master fails, the RS should not block gets/puts but
> won't be able to do splits. However, the new master will
> have to be started manually (or we can implement a
> simple way to have extra masters sleeping just in case)
> so that it gets its unique lock which will surely
> contain it's address.

If the master fails, and then a HRS fails, then what? 
Especially what happens if the HRS is carrying ROOT or META?

There's no reason that all the live HRS cannot use ZK to
negotiate among themselves who should also assume the master
role, since the master role will also go on a diet. After ZK
integration, is there a need for separate processes for the
master and region server functions?

In fact the master role might be distributed among the HRS
via ZK. About the only need for a master would be to manage
region assignments upon splits and HRS failures. Why not put
up locks (or appropriate synchronization primitives) for
every region and have the HRS figure out among themselves
who should carry new or unassigned regions?

Just thinking out loud here. 

   - Andy



      

Mime
View raw message