All Products
Search
Document Center

E-MapReduce:Lakukan operasi O&M saat disk space kluster EMR Kafka penuh

Last Updated:Jun 22, 2026

Topik ini menjelaskan cara melakukan operasi O&M saat ruang disk kluster Kafka penuh. Dalam topik ini, digunakan E-MapReduce (EMR) Kafka 2.4.1.

Skenario bisnis

Kafka menyimpan data log pada disk. Jika ruang disk penuh, direktori log Kafka pada disk tersebut menjadi offline. Dalam kondisi ini, replika partisi pada disk tidak dapat dibaca atau ditulis, sehingga mengurangi ketersediaan dan fault tolerance partisi. Beban broker lain meningkat karena replika partisi leader dimigrasikan ke broker lain. Oleh karena itu, Anda harus segera menangani masalah ini begitu ruang disk penuh.

Ikhtisar

Topik ini menjelaskan kebijakan O&M yang dapat digunakan saat ruang disk kluster Kafka penuh dari dua perspektif berikut: pemantauan dan pemulihan disk penuh.

Pantau disk penuh

Layanan Kafka: Anda dapat mengonfigurasi aturan alert untuk metrik OfflineLogDirectoryCount kluster EMR Kafka di Konsol CloudMonitor guna mendeteksi direktori log offline secara real time.

Pulihkan disk penuh

Jika direktori log Kafka pada disk menjadi offline, Anda harus terlebih dahulu memeriksa apakah ruang disk penuh.

Saat ruang disk untuk direktori log habis, pertimbangkan strategi O&M berikut:

  • Resize disk: Tingkatkan kapasitas disk dengan melakukan resize cloud disk. Metode ini cocok untuk skenario di mana broker menggunakan cloud disk yang disambungkan. Untuk informasi selengkapnya, lihat Pemulihan dengan resize disk.

  • Migrasi partisi intra-node: Migrasikan partisi dari disk penuh ke disk lain pada node yang sama. Metode ini cocok untuk skenario dengan penggunaan disk yang tidak seimbang pada node broker. Untuk informasi selengkapnya, lihat Pemulihan dengan migrasi partisi intra-node.

  • Pembersihan data: Hapus data log dari disk penuh. Metode ini berlaku jika data lama dapat dihapus dengan aman. Untuk informasi selengkapnya, lihat Pemulihan dengan pembersihan data.

Resize disk

Deskripsi

Jika ruang disk penuh pada broker, tingkatkan kapasitas disk untuk memenuhi kebutuhan terkait dengan menggunakan kebijakan ini. Keunggulan kebijakan ini adalah operasi yang sederhana, risiko rendah, dan kemampuan untuk segera menyelesaikan masalah ruang disk yang tidak mencukupi.

Skenario

Kebijakan ini berlaku untuk skenario di mana disk disambungkan ke broker.

Prosedur

Resize disk data pada node broker di Konsol E-MapReduce. Untuk informasi selengkapnya, lihat Resize disk.

Migrasikan partisi dalam satu broker

Deskripsi

Jika ruang disk penuh pada broker, direktori log Kafka pada disk tersebut menjadi offline. Akibatnya, Anda tidak dapat menggunakan tool kafka-reassign-partitions.sh untuk memigrasikan partisi. Dalam kasus ini, Anda dapat melakukan operasi pada instans Elastic Compute Service (ECS) tempat broker dideploy untuk memindahkan data replika partisi ke disk lain pada broker yang sama dan memodifikasi metadata di direktori data Kafka terkait. Hal ini membantu menyelesaikan masalah ruang disk yang tidak mencukupi.

Skenario

Kebijakan ini berlaku untuk skenario di mana penggunaan disk tidak seimbang pada broker karena adanya disk penuh dan disk lain dengan penggunaan relatif rendah.

Catatan penggunaan

  • Metode ini hanya mendukung migrasi partisi antar-disk dalam node yang sama.

  • Migrasi partisi dapat menyebabkan I/O hotspots pada disk, yang mungkin memengaruhi kinerja kluster. Anda harus mengevaluasi dampak ukuran data dan durasi setiap migrasi terhadap layanan Anda.

  • Karena metode ini melibatkan operasi non-standar, uji coba terlebih dahulu pada versi Kafka yang sesuai sebelum menerapkannya pada kluster produksi.

Prosedur

Jika ruang disk penuh, direktori log Kafka pada disk tersebut menjadi offline. Dalam kondisi ini, Anda tidak dapat menggunakan tool kafka-reassign-partitions.sh untuk memigrasikan partisi. Bagian ini menjelaskan cara melakukan operasi non-standar untuk memigrasikan partisi dengan langsung memindahkan file dan memodifikasi metadata terkait Kafka.

  1. Buat topik uji coba.

    1. Login ke node master kluster Kafka sumber menggunakan SSH. Untuk informasi selengkapnya, lihat Login ke kluster.

    2. Jalankan perintah berikut untuk membuat topik uji coba. Replika partisi didistribusikan pada broker 0 dan broker 1.

      kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --replica-assignment 0:1 --create

      Anda dapat menjalankan perintah berikut untuk melihat detail topik.

      kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe

      Informasi yang dikembalikan menunjukkan bahwa broker 0 ada dalam daftar In-Sync Replicas (ISR).

      Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
              Topic: test-topic       Partition: 0    Leader: 0       Replicas: 0,1   ISR: 0,1
  2. Jalankan perintah berikut untuk mensimulasikan penulisan data.

    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. Modifikasi izin direktori log pada broker 0.

    1. Pada node master, beralih ke akun emr-user.

      su emr-user
    2. Login ke node core terkait tanpa password.

      ssh core-1-1
    3. Gunakan sudo untuk mendapatkan izin root.

      sudo su - root
    4. Jalankan perintah berikut untuk menemukan disk tempat partisi berada.

      sudo find / -name test-topic-0

      Tanggapan berikut menunjukkan bahwa partisi berada di direktori /mnt/disk4/kafka/log.

      /mnt/disk4/kafka/log/test-topic-0
    5. Jalankan perintah berikut untuk mengatur izin direktori log pada broker 0 menjadi 000. Ini mensimulasikan error disk yang membuat direktori tidak dapat ditulis.

      sudo chmod 000 /mnt/disk4/kafka/log
    6. Jalankan perintah berikut untuk memeriksa status test-topic.

      kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe

      Informasi yang dikembalikan menunjukkan bahwa broker 0 tidak lagi ada dalam daftar ISR.

      Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
              Topic: test-topic       Partition: 0    Leader: 1       Replicas: 0,1   ISR: 1
  4. Hentikan layanan Kafka pada broker 0.

    Hentikan layanan Kafka pada Broker 0 di Konsol EMR.

  5. Jalankan perintah berikut untuk memindahkan partisi test-topic pada broker 0 ke disk lain pada node yang sama.

    mv /mnt/disk4/kafka/log/test-topic-0 /mnt/disk1/kafka/log/
  6. Modifikasi file metadata.

    Berdasarkan file metadata di direktori sumber /mnt/disk4/kafka/log dan direktori tujuan /mnt/disk1/kafka/log, file yang perlu dimodifikasi meliputi replication-offset-checkpoint dan recovery-point-offset-checkpoint.

    • Modifikasi file replication-offset-checkpoint dengan memindahkan entri yang terkait dengan test-topic dari file replication-offset-checkpoint di direktori log asal ke file replication-offset-checkpoint di direktori log tujuan, serta ubah jumlah entri dalam file tersebut. Pada file replication-offset-checkpoint yang telah dimodifikasi, baris pertama 0 adalah nomor versi, baris kedua 18 adalah jumlah total entri dalam file (harus sesuai dengan jumlah baris entri aktual), dan baris terakhir test-topic 0 4901378 adalah catatan offset partisi yang dimigrasikan. Contoh isi:

      0
      18
      __consumer_offsets 22 0
      __consumer_offsets 8 0
      __consumer_offsets 21 0
      __consumer_offsets 9 0
      __consumer_offsets 35 0
      __consumer_offsets 33 0
      __consumer_offsets 23 0
      __consumer_offsets 47 0
      __consumer_offsets 2 0
      __consumer_offsets 14 0
      __consumer_offsets 45 0
      __consumer_offsets 10 0
      __consumer_offsets 4 0
      __consumer_offsets 17 0
      __consumer_offsets 30 0
      __consumer_offsets 36 0
      __consumer_offsets 48 0
      test-topic 0 4901378
    • Modifikasi file recovery-point-offset-checkpoint. Pindahkan entri untuk test-topic dari file recovery-point-offset-checkpoint di direktori log asal ke file recovery-point-offset-checkpoint di direktori log tujuan, lalu perbarui jumlah total entri dalam file tujuan. Berikut contoh file recovery-point-offset-checkpoint yang telah dimodifikasi. Pada contoh ini, 13 pada baris kedua adalah jumlah total entri, dan test-topic 0 4952628 adalah entri yang dimigrasikan untuk test-topic:

      0
      13
      __consumer_offsets 22 0
      __consumer_offsets 8 0
      __consumer_offsets 21 0
      __consumer_offsets 9 0
      __consumer_offsets 35 0
      __consumer_offsets 33 0
      __consumer_offsets 23 0
      __consumer_offsets 47 0
      __consumer_offsets 2 0
      __consumer_offsets 14 0
      test-topic 0 4952628
      __consumer_offsets 45 0
      __consumer_offsets 10 0
  7. Jalankan perintah berikut untuk mengembalikan izin yang benar untuk direktori log pada broker 0 sumber.

    sudo chmod 755 /mnt/disk4/kafka/log
  8. Jalankan layanan Kafka pada broker 0.

    Jalankan layanan Kafka pada Broker 0 di Konsol EMR.

  9. Jalankan perintah berikut untuk memverifikasi bahwa status kluster normal.

    kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe

Bersihkan log

Deskripsi

Jika ruang disk penuh pada broker, hapus data log bisnis secara kronologis mulai dari data terlama hingga data terbaru hingga ruang disk yang cukup dilepaskan. Data pada topik internal kluster Kafka tidak dapat dihapus.

Skenario

Kebijakan ini berlaku untuk skenario di mana data log bisnis yang sudah kadaluarsa dapat dihapus dari disk penuh.

Jika periode retensi data tidak diubah, disk mungkin akan segera penuh kembali. Oleh karena itu, kebijakan ini umumnya berlaku untuk skenario di mana terjadi lonjakan data akibat keadaan khusus.

Catatan penggunaan

Anda tidak dapat menghapus data dari topik yang namanya diawali dengan garis bawah (_).

Prosedur

  1. Login ke mesin yang terdampak.

  2. Temukan disk penuh dan hapus data bisnis yang tidak diperlukan.

    Ikuti prinsip berikut untuk pembersihan data:

    • Jangan langsung menghapus direktori data Kafka untuk menghindari kehilangan data yang tidak perlu.

    • Identifikasi topik yang mengonsumsi banyak ruang atau tidak lagi diperlukan. Untuk partisi terpilih dalam topik tersebut, mulailah menghapus segmen log terlama. Ini mencakup penghapusan file .log, .index, dan .timeindex untuk setiap segmen. Jangan menghapus data dari topik internal, seperti __consumer_offsets dan _schema.

  3. Restart layanan Kafka pada broker yang terdampak untuk mengembalikan direktori log ke status online.