本文以EMR Kafka 2.4.1版本為例，介紹Kafka磁盤寫滿時的運維操作。

業(yè)務場景

Kafka將日志數(shù)據(jù)存儲到磁盤中，當磁盤寫滿時，相應磁盤上的Kafka日志目錄會出現(xiàn)offline問題。此時，該磁盤上的分區(qū)副本不可讀寫，降低了分區(qū)的可用性與容錯能力，同時由于leader遷移到其他Broker，增加了其他Broker的負載。因此，當磁盤出現(xiàn)寫滿情況時，應及時處理。

磁盤寫滿運維概述

本文從磁盤寫滿監(jiān)控和磁盤寫滿恢復角度來介紹磁盤寫滿運維策略。

磁盤寫滿監(jiān)控

Kafka服務層面：可以在云監(jiān)控系統(tǒng)中設置EMR Kafka集群的OfflineLogDirectoryCount指標告警，及時發(fā)現(xiàn)日志目錄offline的情況。

磁盤寫滿恢復

從排查問題角度來看，當Kafka出現(xiàn)log directory offline時，需要盡快定位是否是由于日志目錄所在磁盤寫滿導致的。

當日志目錄磁盤空間被寫滿時，您可以考慮如下運維策略：
  • 磁盤擴容：通過擴容云盤的方式來增加磁盤容量，適用于Broker掛載云盤的場景，詳情請參見磁盤擴容方式恢復。
  • 節(jié)點內分區(qū)遷移：將寫滿磁盤中的分區(qū)遷移到本節(jié)點的其他磁盤,適用于本Broker節(jié)點內磁盤使用率不均衡的場景，詳情請參見節(jié)點內分區(qū)遷移方式恢復。
  • 數(shù)據(jù)清理：清理寫滿磁盤的日志數(shù)據(jù)，適用于舊數(shù)據(jù)可以刪除的場景，詳情請參見數(shù)據(jù)清理方式恢復。

磁盤擴容方式恢復

方案描述

磁盤擴容方式是指當Broker磁盤空間被寫滿時，通過擴容磁盤存儲的方式來滿足磁盤需求。其優(yōu)點在于操作簡單、風險小、能夠快速解決磁盤空間不足的問題。

適用場景

適用于Broker掛載云盤的場景。

操作步驟

在EMR控制臺擴容Broker節(jié)點的數(shù)據(jù)盤，詳情請參見擴容磁盤。

節(jié)點內分區(qū)遷移方式恢復

方案描述

當Broker磁盤容量被寫滿時，對應的log directory被offline，無法使用kafka-reassign-partitions.sh工具遷移分區(qū)。此時，可以通過ECS實例層面的操作，將分區(qū)副本數(shù)據(jù)挪到當前Broker的其他磁盤并修改相應Kafka數(shù)據(jù)目錄元數(shù)據(jù)的方式來解決故障盤空間不足的問題。

適用場景

故障磁盤所在Broker使用容量不均衡、存在空間使用率較低的磁盤。

注意事項

  • 該方法只能進行節(jié)點內部磁盤遷移。
  • 分區(qū)遷移有可能導致磁盤的IO熱點，進而影響集群的性能。需要評估每次遷移數(shù)據(jù)的大小、遷移時長對業(yè)務的影響程度。
  • 由于該方法是非標操作，請在相應的Kafka版本測試后再用于生產集群。

操作步驟

當磁盤寫滿時，由于log directory已經offline了，所以不能用kafka-reassign-partitions.sh工具進行分區(qū)遷移。本文通過非標方式直接移動文件、修改Kafka相關元數(shù)據(jù)的方式來遷移分區(qū)。

  1. 創(chuàng)建測試Topic。
    1. 以SSH方式登錄到源Kafka集群的Master節(jié)點，詳情請參見登錄集群。
    2. 執(zhí)行以下命令，創(chuàng)建測試Topic，分區(qū)副本分布在Broker 0，1節(jié)點。
      kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --replica-assignment 0:1 --create
      您可以通過以下命令查看Topic詳情。
      kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
      返回如下信息，此時Broker 0是在Isr列表中的。
      Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 0       Replicas: 0,1   Isr: 0,1
  2. 執(zhí)行以下命令，模擬數(shù)據(jù)寫入。
    kafka-producer-perf-test.sh --topic test-topic --record-size 1000 --num-records 600000000 --print-metrics --throughput 10240 --producer-props linger.ms=0 bootstrap.servers=core-1-1:9092
  3. 修改Broker 0分區(qū)對應的日志目錄權限。
    1. 在Master節(jié)點上切換到emr-user賬號。
      su emr-user
    2. 免密碼登錄到對應的Core節(jié)點。
      ssh core-1-1
    3. 通過sudo獲得root權限。
      sudo su - root
    4. 執(zhí)行以下命令，查找分區(qū)所在磁盤。
      sudo find / -name test-topic-0
      返回信息如下，則表示分區(qū)在/mnt/disk4/kafka/log目錄下。
      /mnt/disk4/kafka/log/test-topic-0
    5. 執(zhí)行以下命令，將Broker 0分區(qū)對應的日志目錄權限設置成000。
      sudo chmod 000 /mnt/disk4/kafka/log
    6. 執(zhí)行以下命令，查看test-topic的狀態(tài)。
      kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
      返回信息如下，可以看到Broker 0已經不在Isr列表中了。
      Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 1       Replicas: 0,1   Isr: 1
  4. 停止Broker 0節(jié)點。

    在EMR控制臺停止Broker 0的Kafka服務。

  5. 執(zhí)行以下命令，將Broker 0的test-topic的分區(qū)移動到本節(jié)點的其他磁盤。
    mv /mnt/disk4/kafka/log/test-topic-0 /mnt/disk1/kafka/log/
  6. 修改文件。

    根據(jù)源目錄/mnt/disk4/kafka/log和目標目錄/mnt/disk1/kafka/log的元數(shù)據(jù)文件。需要修改的文件包括replication-offset-checkpoint和recovery-point-offset-checkpoint。

    • 修改replication-offset-checkpoint文件，將test-topic相關的條目從原日志目錄下的replication-offset-checkpoint文件挪到目標日志目錄的replication-offset-checkpoint中，并修改該文件條目的數(shù)量。修改replication-offset-checkpoint
    • 修改recovery-point-offset-checkpoint文件，將test-topic相關的條目從原日志目錄下的recovery-point-offset-checkpoint文件挪到目標日志目錄的recovery-point-offset-checkpoint中，并修改該文件條目的數(shù)量。修改recovery-point-offset-checkpoint
  7. 執(zhí)行以下命令，將源broker 0的日志目錄權限設置成正確的權限。
    sudo chmod 755 /mnt/disk4/kafka/log
  8. 啟動Broker 0節(jié)點。

    在EMR控制臺啟動Broker 0的Kafka服務。

  9. 執(zhí)行以下命令，觀察集群的狀態(tài)是正常的。
    kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe

數(shù)據(jù)清理方式恢復

方案描述

數(shù)據(jù)清理是指當磁盤被寫滿時，將業(yè)務日志數(shù)據(jù)（非Kafka內部Topic數(shù)據(jù)）按照從舊到新的方式刪除，直到釋放出足夠的空間。

適用場景

寫滿磁盤存在允許刪除的業(yè)務數(shù)據(jù)。

如果不改變數(shù)據(jù)的存儲時長，數(shù)據(jù)有可能又被快速的寫滿。因此，通常適用于因特殊情況而導致的數(shù)據(jù)突增的場景。

注意事項

不能刪除Kafka內部的Topic數(shù)據(jù)，即不能刪除以下劃線（_）開頭命名的Topic。

操作步驟

  1. 登錄到相應的機器上。
  2. 找到寫滿的磁盤，刪除掉不需要的業(yè)務數(shù)據(jù)。
    數(shù)據(jù)清理原則：
    • 不可直接刪除Kafka的數(shù)據(jù)目錄，避免造成不必要的數(shù)據(jù)丟失。
    • 找到占用空間較多或者明確不需要的Topic，選擇其中某些Partition，從最早的日志數(shù)據(jù)開始刪除。刪除segment及相應地index和timeindex文件。不要清理內置的Topic，例如__consumer_offsets和_schema等。
  3. 重啟磁盤被寫滿的相應的Broker節(jié)點，使日志目錄online。