Hapus index lama
DELETE /logs-2026.04
Troubleshooting
Disk Watermark & Flood Stage
Ketika disk node hampir penuh, Elasticsearch menerapkan pengaman bertingkat berupa watermark. Pada tahap terparah (flood stage), seluruh index di node itu dikunci menjadi read-only. Panduan ini menjelaskan tiga watermark, gejalanya, cara diagnosis, dan cara mengembalikan index agar bisa ditulis lagi.
Tiga Tingkat Watermark
| Watermark | Default | Setting | Yang terjadi |
|---|---|---|---|
| Low | 85% | ...disk.watermark.low | Tidak ada shard baru dialokasikan ke node ini. |
| High | 90% | ...disk.watermark.high | Shard mulai dipindahkan keluar dari node ini. |
| Flood stage | 95% | ...disk.watermark.flood_stage | Semua index di node dikunci read_only_allow_delete. |
Prefix lengkap setiap setting adalah cluster.routing.allocation.disk.watermark.*.
Watermark adalah pengaman, bukan error. Tujuannya mencegah disk penuh 100% yang bisa membuat node crash dan shard korup.
Gejala Flood Stage
# saat mencoba indexing { "error": { "type": "cluster_block_exception", "reason": "index [logs-2026.06] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];" }, "status": 429 }
# di log Elasticsearch
high disk watermark [90%] exceeded on [es-01] free: 4.2gb[4.1%]
flood stage disk watermark [95%] exceeded on [es-01],
all indices on this node will be marked read-only
Langkah 1 — Diagnosis
# persentase disk per node
GET /_cat/allocation?v
shards disk.indices disk.used disk.avail disk.total disk.percent node
24 96.4gb 98.1gb 1.9gb 100gb 98 es-01
# index terbesar pemakan disk GET /_cat/indices?v&s=store.size:desc&h=index,store.size,docs.count # cek setting watermark aktif GET /_cluster/settings?include_defaults=true&flat_settings=true&filter_path=**.watermark*
Tambahkan
&bytes=gb pada perintah _cat untuk menyeragamkan satuan ke gigabyte agar mudah dibaca.Langkah 2 — Bebaskan Disk
Hapus snapshot lama
DELETE /_snapshot/repo/snap_old
Perbesar volume
Tambah kapasitas disk / EBS lalu perluas filesystem. Solusi paling berkelanjutan.
Langkah 3 — Reset Blokir Read-Only
Setelah disk turun di bawah flood stage, lepas blokir agar index bisa ditulis kembali.
# lepas blokir untuk semua index PUT /_all/_settings { "index.blocks.read_only_allow_delete": null }
# atau untuk satu index spesifik
PUT /logs-2026.06/_settings
{
"index.blocks.read_only_allow_delete": null
}
Pakai
null untuk menghapus setelan, bukan false. Mengisi false menetapkan nilai eksplisit yang justru bisa mengganggu pengaman otomatis. null mengembalikan ke perilaku default.Langkah 4 — Sesuaikan Watermark (Opsional)
Pada disk besar, persentase default bisa menyisakan terlalu banyak ruang menganggur. Gunakan nilai absolut.
PUT /_cluster/settings
{
"transient": {
"cluster.routing.allocation.disk.watermark.low": "100gb",
"cluster.routing.allocation.disk.watermark.high": "50gb",
"cluster.routing.allocation.disk.watermark.flood_stage": "20gb"
}
}
Nilai di atas berarti: alokasi berhenti saat sisa < 100gb, pemindahan saat sisa < 50gb, dan read-only saat sisa < 20gb. Sesuaikan dengan kapasitas Anda; jangan setel flood_stage terlalu rendah.
Gunakan
persistent alih-alih transient bila ingin setelan bertahan setelah full cluster restart.Pencegahan
- Pantau
_cat/allocationdan pasang alert sebelum mencapai high watermark 90%. - Terapkan ILM (Index Lifecycle Management) untuk menghapus/menggulung index lama otomatis.
- Pisahkan data panas/dingin agar index lama pindah ke node berkapasitas besar.
- Sediakan headroom disk minimal 20-25% untuk merge segmen dan pemulihan shard.
FAQ Disk Watermark
Kenapa index saya tiba-tiba jadi read-only dan tidak bisa ditulis?
Kemungkinan besar disk node melewati flood stage (default 95%). Elasticsearch otomatis menerapkan blokir index.blocks.read_only_allow_delete=true pada semua index di node tersebut untuk mencegah disk benar-benar penuh. Anda perlu membebaskan disk lalu mereset blokir secara manual.
Apa beda low, high, dan flood stage watermark?
Low watermark (85%) menghentikan alokasi shard baru ke node penuh. High watermark (90%) memicu Elasticsearch memindahkan shard keluar dari node tersebut. Flood stage (95%) menjadikan index read-only agar tidak ada penulisan yang membuat disk penuh total.
Apakah blokir read_only_allow_delete hilang sendiri setelah disk lega?
Tidak otomatis pada versi lama; Anda harus mereset manual dengan PUT index.blocks.read_only_allow_delete: null setelah disk turun di bawah flood stage. Pada Elasticsearch 7.4+ blokir bisa dilepas otomatis bila disk kembali di bawah high watermark, tetapi mereset manual tetap praktik aman.
Bagaimana cara cepat membebaskan disk pada node Elasticsearch?
Hapus index lama yang tidak dipakai, hapus snapshot lama, pindahkan shard ke node lain, atau perbesar volume disk. Gunakan GET /_cat/allocation?v dan GET /_cat/indices?v&s=store.size:desc untuk menemukan konsumen disk terbesar.
Bersihkan index lama dengan aman
Pindahkan data lama ke snapshot sebelum dihapus agar disk lega tanpa kehilangan riwayat.
Panduan Snapshot ke S3