• 【kafka学习之三】kafka集群运维


    kafka集群维护
    一、kafka集群启停
    #启动kafka
    /home/cluster/kafka211/bin/kafka-server-start.sh -daemon /home/cluster/kafka211/config/server.properties

    #关闭kafka
    /home/cluster/kafka211/bin/kafka-server-stop.sh

    二、kafka集群基本信息实时查看和修改
    #列出所有有效主题
    /home/cluster/kafka211/bin/kafka-topics.sh --list --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181

    #查看特定主题
    /home/cluster/kafka211/bin/kafka-topics.sh --describe --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --topic REC-CBBO-MSG-TOPIC

    #创建主题 尽量不要使用下划线"_"或者点好".",可以使用横线"-"
    /home/cluster/kafka211/bin/kafka-topics.sh --create --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --replication-factor 3 --partitions 17 --topic REC-CBBO-MSG-TOPIC

    #修改主题 如果主题创建了之后发现分区不够用,可以增加,不可以减少
    /home/cluster/kafka211/bin/kafka-topics.sh --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --alter --topic REC-CBBO-MSG-TOPIC --partitions 50

    #删除主题 delete.topic.enable要设置为true
    /home/cluster/kafka211/bin/kafka-topics.sh --delete --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --topic REC-CBBO-MSG-TOPIC

    #控制台当作生产者

    kafka-console-producer.sh --broker-list node1:9092,node2:90092,node3:9092 --topic t0425

    #控制台当作消费者

    ./kafka-console-consumer.sh --zookeeper node3:2181,node4:2181,node5:2181 --topic t0422

    #查看producer生产消息的最大位置

    ./kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list node1:9092 --topic t0426 --time -1 

    -1表示查询某个主题各个分区当前最大的消息位移值(注意,这里的位移值不是consumer端的位移,而是指消息在每个分区的位置)
    如果要查询曾经生产过的最大消息数,那么只运行上面这条命令然后把各个分区的结果相加就可以了

    #如果查询集群中某个topic当前消息数,还需要运行下面命令:
    /kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list node1:9092 --topic t0426 --time -2
    -2表示去获取当前各个分区的最小位移。之后把运行第一条命令的结果与刚刚获取的位移之和相减就是集群中该topic的当前消息总数

    三、kafka集群leader平衡机制

    问题:当一个broker停止或者crashes时,所有本来将它作为leader的分区将会把leader转移到其他broker上去,极端情况下,会导致同一个leader管理多个分区,导致负载不均衡,同时当这个broker重启时,如果这个broker不再是任何分区的leader,kafka的client也不会从这个broker来读取消息,从而导致资源的浪费。

    解决思路:

    kafka中有一个被称为优先副本(preferred replicas)的概念。如果一个分区有3个副本,且这3个副本的优先级别分别为0,1,2,根据优先副本的概念,0会作为leader 。当0节点的broker挂掉时,会启动1这个节点broker当做leader。当0节点的broker再次启动后,会自动恢复为此partition的leader。不会导致负载不均衡和资源浪费,这就是leader的均衡机制。


    #leader手动平衡
    /home/cluster/kafka211/bin/kafka-preferred-replica-election.sh --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181
    #leader自动平衡 server.properties 参数配置
    auto.leader.rebalance.enable=true

    注意:kafka创建主题时指定副本数R和分区数P,那么总副本数为 R*P,这些副本均匀的分布到各个broker机器上;

    其中对于每个分区都有R个副本,其中有一个leader,其他都是follow

    四、kafka集群分区日志迁移
    1、迁移topic数据到其他broker
    1.1写json文件 格式
    cat topics-to-move.json
    {
    "topics":[{"topic","foo1"},{"topic","foo2"}],
    "version":1
    }

    1.2使用generate生成迁移计划 只是生成迁移计划 并未迁移
    bin/kafka-reassign-partitions.sh --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate

    Current partition replica assignment  指当前配置  要保存 用来回滚

    Proposed partition reassignment configuration 指生成的迁移计划  保存到expand-cluster-reassignment.json

    1.3使用-execute执行计划 执行前最好保存当前的分配情况 以防出错回滚
    将上一步生成的执行计划json数据保存到expand-cluster-reassignment.json
    bin/kafka-reassign-partitions.sh --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --reassignment-json-file expand-cluster-reassignment.json --execute

    1.4使用-verify验证是否已经迁移完成
    bin/kafka-reassign-partitions.sh --zookeeper 134.32.123.101:2181,134.32.123.102:2181,134.32.123.103:2181 --reassignment-json-file expand-cluster-reassignment.json -verify

    2、迁移某个topic的某些特定的partition的数据到其他broker 步骤与上面一样 但是json文件如下
    cat custom-reassignment.json
    {
    "version":1,"partitions":[{"topic":"foo1","partition":0,"replicas":[5,6]},{"topic":"foo2","partition":1,"replicas":[2,3]}]
    }
    可以指定到topic的分区编码

    注意:迁移会导致leader失衡 需要使用平衡命令 重新平衡

    五、集群操作日志清理

    5.1 了解linux查看空间的命令

    #查看目录空间的分配和使用情况 df -h

    [cluster@PCS103 ~]$ df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/mapper/rhel-root 100G 4.7G 96G 5% /
    devtmpfs 95G 0 95G 0% /dev
    tmpfs 95G 0 95G 0% /dev/shm
    tmpfs 95G 722M 94G 1% /run
    tmpfs 95G 0 95G 0% /sys/fs/cgroup
    /dev/sda2 1016M 148M 868M 15% /boot
    /dev/sda1 200M 9.5M 191M 5% /boot/efi
    /dev/mapper/vgdata-data02 1.0T 7.5G 1017G 1% /data2
    /dev/mapper/vgdata-data01 1.0T 12G 1013G 2% /data1
    /dev/mapper/rhel-home 100G 100G 20K 100% /home
    /dev/loop0 3.6G 3.6G 0 100% /mnt/cdrom

    可以看到/home 几乎已经满了

    #查看当前目录所占空间大小 du -sh

    [cluster@PCS101 ~]$ du -sh
    3.7G    .

    #查看当前目录下每个文件以及目录所占空间大小 du -h

    [cluster@PCS101 ~]$ du -h
    472K    ./zookeeper/src/recipes
    .
    .
    .
    20M    ./zookeeper/src
    4.0K    ./zookeeper/data
    0    ./zookeeper/logs
    61M    ./zookeeper
    61M    .

    5.2 kafka操作日志  清理

    kafka/logs目录下会有操作日志  如controller.log  server.log state-change.log 等  非常多  ,根据kafka/config/log4j.properties可以看到 每天都会生成,而且有几个的日志级别是

    trace,这样会造成空间迅速被占满,需要定期清理

    需要做的是:

    (1)修改日志级别   trace改成info

    (2)写个脚本  定期清理 kafka/logs下日志   rm  -rf  kafka/logs/*

  • 相关阅读:
    synchronized对比cas
    java 数据集合类
    【转载】S2SH
    【转载】Solr4+IKAnalyzer的安装配置
    【转】基于CXF Java 搭建Web Service (Restful Web Service与基于SOAP的Web Service混合方案)
    【转载】solr初体验
    【转载】CSS 盒子模型
    【转载】div层调整zindex属性无效原因分析及解决方法
    【转载】 IE/Firefox每次刷新时自动检查网页更新,无需手动清空缓存的设置方法
    mysql ODBC connector相关问题
  • 原文地址:https://www.cnblogs.com/cac2020/p/9722890.html
Copyright © 2020-2023  润新知