Perbaiki ruang disk penuh pada kluster EMR Kafka - E-MapReduce

Ketika disk pada broker Kafka penuh, direktori log Kafka pada disk tersebut menjadi offline. Replika partisi yang berada di direktori offline tidak dapat lagi dibaca atau ditulis, sehingga partisi yang terdampak kehilangan ketersediaan dan replika leader bermigrasi ke broker lain—meningkatkan beban broker tersebut. Segera atasi masalah disk penuh untuk memulihkan kesehatan kluster.

Topik ini menggunakan E-MapReduce (EMR) Kafka 2.4.1 sebagai contoh versi.

Cara kerja

Kafka menulis semua data pesan ke direktori log pada disk. Setiap broker dapat memiliki beberapa disk, masing-masing menyimpan satu atau lebih direktori log. Ketika sebuah disk mencapai kapasitas penuh:

Direktori log pada disk tersebut menjadi offline.
Replika partisi dalam direktori offline berhenti menerima operasi baca dan tulis.
Kafka memindahkan replika leader ke broker lain, meningkatkan beban mereka.
Ketersediaan dan toleransi kesalahan kluster menurun hingga masalah disk terselesaikan.

Memantau penggunaan disk

Buat peringatan CloudMonitor pada metrik OfflineLogDirectoryCount untuk kluster EMR Kafka Anda. Ketika nilai ini melebihi 0, setidaknya satu direktori log sudah offline—segera lakukan tindakan menggunakan salah satu strategi pemulihan di bawah ini.

Pilih strategi pemulihan

Strategi	Kapan digunakan	Risiko	Upaya
Resize a disk	Disk yang terpasang pada broker memiliki kapasitas tidak mencukupi	Rendah	Rendah
Migrate partitions within a broker	Penggunaan disk tidak seimbang di antara disk-disk pada broker yang sama	Sedang — dapat menyebabkan hotspot I/O	Tinggi
Clear logs	Data log bisnis lama dapat dihapus, atau terjadi lonjakan data akibat event khusus	Sedang — data dihapus secara permanen	Sedang

Resize a disk

Mengubah ukuran disk yang penuh secara langsung menambah kapasitas tanpa memindahkan data. Ini merupakan opsi dengan risiko terendah dan cara tercepat untuk memulihkan layanan ketika disk broker penuh.

Di Konsol EMR, ubah ukuran disk yang terpasang pada broker yang terdampak. Untuk langkah-langkah detail, lihat Expand a disk.

Migrate partitions within a broker

Ketika sebuah disk penuh, direktori log-nya menjadi offline dan alat kafka-reassign-partitions.sh tidak dapat memindahkan partisi—alat ini memerlukan direktori agar dapat diakses. Sebagai gantinya, pindahkan langsung file data partisi pada instans Elastic Compute Service (ECS) tempat broker berjalan, lalu perbarui file metadata Kafka agar mencerminkan lokasi baru tersebut.

Strategi ini hanya memindahkan partisi antar disk pada broker yang sama. Strategi ini tidak memindahkan data antar broker.

Catatan penggunaan

Migrasi partisi dapat menyebabkan hotspot I/O pada disk, yang mungkin memengaruhi kinerja kluster. Evaluasi ukuran dan durasi setiap migrasi sebelum melanjutkan.
Uji prosedur ini pada kluster non-produksi yang menjalankan versi Kafka yang sama sebelum menerapkannya di lingkungan produksi.

Prosedur

Langkah-langkah berikut menggunakan topik uji untuk mengilustrasikan migrasi. Ganti path contoh, nama topik, dan ID broker dengan nilai aktual Anda.

Buat topik uji.
1. Login ke node master kluster Kafka melalui SSH. Untuk detailnya, lihat Log on to a cluster.
2. Buat topik uji bernama test-topic dengan replika pada Broker 0 dan Broker 1:
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --replica-assignment 0:1 --create
```
3. Verifikasi topik tersebut. Kedua broker harus muncul dalam daftar in-sync replicas (ISR):
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
  Output yang diharapkan — Broker 0 adalah leader dan kedua broker ada dalam daftar ISR:
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 0       Replicas: 0,1   Isr: 0,1
```

Simulasikan penulisan data (opsional — lewati jika Anda sedang menangani disk penuh yang sudah ada):

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

Simulasikan disk penuh dengan membatasi izin direktori log pada Broker 0. Di node master, beralih ke akun emr-user dan login ke node core:
```
su emr-user
ssh core-1-1
```
Dapatkan izin root:
```
sudo su - root
```
Cari disk mana yang menyimpan partisi test-topic-0:
```
sudo find / -name test-topic-0
```
Jika output-nya /mnt/disk4/kafka/log/test-topic-0, maka partisi tersebut berada di /mnt/disk4. Atur izin direktori log menjadi 000 untuk mensimulasikan status offline:
```
sudo chmod 000 /mnt/disk4/kafka/log
```
Verifikasi bahwa Broker 0 telah dihapus dari daftar ISR:
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
Output yang diharapkan — Broker 0 tidak lagi berada dalam daftar ISR:
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 1       Replicas: 0,1   Isr: 1
```
Hentikan Broker 0. Di Konsol EMR, hentikan layanan Kafka pada Broker 0.

Pindahkan data partisi ke disk berbeda pada Broker 0:

mv /mnt/disk4/kafka/log/test-topic-0 /mnt/disk1/kafka/log/

Perbarui file metadata Kafka baik di direktori sumber (/mnt/disk4/kafka/log) maupun direktori tujuan (/mnt/disk1/kafka/log). Perbarui kedua file berikut:
- replication-offset-checkpoint: Pindahkan entri yang terkait test-topic dari file sumber ke file tujuan, dan perbarui jumlah entri di kedua file tersebut.
- recovery-point-offset-checkpoint: Pindahkan entri yang terkait test-topic dari file sumber ke file tujuan, dan perbarui jumlah entri di kedua file tersebut.
Pulihkan izin direktori log pada Broker 0:
```
sudo chmod 755 /mnt/disk4/kafka/log
```
Jalankan Broker 0. Di Konsol EMR, jalankan layanan Kafka pada Broker 0.
Verifikasi kluster dalam kondisi sehat:
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
Kedua broker seharusnya kembali muncul dalam daftar ISR, yang mengonfirmasi keberhasilan migrasi partisi.

Clear logs

Hapus data log bisnis dari disk yang penuh untuk membebaskan ruang. Data dihapus secara kronologis, dimulai dari segmen log terlama.

Penting

Penghapusan data log bersifat ireversibel. Jangan hapus data dari topik internal Kafka, termasuk __consumer_offsets dan _schema. Jangan hapus topik yang namanya diawali garis bawah (_).

Strategi ini cocok untuk memulihkan diri dari lonjakan data akibat kejadian luar biasa. Jika Anda tidak menyesuaikan periode retensi setelah membersihkan log, disk akan kembali penuh.

Prosedur

Login ke mesin tempat disk penuh berada.
Identifikasi disk penuh dan hapus data log bisnis yang tidak diperlukan:
- Jangan menghapus direktori data kluster Kafka itu sendiri.
- Cari topik yang menempati ruang besar atau yang tidak lagi diperlukan.
- Untuk topik yang telah diidentifikasi, hapus segmen log mulai dari data terlama. Hapus file indeks dan timeindex yang sesuai bersamaan dengan setiap segmen log.
- Jangan menghapus data dari topik internal seperti __consumer_offsets dan _schema.
Mulai ulang broker tempat disk penuh berada untuk mengembalikan direktori log ke status online.