> 推薦一款非常好用的kafka管理平臺,kafka的靈魂伴侶 > 滴滴開源LogiKM一站式Kafka監控與管控平臺

<hr>

這篇文章源自於,一位羣友的問題,然後就寫下了這篇文章

</div> 進羣加V :jjdlmn_

先定義一下名詞: 遷移前的Broker： OriginBroker 、遷移後的副本 TargetBroker

Kafka專欄整理地址請戳這裏0.0

前提

進羣加V :jjdlmn_

在這之前如果你比較瞭解 分區重分配的原理 的話,下面的可能更好理解; 推薦你閱讀一下下面幾篇文章(如果你點不進去說明我還沒有發佈)

【kafka源碼】ReassignPartitionsCommand源碼分析(副本擴縮、數據遷移、副本重分配、副本跨路徑遷移) 【kafka運維】副本擴縮容、數據遷移、副本重分配、副本跨路徑遷移

Kafka的靈魂伴侶Logi-KafkaManger(4)之運維管控–集羣運維(數據遷移和集羣在線升級)

如果你不想費那個精力,那直接看下面我畫的這張圖,你自己也能分析出來可能出現的問題;以及怎麼排查

所有異常情況

1. TargetBroker若不在線,遷移腳本執行會失敗

> TargetBroker若不在線, 在開始執行任務腳本的時候，校驗都不會被通過呢

情景演示

BrokerId	角色	狀態	副本
0	普通Broker	正常	test-0
1	普通Broker	宕機	無

現在將分區topic-test-0 從Broker0 遷移到 Broker1


sh bin/kafka-reassign-partitions.sh --zookeeper xxxxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 1000000

執行異常

Partitions reassignment failed due to The proposed assignment contains non-existent brokerIDs: 1
kafka.common.AdminCommandFailedException: The proposed assignment contains non-existent brokerIDs: 1
        at kafka.admin.ReassignPartitionsCommand$.parseAndValidate(ReassignPartitionsCommand.scala:348)
        at kafka.admin.ReassignPartitionsCommand$.executeAssignment(ReassignPartitionsCommand.scala:209)
        at kafka.admin.ReassignPartitionsCommand$.executeAssignment(ReassignPartitionsCommand.scala:205)
        at kafka.admin.ReassignPartitionsCommand$.main(ReassignPartitionsCommand.scala:65)
        at kafka.admin.ReassignPartitionsCommand.main(ReassignPartitionsCommand.scala)

2. TargetBroker在開始遷移過程中宕機，導致遷移任務一直在進行中

進羣加V :jjdlmn_ Kafka專欄整理地址請戳這裏0.0

>一般這種情況是出現在, 寫入了節點/admin/reassign_partitions/之後, 有一臺/N臺 targetBroker 中途宕機了, 導致這臺Broker不能正常的創建新的副本和同步Leader操作,就不能夠繼續往後面走了

情景演示

模擬這種情況,我們可以手動寫入了節點/admin/reassign_partitions/重分配信息例如：

創建一個節點寫入的信息如下, 其中Broker-1 不在線; 模擬在分配過程中宕機了;

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[1]}]}

看到 /broker/topics/{topicName} 中的節點已經變更爲下面的了
接下來應該要像Broker-1發送LeaderAndIsr請求讓它創建副本並且同步Leader；但是這個時候Broker-1是不在線的狀態；所以就會導致這個任務一直在進行中, 如果你想進行其他的重分配就會提示如下
```
	There is an existing assignment running.
```

解決方法

>只要知道什麼情況,那解決問題思路就很清晰了, 只要把掛掉的Broker重啓就行了;

3. 被遷移副本沒有找到Leader,導致TargetReplica一直不能同步副本

>只要被遷移的副本的Leader服務掛了,並且還沒有選舉出新的Leader, 那麼就沒地方同步了 >這種情況跟情況2類似,但也有不同, 不同在於這裏可能是其他的Broker掛了導致的

情景演示

BrokerId	角色	狀態	副本
0	普通Broker	正常	無
1	普通Broker	宕機	test-0

現在將分區test-0 從Broker1 遷移到 Broker0

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0],"log_dirs":["any"]}]}

看上面的圖, TargetReplica會收到LeaderAndIsr 然後開始創建副本，並且zk中也寫入了TargetBroker的AR信息; 然後開始去同步Leader的副本信息,這個時候Leader是誰? 是Broker-1上的test-0;(只有一個副本)，然後準備去同步的時候,OriginBroker不在線,就同步不了,所以TargetReplica只是創建了副本,但是還沒有同步數據;如下

TargetReplica被創建,但是沒有數據; 又因爲OriginBroker不在線,所以也沒有被刪除副本(下圖kafka-logs-30 是Broker0;kafka-logs-31是Broker1)
因爲整個分區重分配任務沒有完成，所以 /admin/reassign_partitions/還未刪除 >{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0]}]}
/broker/topics/{topicName} 中的節點會更新爲下圖, 其中AR RR都還沒有被清空
brokers/topics/test/partitions/0/state節點看Leader爲-1，並且ISR中也沒有加入 TargetBroker 只要是沒有同步成功,那麼整個分區流程就會一直進行中;

解決方案

一般出現這種情況還是少見的,基本上單副本纔會出現這種情況一般就算OriginBroker掛了,導致一個副本下線了,那麼其他的副本會承擔起Leader的角色如果只有一個副本,那麼就會造成這種異常情況了,這個時候只需要把OriginBroker重啓一下就行了

4. 限流導致重分配一直完成不了

進羣加V :jjdlmn_ Kafka專欄整理地址請戳這裏0.0

> 我們一般在做分區副本重分配任務的時候,一般都會加上一個限流值 > --throttle : 遷移過程Broker之間傳輸的速率,單位 bytes/sec > 注意這個值是Broker之間的限流, 並不僅僅指的是這次遷移的幾個分區副本的限流；而是包含其他Topic自身正常的數據同步的流量; 所以如果你這個限流值設置的很小, 速率比正常情況下的同步速率還要小 > 又或者你的同步速率比創建消息的速率都要慢, 那麼這個任務是永遠完不成的！

情景演示

創建重分配任務, 限流值 1

	 sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 1

基本上這個速率是別想完成了，admin/reassign_partitions節點一直在
zk中的限流配置

解決方案

>將限流閾值設置大一點，重新執行一下上面的腳本，限流值加大

	 sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 100000000

(雖然這裏執行之後還是會提醒你有任務在進行中,但是會重寫限流信息的) 千萬記得任務結束要用 --verify來把限流值移除掉! 不然他會一直存在的;

5. 數據量太大,同步的賊慢

進羣加V :jjdlmn_

> 出現這個情況是很常見的一個事情,它也不屬於異常, 性能問題你沒辦法,但是往往我們做數據遷移的時候會忽略一個問題； 那就是過期數據太多,遷移這個過期數據本身就沒有什麼意義; > 可以看我之前的文章 Kafka的靈魂伴侶Logi-KafkaManger(4)之運維管控–集羣運維(數據遷移和集羣在線升級) > 減少遷移的有效數據,能夠大大增加數據遷移的效率;

解決方案

減少遷移的數據量 如果要遷移的Topic 有大量數據（Topic 默認保留7天的數據），可以在遷移之前臨時動態地調整retention.ms 來減少數據量; 當然手動的來做這個操作真的是太讓你煩心了, 你可以有更聰明的選擇

Kafka的靈魂伴侶Logi-KafkaManger(4)之運維管控–集羣運維(數據遷移和集羣在線升級)

滴滴開源Logi-KM一站式Kafka監控與管控平臺

可視化的進行數據遷移、分區副本重分配;

設置限流、減小數據遷移量、遷移完成自動清理限流信息

排查問題思路

進羣加V :jjdlmn_

>上面我把我能想到的所有可能出現的問題解決方案都列舉了出來; 那麼碰到了 >重分配任務一直在進行中怎麼快速定位和解決呢？There is an existing assignment running.

1. 先看/admin/reassign_partitions裏面的數據

假設一次任務如下; 有兩個分區 test-0分區分在Broker[0,1] test-1分區在Broker[0,2]

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,1]},
{"topic":"test","partition":1,"replicas":[0,2]}]}

恰好圖中Broker1宕機了,test-0就不能完成了,test-1則正常完成; 那麼這個時候/admin/reassign_partitions節點就是

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,1]}]}

所以我們先看節點的數據，能夠讓我們指定是哪個分區重分區出現了問題 ;

從上面數據可以指定, test-0 這個分區沒有完成,對應的Broker有 [0,1]

2. 再看brokers/topics/{TopicName}/partitions/{分區號}/state數據

通過步驟1 我知道 test-0 有問題,我就直接看節點/brokers/topics/test/partitions/0/state得到數據這裏分兩種情況看

如下
```
	{"controller_epoch":28,"leader":0,"version":1,"leader_epoch":2,"isr":[0]}
```
可以發現 ISR:[0], 只有0 ；正常來說應該是我上面設置的[0,1]; 那問題就定位在 Broker-1中的副本沒有加入到ISR中; 接下來的問題就是排查爲啥Broker-1 沒有加入到ISR了；
如下, leader:-1 的情況
```
	{"controller_epoch":28,"leader":-1,"version":1,"leader_epoch":2,"isr":[0]}
```
leader:-1 表示當前沒有Leader; 新增的副本沒有地方去同步數據，就很迷茫; 所以接下來要排查的就是其該TopicPartition的其他副本所在Broker是不是都宕機了; 如何確定其他Broker? 看AR是否都正常;AR數據在brokers/topics/{topicName}可以看到 ;

當然你可以通過滴滴開源-LogIKM 一站式Kafka監控與管控平臺更簡單的去排查這個步驟;如下

3. 根據步驟2確定對應的Broker是否異常

如果找到有Broker異常，直接重啓就完事了;

4.查詢限流大小

如果步驟3還沒有解決問題,也沒有Broker異常,那麼再判斷一下流量限制的問題了

首先看看節點/config/brokers/{brokerId} 是否配置了限流信息;
還有節點/config/topics/{topicName}的信息
並且看到Broker節點也沒有加入到ISR, 那麼妥妥的同步速率問題了

如果查詢到的限流值比較小的話,可以適當的調大一點


		 sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 100000000

5. 重新執行重分配任務(停止之前的任務)

> 如果上面還是沒有解決問題,那麼可能是你副本數據量太大,遷移的數據太多, 或者你TargetBroker網絡情況不好等等,網絡傳輸已經達到上限,這屬於性能瓶頸的問題了，或許你該考慮一下是不是重新分配一下；或者找個夜深人靜的晚上做重分配的操作;

情景演示

test-0 分區原本只在Broker [0]中, 現在重分配到 [0,1], 用--throttle 1 模擬一下網絡傳輸速率慢，性能瓶頸等

這個節點一直會存在,一直在進行中,adding_replicas 也一直顯示[1]
同時可以看到 Broker-1 是存活的
但是不在ISR裏面的
判斷出來可能同步速率更不上, TargetBroker可能網絡狀況不好,或者本身壓力也挺大；換個TargetBroker
直接刪除節點/admin/reassign_partitions ,然後重新執行一下重分配任務; 重分配到[0,2]中
```
	{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,2]}]}
```
可以看到已經在zk中寫入了新的分配情況; 但是topic節點中卻沒有變更AR 和ARS 這是因爲Controller雖然收到了節點的新增通知/admin/reassign_partitions; 但是在校驗的時候,它內存裏面保存過之前的重分配任務,所以對Controller而言,它認爲之前的任務還是沒有正常結束的,所以也就不會走後門的流程;
重新選舉Controller角色,重新加載/admin/reassign_partitions ; 我在文章【kafka源碼】Controller啓動過程以及選舉流程源碼分析裏面分析過,Controller重新選舉會重新加載/admin/reassign_partitions節點並繼續任務的執行; 切換之後如下,變更正常 切換Controller,需要你主動去刪除zk節點 /controller 當然還有更簡單的方式滴滴開源LogiKM 一站式Kafka監控與管控平臺如下指定一些空閒的Broker當做Controller,並立即切換是一個明智的選擇;

解決方案

數據量太大是因爲很多過期數據; 如果你重分配的時候沒有考慮清理過期數據; 那麼就重新分配把但是重分配任務同一時間只能有一個,所以你只能暴力刪除/admin/reassign_partitions ;然後重新分配一下; 注意重新分配的時候,請務必設置臨時的數據過期時間,減少遷移數據；並且還要讓Controller切換一下;
總結起來是 ①. 刪除節點/admin/reassign_partitions ②. 重新執行重分配任務 ③. 讓Controller發生重選舉

排查工具+思考

> 分析完上面的問題, 起始這個問題排查起來,還是挺麻煩的,看這個看那個指標什麼的; > 是不是可以有一個工具來自動幫我排查問題+提供解決方案; > 既然排查思路有了,可視化，自動化，工具化也不是什麼難事吧; > 所以我在滴滴開源LogiKM 一站式Kafka監控與管控平臺上準備提一個ISSUE, 來簡單的實現這麼一個功能; > 看什麼時候比較空的時候來完成它,你要是有興趣,也可以一起來完成它!

現實案例分析

進羣加V :jjdlmn_

>週五快下班的時候, 羣裏面有個同學問了一句下面這個問題, 然後我就我回復了一下; >後來爲了具體分析就拉了一個小羣來尋找蛛絲馬跡

</center> </div> <center>

</center> 進羣加V: jjdlmn_

<hr> 具體的日誌我就不貼出來了,太多了;

這位同學在進行分區重分配的過程中, 持久了很久,一直在進行中, 後來去百度說讓在zk中刪除重分配任務節點; 我告知了節點之後,然後立馬刪除了這個節點,後來發現某一臺遷移的 TargetBroker掛了, 讓他們重啓之後,重分配的任務仍舊接着進行下去了, 也就是說 TargetBroker 依然正常的完成了副本的分配;

問題分析

其實這個問題就是我們上面分析過的第二種情況 2. TargetBroker在開始遷移過程中宕機，導致遷移任務一直在進行中 具體爲什麼TargetBroker爲什麼會宕機這不是我們分析的範疇;

因爲TargetBroker宕機了,導致任務不能結束; 這個時候只需要重啓TargetBroker就可以了;

雖然他們直接暴力刪除了節點/admin/reassign_partitions ; 問題也不大; 影響點在下一次開始重分配的任務時候, Controller內存裏面還是報錯的之前的信息,所以下一次的任務不會被執行; 但是如果你讓Controller重新分配之後,那麼就會繼續執行了,沒有什麼影響;

雖然他們這次刪除了節點, 也裏面開始了下一次的分配; 但是因爲它重啓了 TargetBroker ；讓原來的任務順利的進行了下去; 哪怕沒有切換Controller, 也是不會影響下一次的重分配任務的;(因爲順利進行 Controller被通知的之前的已經結束了)

如果你有其他可能出現的異常,或者其他有關於kafka、es、agent等等相關問題,請聯繫我,我會補充這篇文章

<hr> 歡迎Star和共建由滴滴開源的kafka的管理平臺,非常優秀非常好用的一款kafka管理平臺 滿足所有開發運維日常需求

<a href="https://github.com/didi/LogiKM" title="進入LogiKM" target="top">滴滴開源LogiKM 一站式Kafka監控與管控平臺</a>

Kafka專欄整理地址請戳這裏0.0

【kafka實戰】分區重分配可能出現的問題和排查問題思路(生產環境實戰,乾貨!!!非常幹!!!建議收藏)

前提

所有異常情況

1. TargetBroker若不在線,遷移腳本執行會失敗

情景演示

2. TargetBroker在開始遷移過程中宕機，導致遷移任務一直在進行中

情景演示

解決方法

3. 被遷移副本沒有找到Leader,導致TargetReplica一直不能同步副本

情景演示

解決方案

4. 限流導致重分配一直完成不了

情景演示

解決方案

5. 數據量太大,同步的賊慢

解決方案

排查問題思路

1. 先看/admin/reassign_partitions裏面的數據

2. 再看brokers/topics/{TopicName}/partitions/{分區號}/state數據

3. 根據步驟2確定對應的Broker是否異常

4.查詢限流大小

5. 重新執行重分配任務(停止之前的任務)

情景演示

解決方案

排查工具+思考

現實案例分析

Java集合中的Set

安裝chromadb注意事項

前端面試題 - null是原始類型，但爲什麼typeof null的結果是object？

前端面試題 - 如何實現promise？

Java中的List

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結