kafka的topic默认是不允许被删除的,删除后在topic后会出现”marked for deletion”字样,实际并未删除,现在创建同样的topic会提示topic已经存在. 解决办法: server.properties配置文件中添加:delete.topic.enable=true 之后重启kafka,会发现之前被标记删除的topic已经不存在了. kafka操作基本命令: 创建topic(replication-factor为集群broker数量): bin/kafka-topic

前提: 只针对Kafka 0.9.0.1版本; 说是运维,其实偏重于问题解决; 大部分解决方案都是google而来, 我只是作了次搬运工; 有些问题的解决方案未必一定是通用的, 若应用到线上请慎重; 如有疏漏之处, 欢迎大家批评指正; 列表: Replica无法从leader同步消息 Broker到zk集群的连接不时会断开重断 Broker重启耗时很久 不允许脏主选举导致Broker被强制关闭 Replica从错误的Partition leader上去同步数据 __consumer_offset

1.目标 我们可以在Kafka集群上执行几个Apache Kafka Operations .因此,在本文中,我们将详细讨论所有Apache Kafka操作.它还包括有助于实现这些Kafka操作的命令.所以,让我们详细讨论所有Kafka Operations. 使用命令进行Apache Kafka操作 2.什么是Apache Kafka Operations? 下面,我们正在讨论卡夫卡的运作,让我们逐一看到它们: 一个.添加和删​​除Kafka主题 我们可以自动和手动添加和删除Kafka主题.添

转载自:https://www.jianshu.com/p/d2cbaae38014 前提: 只针对Kafka 0.9.0.1版本; 说是运维,其实偏重于问题解决; 大部分解决方案都是google而来, 我只是作了次搬运工; 有些问题的解决方案未必一定是通用的, 若应用到线上请慎重; 如有疏漏之处, 欢迎大家批评指正; 列表: Replica无法从leader同步消息 Broker到zk集群的连接不时会断开重断 Broker重启耗时很久 不允许脏主选举导致Broker被强制关闭 Replica从

事情始末 平时经常开玩笑,删库跑路.删库跑路,今天我真的rm -rf *了.早上来,一个同事说要查日志,但是日志我又备份到云磁盘了,我就想着把那一天的日志wget下来看看,然后分析.本来是想放在/var/log/目录下去,但是我看了一下磁盘的根目录可用空间不多了,于是我就cd 到/data数据目录.这一个操作就是万恶之源,在这个目录下,我wget日志下来后,解压,看了之后不是我想要的日志,因为我解压的日志也是data目录.当时我就想删的时候千万不要把根目录下的data(/data)删了,只要删d

0x00 概述 kafka将topic分成不同的partitions,每个partition的日志分成不同的segments,最后以segment为单位将陈旧的日志从文件系统删除. 假设kafka的在server.properity文件中设置的日志目录为tmp/kafka-logs,对于名为test_perf的topic.假设两个partitions,那么我们可以在tmp/kafka-logs目录下看到目录VST_TOPIC-0,VST_TOPIC-1.也就是说kafka使用目录表示topic

简要:开发中,常常因为需要我们要认为修改消费者实例对kafka某个主题消费的偏移量.具体如何修改?为什么可行?其实很容易,有时候只要我们换一种方式思考,如果我自己实现kafka消费者,我该如何让我们的消费者代码如何控制对某一个主题消费,以及我们该如何实现不同消费者组可以消费同一个主题的同一条消息,一个消费组下不同消费者消费同一个主题的不同消息.如果让你实现该框架该如何实现? 这里我演示实验storm的kafkaspout来进行消费,kafkaspout里面使用的低级api,所以他在zookeep

顾名思义,就是kafka的consumer api包. 一.ConsumerConfig.scala Kafka consumer的配置类,除了一些默认值常量及验证参数的方法之外,就是consumer的配置参数了,比如group.id, consumer.id等,详细列表见官网. 二.ConsumerIterator.scala     KafkaStream的迭代器类,当stream底层的阻塞队列为空时该iterator会置于阻塞状态.这个迭代器还提供了一个shutdownCommand对象可

32, 33都是和时间相关的, KIP-32 - Add timestamps to Kafka message 引入版本,0.10.0.0 需要给kafka的message加上时间戳,这样更方便一些, 比如在做retention,rolling,或getMessageByTime的时候 在config里面可以配置, message.timestamp.type - This topic level configuration defines the type of timestamp in t

Kafka集群中的一个broker会被作为controller负责管理分区和副本的状态以及执行类似于重分配分区之类的管理任务.如果当前的controller失败了,会从剩下的broker中选出新的controller. 一.PartitionLeaderSelector.scala 顾名思义就是为分区选举出leader broker,该trait只定义了一个方法selectLeader,接收一个TopicAndPartition对象和一个LeaderAndIsr对象.TopicAndPartit

Kafka是一种高吞吐量的分布式发布订阅的消息队列系统,原本开发自LinkedIn,用作LinkedIn的活动流(ActivityStream)和运营数据处理管道(Pipeline)的基础.现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用. 1 Kafka消息队列简介 1.1 基本术语 Broker Kafka集群包含一个或多个服务器,这种服务器被称为broker[5]  Topic 每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic.(物理上不同Topic的消

1.删除kafka存储目录(server.properties文件log.dirs配置,默认为"/tmp/kafka-logs")相关topic目录 2.Kafka 删除topic的命令是: ./bin/kafka-topics  --delete --zookeeper [zookeeper server]  --topic [topic name] 如果kafaka启动时加载的配置文件中server.properties没有配置delete.topic.enable=true,那么

http://www.infoq.com/cn/articles/kafka-analysis-part-1/ Kafka是由LinkedIn开发的一个分布式的消息系统,使用Scala编写,它以可水平扩展和高吞吐率而被广泛使用.目前越来越多的开源分布式处理系统如Cloudera.Apache Storm.Spark都支持与Kafka集成.InfoQ一直在紧密关注Kafka的应用以及发展,“Kafka剖析”专栏将会从架构设计.实现.应用场景.性能等方面深度解析Kafka. 背景介绍 Kafka创建

(一)kafka修改topic分区的位置 环境:kafka_2.10-0.8.2.1 + JDK1.7.0_80 1. 查看分区topic的分区分布 $ le-kafka-topics.sh --describe --topic http_zhixin_line1 结果如下: [hadoop@sdf-nimbus-perf project]$ le-kafka-topics.sh --describe --topic http_zhixin_line1 Topic:http_zhixin_lin

前面已经分析过kafka server的启动过程,以及server所能处理的所有的request,即KafkaApis 剩下的,其实关键就是controller,以及partition和replica的状态机 这里先看看controller在broker server的基础上,多做了哪些初始化和failover的工作   最关键的一句, private val controllerElector = new ZookeeperLeaderElector(controllerContext, Zk

一.结构与概念解释 1.基础概念 topics: kafka通过topics维护各类信息. producer:发布消息到Kafka topic的进程. consumer:订阅kafka topic进程和处理订阅的消息的进程. broker:kafka集群的每个server叫broker. 提供了语言无关.高性能.简单的client-server的链接方式. 2.Topics and Logs (1)topic是发送消息的类别名称.每个partition是持续添加的有序的不可变的消息序列-comm

因公司数据安全和分析的需要,故调研了一下 GlusterFS + lagstash + elasticsearch + kibana 3 + redis 整合在一起的日志管理应用: 安装,配置过程,使用情况等续 一,glusterfs分布式文件系统部署: 说明: 公司想做网站业务日志及系统日志统一收集和管理,经过对mfs, fastdfs 等分布式文件系统的调研,最后选择了 glusterfs,因为Gluster具有高扩展性.高性能.高可用性.可横向扩展的弹性特点,无元数据服务器设计使glust

接上面一篇文章: http://www.cnblogs.com/charlesblc/p/6038112.html 主要参考这篇文章: http://www.open-open.com/lib/view/open1435884136903.html 还有之前一直在跟的这篇文章: http://blog.csdn.net/ymh198816/article/details/51998085 下载了Kafka的安装包: http://apache.fayea.com/kafka/0.10.1.0/k

broker.id 区kafka集群中每台机器的标识 log.dirs 日志的存放目录,这个最好不要放到/tmp目录下,因为kafka的已被消费和未被消费的数据也被当成“日志”存放到了日志目录,: log.retention.hours log.segment.bytes log.retention.check.interval.ms log.cleaner.enable=false 因为数据存放在日志目录中,所以在实际集群中会有大量的数据,这样会导致日志目录会不断增大,一些被消费过的数据和日志

Purgatory是Kafka server中处理请求时使用的一个重要的数据结构.正好研究ReplicaManager源码的时候发现了这篇文章,顺便翻译下.由于这个proposal里的很多东西需要看源码才能理解得比较清楚,但是代码还是比较多的,所以先大概讲一下其中的一些概念和原理,以便于阅读接下来的文章. 1. purgatory是用于缓存一些 delayed request的.这些请求因为一些条件得不到满足,所以需要先放到purgatory里,等到条件满足了,再从里边移出来. 2. 这些req

开发测试时给 Kafka 发消息的 UI 发送器――Mikasa 说来话长,自从入了花瓣,整个人就掉进连环坑了. 后端元数据采集是用 Storm 来走拓扑流程的,又因为 @Zola 不是很喜欢 Java,所以退而求其次选择了 Clojure,所以正在苦逼地学习 Clojure 和 Storm 中. 目前来说外面的 Storm 拓扑的 Spout 是从 Kafka 中流入数据的.但是我们要给 Kafka 发送测试数据的时候,就需要跑到 Kafka 的测试服务器打开它的一个发送脚本进去发送,非常蛋疼