kafka集群中一台重启后自动停止问题排查

起因：

kibana数据展示发现数据有缺失，排查后发现filebeats无法写入。登入kafka机器发现集群中1号节点leader 为 -1，根据过往经验，原因为 1号机 kafka与集群通信异常，重启后即可解决问题。暂未测试此种情况下的数据丢失问题：即kafka集群是否会向 -1 的节点写入数据。
使用命令查看topic副本情况：

/opt/kafka_2.11-1.1.1/bin/kafka-topics.sh --zookeeper ip1:2181,ip2:2181,ip3:2181  --describe   --topic   xxxxx

此时查看1号机进程运行正常，杀掉1号机kafka进程后，使用

./bin/kafka-server-start.sh -daemon ./config/server.properties  

命令进行重启。结果一分钟后发现kafka 没有起来。

问题分析：

查看kafkaServer.out日志，发现最后记录为：

[2019-07-03 09:26:34,580] INFO [ThrottledRequestReaper-Fetch]: Shutting down (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:34,857] INFO [ThrottledRequestReaper-Fetch]: Stopped (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:34,857] INFO [ThrottledRequestReaper-Fetch]: Shutdown completed (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:34,857] INFO [ThrottledRequestReaper-Produce]: Shutting down (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,857] INFO [ThrottledRequestReaper-Produce]: Stopped (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,857] INFO [ThrottledRequestReaper-Produce]: Shutdown completed (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,857] INFO [ThrottledRequestReaper-Request]: Shutting down (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,858] INFO [ThrottledRequestReaper-Request]: Stopped (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,858] INFO [ThrottledRequestReaper-Request]: Shutdown completed (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,860] INFO [SocketServer brokerId=0] Shutting down socket server (kafka.network.SocketServer)
[2019-07-03 09:26:35,887] INFO [SocketServer brokerId=0] Shutdown completed (kafka.network.SocketServer)
[2019-07-03 09:26:35,895] INFO [KafkaServer id=0] shut down completed (kafka.server.KafkaServer)

尝试分析日志：kafka自动shutdown，可能为内部错误。全局搜索大小写严格匹配‘ERROR’(对应的为上面代码段中INFO 列)发现错误原因：

[2019-07-03 09:26:25,058] ERROR [ReplicaFetcher replicaId=0, leaderId=2, fetcherId=0] Exiting because log truncation is not allowed for partition xxx-xxx-2, current leader's latest offset 8260512 is less than replica's latest offset 8314390 (kafka.server.ReplicaFetcherThread)

即现存replication数据比shutdown 掉的一号机的数据还少大约5W条数据，由于该集群下出问题的partitions数据量并不大，对于此问题有三种推测：
1、kafka在1号机broker无法加入集群时仍旧处理数据写入
2、kafka在1号机不可用时清理掉了过期数据，导致现存数据少于已存数据
3、kafka主备的数据同步并不一致，replication同步数据滞后于leader，考虑到当前机器压力与在正常运行过程中出现 leader为 -1的情况，不排除由于网络波动或其他原因导致的数据同步滞后问题

问题验证：
问题一：查看kakfa 内topic分区情况时是通过zookeeper查看的，而生产者生产数据时不需要通过kafka

解决方式：
此方式对于内topic过多时不建议，可直接参照问题三解决方式，而且不同步写入时同样会有数据丢失问题。
在zookeeper中查看kafka topic leader为 -1 的解决方法：
进入zookeeper ：

查看对应topic的分区情况及leader情况：

手动指定leader值：

set /brokers/topics/R*/partitions/1/state {"controller_epoch":46,"leader":1004,"version":1,"leader_epoch":10,"isr":[1004]}

等待30S，查看topic 状态是否恢复：

问题三：
经测试，kafka为集群读写，可能在 broker 为 -1 期间仍正常提供写入服务，导致数据不同步，此时，删除多写的数据后重启服务器等待数据同步完成即可。如果对于数据要求比较高，需要先备份数据，然后删除数据，重启服务同步数据，最后手动分析备份数据中的新增数据。