Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> HBase Availability - Mean Time to Failure & Recovery Time


Copy link to this message
-
Re: HBase Availability - Mean Time to Failure & Recovery Time
Read this:
http://hortonworks.com/blog/introduction-to-hbase-mean-time-to-recover-mttr/

There are some jira ticket links in there that will give you more reading
material on MTTR.
--Suraj
On Tue, Jun 11, 2013 at 2:19 AM, Pankaj Misra <[EMAIL PROTECTED]>wrote:

> Hi,
>
>
>
> We are using 0.94.6.1 version of HBase and are planning for high
> availability testing. While the entire scheme to enable the cluster to be
> highly available is clear, I wanted to get some idea about HBase Service
> lifetime in terms of Mean-Time to Failure and Time of Recovery in cases of
> failure. Any historic evidences will also help, as it will be vital for us
> to calculate the actual availability of the system across an year.
>
>
>
> While I understand that HBase provides more of active/passive mode of
> seamless high availability of Masters, but any failure, will impact the
> performance to some extent and this calculation will help in deriving the
> actual number of nodes that we should consider without compromising on the
> performance as well, while the system is available.
>
>
>
> The article below from HBase wiki indicates that the Master switching
> takes a couple of seconds to happen but I think the volume of data, replay
> logs and the region availability will also play a key role in order to make
> the switch complete, and hence would request guidance around the complete
> mechanism and recovery time.
>
> http://wiki.apache.org/hadoop/Hbase/MultipleMasters
>
>
>
> Any ideas/facts would be very helpful .
>
>
> Thanks & Regards
> Pankaj Misra
>
>
> ________________________________
>
>
>
>
>
>
> NOTE: This message may contain information that is confidential,
> proprietary, privileged or otherwise protected by law. The message is
> intended solely for the named addressee. If received in error, please
> destroy and notify the sender. Any use of this email is prohibited when
> received in error. Impetus does not represent, warrant and/or guarantee,
> that the integrity of this communication has been maintained nor that the
> communication is free of errors, virus, interception or interference.
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB