Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Search/log analytics cluster'larında sorun yalnız RAM değildir; yanlış shard sayısı, hızlı büyüyen retention, ağır aggregation ve düşük disk headroom cluster health'i bozabilir. OpenSearch production yaklaşımı dedicated cluster-manager node'ları önerir.
OpenSearch resmî dokümantasyonu çoğu production kullanımında üç dedicated cluster-manager node'u doğru yaklaşım olarak belirtir. Data node'lar storage/search/indexing yükünü taşır ve zone'lar arasında dengelenmelidir.
Cluster-manager cluster state'i yönetir; data node shard'ları saklar ve sorgular; ingest node pipeline dönüşümlerini taşıyabilir; coordinating node sorguları dağıtır.
Elastic birçok kullanım için 10–50 GB shard aralığını ve shard başına 200 milyon belgenin altında kalmayı genel rehber olarak verir; gerçek optimum workload benchmark ile bulunmalıdır.
Primary data dışında replica, merge, segment overhead ve watermark headroom da disk ihtiyacını artırır.
Endpoint ve auth bilgilerini kendi cluster'ınıza göre uyarlayın.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
curl -s http://localhost:9200/_cluster/health?prettycurl -s http://localhost:9200/_cat/nodes?vcurl -s http://localhost:9200/_cat/shards?v | head -n 40curl -s http://localhost:9200/_cat/indices?v&s=store.size:desc | head -n 30Yeni node eklemek oversharding veya yanlış index lifecycle politikasını tek başına çözmez.
Aynı kökenden gelen ancak ayrı projelerdir. API benzerlikleri yüksek olsa da sürüm ve eklenti uyumluluğu ayrı doğrulanmalıdır.
Elastic birçok kullanım için 10–50 GB aralığını genel rehber olarak verir; gerçek optimum sorgu, recovery ve ingest benchmark'ıyla belirlenmelidir.
Çalışabilir ancak replica redundancy ve node failure toleransı sağlamaz; kritik production için multi-node cluster değerlendirilmelidir.
Günlük ingest, retention, index sayısı, query tipi ve mevcut shard dağılımını iletin; uygun node/RAM/NVMe topolojisini çıkaralım.