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
Kafka >> mail # user >> Re: Kakfa Failures and Recovery


Copy link to this message
-
Re: Kakfa Failures and Recovery
At LinkedIn, the most common type of failure is controlled shutdown for
code/config pushes. For that, we have a tool for reducing
the unavailability window (
https://cwiki.apache.org/confluence/display/KAFKA/Replication+tools). This
can happen once or twice a month. The next common type of failure is
disk/raid failure, which seems to happen once every month or two. The
remaining types of failure include Linux crashes, JMV bugs, and other types
of hardware failures. They happen a few times a year.

Thanks,

Jun
On Tue, Jun 11, 2013 at 1:22 AM, Pankaj Misra <[EMAIL PROTECTED]>wrote:

> Hi,
>
> We are using 0.8 version of Kafka and are planning for high availability
> testing with replication. While the entire scheme to enable the cluster to
> be highly available is clear, I wanted to get some idea about Kafka 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 Kafka provides more of active/active mode of
> seamless high availability, 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.
>
> 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