Changing the Replication Factor

Hi, Using 0.8 beta1, how can I go about changing the replication factor for a topic that already exists? Thanks, Ryan

ClientUtils.fetchTopicMetadata reports smaller ISR than ZkUtils.getLeaderIsrAndEpochForPartition

I'm working on some monitoring tools for Kafka, and I've seen a couple of clusters get into a state where ClientUtils.fetchTopicMetadata will show that not all replicas are in the ISR. At the same time, ZkUtils.getLeaderIsrAndEpochForPartition will show that all all partitions are in the ISR, and

Re: ClientUtils.fetchTopicMetadata reports smaller ISR than ZkUtils.getLeaderIsrAndEpochForPartition

titions. What can I do in the meantime to track down the issue? Thanks, Ryan On Thu, Dec 5, 2013 at 12:55 AM, Jun Rao wrote: > Do you see any ISR churns on the brokers? You can check the ISR > expand/shrink rate jmx. > > Thanks, > > Jun > > > On Wed, Dec 4, 2013 a

Re: ClientUtils.fetchTopicMetadata reports smaller ISR than ZkUtils.getLeaderIsrAndEpochForPartition

> /*** > Joe Stein > Founder, Principal Consultant > Big Data Open Source Security LLC > http://www.stealth.ly > Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> > / > &

Invalid topic metadata response

After reassigning a topic to 5 new brokers, the topic metadata returned by the brokers for the topic is causing an exception when a producer tries to read it: java.util.NoSuchElementException: key not found: 7 ... at kafka.api.PartitionMetadata$.readFrom(TopicMetadata.scala:104) The reassignment

Re: Invalid topic metadata response

ome known bugs with the partition reassignment tool in 0.8. We > fixed a lot of those, tested it on large set of partitions and found it to > be stable in 0.8.1. Could you give 0.8.1 a spin instead? > > > On Thu, Mar 13, 2014 at 4:05 PM, Ryan Berdeen > wrote: > > > After reassi

Documentation for metadata.broker.list

I recently moved my 0.8.0 cluster to a set of entirely new brokers, and was surprised to find that the producers did not update their list of brokers to remove the brokers that were no longer in the cluster. That is, I had brokers 1,2,3,4,5, added brokers 6,7,8,910, waited a day, and stopped broker

Controlled shutdown and leader election issues

While upgrading from 0.8.0 to 0.8.1 in place, I observed some surprising behavior using kafka.admin.ShutdownBroker. At the start, there were no underreplicated partitions. After running bin/kafka-run-class.sh kafka.admin.ShutdownBroker --broker 10 ... Partitions that had replicas on broker 10 w

Re: Controlled shutdown and leader election issues

ated partition > > count drops to 0 after each restart before moving to the next one. > > > > Thanks, > > > > Jun > > > > > > On Thu, Mar 20, 2014 at 3:14 PM, Ryan Berdeen > > wrote: > > > > > While upgrading from 0.8.0 to 0.8.1 in

Re: Controlled shutdown and leader election issues

t a try to see if your issue is resolved. > > > > > > > > Thanks, > > > > Neha > > > > > > > > > > > > On Wed, Apr 2, 2014 at 12:59 PM, Clark Breyman > > > wrote: > > > > > > > > >

Too many replicas after partition reassignment

After doing some partition reassignments, I've ended up with some partitions that have both the old and new brokers assigned. The output of kafka-topics.sh --describe looks like this: Topic:cs-es-indexer-a PartitionCount:30 ReplicationFactor:2 Configs: retention.ms=1080 ... Topic: cs-es-ind