當Kafka分區不可用且 副本被損壞時如何盡量減少數據的丟失

本篇文章為大家展示了當Kafka分區不可用且 副本被損壞時如何盡量減少數據的丟失，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

下面專門對分區不可用進行故障重現，并給出我的一些騷操作來盡量減少數據的丟失。

故障重現

下面我用一個例子重現現分區不可用且 leader 副本被損壞的例子：

1. 使用 unclean.leader.election.enable = false 參數啟動 broker0；

2. 使用 unclean.leader.election.enable = false 參數啟動 broker1；

3. 創建 topic-1，partition=1，replica-factor=2；

4. 將消息寫入 topic-1；

5. 此時，兩個 broker 上的副本都處于 ISR 中，broker0 的副本為 leader 副本；

6. 停止 broker1，此時 topic-1 的 leader 依然時 broker0 的副本，而 broker1 的副本從 ISR 中剔除；

7. 停止 broker0，并且刪除 broker0 上的日志數據；

8. 重啟 broker1，topic-1 嘗試連接 leader 副本，但此時 broker0 已經停止運行，此時分區處于不可用狀態，無法寫入消息；

9. 恢復 broker0，broker0 上的副本恢復 leader 職位，此時 broker1 嘗試加入 ISR，但此時由于 leader 的數據被清除，即偏移量為 0，此時 broker1 的副本需要截斷日志，保持偏移量不大于 leader 副本，此時分區的數據全部丟失。

我的建議

在遇到分區不可用時，是否可以提供一個選項，讓用戶可以手動設置分區內任意一個副本作為 leader？

因為集群一旦設置了 unclean.leader.election.enable = false，就無法選舉 ISR 以外的副本作為 leader，在極端情況下僅剩 leader 副本還在 ISR 中，此時 leader 所在的 broker 宕機了，那如果此時 broker 數據發生損壞這么辦？在這種情況下，能不能讓用戶自己選擇 leader 副本呢？盡管這么做也是會有數據丟失，但相比整個分區的數據都丟失而言，情況還是會好很多的。

我的騷操作

首先你得有一個不可用的分區（并且該分區 leader 副本數據已損失），如果是測試，可以以上故障重現 1-8 步驟實現一個不可用的分區（需要增加一個 broker）：

此時 leader 副本在 broker0，但已經掛了，且分區不可用，此時 broker2 的副本由于掉出 ISR ，不可選為 leader，且 leader 副本已損壞清除，如果此時重啟 broker0，follower 副本會進行日志截斷，將會丟失該分區所有數據。

經過一系列的測試與實驗，我總結出了以下騷操作，可以強行把 broker2 的副本選為 leader，盡量減少數據丟失：

1、使用 kafka-reassign-partitions.sh 腳本對該主題進行分區重分配，當然你也可以使用 kafka-manager 控制臺對該主題進行分區重分配，重分配之后如下：

此時 preferred leader 已經改成 broker2 所在的副本了，但此時的 leader 依然還是 broker0 的副本。需要注意的是，分區重分配之后的 preferred leader 一定要之前那個踢出 ISR 的副本，而不是分區重分配新生成的副本。因為新生成的副本偏移量為 0，如果自動重分配不滿足，那么需要編寫 json 文件，手動更改分配策略。

2、進入 zk，查看分區狀態并修改它的內容：

修改 node 內容，強行將 leader 改成 2（與重分配之后的 preferred leader 一樣），并且將 leader_epoch 加 1 處理，同時 ISR 列表改成 leader，改完如下：

此時，kafka-manager 控制臺會顯示成這樣：

但此時依然不生效，記住這時需要重啟 broker 0。

3、重啟 broker0，發現分區的 lastOffset 已經變成了 broker2 的副本的 lastOffset：

成功挽回了 46502 條消息數據，盡管依然丟失了 76053 - 46502 = 29551 條消息數據，但相比全部丟失相對好吧！

上述內容就是當Kafka分區不可用且 副本被損壞時如何盡量減少數據的丟失，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。