Kafka, mail # user - Re: 0.8 best practices for migrating / electing leaders in failure situations? - 2013-03-26, 00:37
Solr & Elasticsearch trainings in New York & San Francisco [more info][hide]
 Search Hadoop and all its subprojects:

Switch to Threaded View
Copy link to this message
-
Re: 0.8 best practices for migrating / electing leaders in failure situations?
The assignment of partitions to replicas (brokers) happens at the
create topic time. After that, it can only be changed through the
partition reassignment tool. The replicas are identified using the
broker id, so if you keep the broker ids intact, Kafka cluster and
clients cannot tell that the previous brokers are gone and new ones
have come up. If you change the broker ids, then you have to
explicitly reassign the partitions to the new brokers.

There is no caching on the client, it asks the brokers about the
topic/partition placement and metadata.

Thanks,
Neha

On Mon, Mar 25, 2013 at 9:58 AM, Scott Clasen <[EMAIL PROTECTED]> wrote:

 
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