#Kısa Notlar : Elasticsearch Node Clone Sonrası Clustering Problemi MasterNotDiscoveredException

By Burak TUNGUT - 15.3.2017 - Kategori DevOps

Selamlar herkese,

Bugün uzunca yazmaktansa karşılaştığım ve yaklaşık olarak 3-4 saatimi alan problemin nasıl çözüldüğünü anlatacağım. Artık yavaş yavaş bu kapsamda, kısa not niteliği taşıyacak şeyleride paylaşmaya başlayacağım.

Tüm search yapımızı elasticsearch'e geçirmeyi planladığımız şu günlerde bir kaç yeni failover stratejisini denemek için 5 adet master node'a ihtiyacım vardı. Bunun için DC'de bir adet host üzerine bir Centos minimal VM kurdum. Onun üzerine ise Elasticsearch ve Kibana 5'i kurdum.

#Kısa Notlar : Elasticsearch Node Clone Sonrası Clustering Problemi MasterNotDiscoveredException

Tekar aynı adımları tekrarlamaktansa kurduğum VM'i clone'ladım fakat hepimizin clustering için gerekli olduğunu bildiğimiz konfigürasyonları yapmama rağmen ikinci sırada ayağa kalkan node'dan ısrarla MasterNotDiscoveredException aldım. Bu exception tek başına çok anlamlı olmayacaktır çünkü genelde network'de oluşan sorunlardan dolayı ya da unicast'te hiç bir master node'un olmamasından dolayı böyle bir hata ile karşılaşabiliyoruz. Kontrol ettiğimde node'lar ayakta ve her biri 9300 portu ile haberleşebilecek durumda idi.

Index log'larda ise şöyle bir ayrıntı yakaladım; with the same id but is a different node instance

Buradaki asıl problem elasticsearch'ün data folder'a her bir index için attığı klasör ve içerdiği segment file'ların aslında node ismini içermesi. E haliyle clone ettiğim ve sonradan adını değiştirdiğim node'un file'larında eski node'un isimleri geçiyor. Kısacası clone sonrası bu dosyaları silmemiz gerekiyor :) Zaten data node ise sharding başlayacak ve alması gereken index'lerin segment'lerini almaya başlayacaktır.

Sorunu çözmek için data folder'ı boşaltmanız yeterli olacaktır. Not olarak şunuda söylemek isterim ki MasterNotDiscoveredException sadece bu nedenle JVM tarafından fırlatılan bir hata değildir. Değindiğim sorun ve çözüm bu hatayı oluşturan case'lerden sadece birtanesi.

Herkese iyi çalışmalar,
Burak.

Devamı

Elasticsearch Serisi : 02 Mimari Özellikleri, Sharding, Failovering ve Scaling

By Burak Tungut - 10.12.2015 - Kategori DevOps

Herkese selam!

Blogumu takip ediyorsanız bir önceki makalem Elasticsearch Serisi : 01 Ubuntu Server'a Elasticsearch Kurulumu idi. Eğer seriye yeni başlayacaksanız ve hiç elasticsearch kurulumu gerçekleştirmediyseniz bir göz atmanızda fayda var derim.

Bugün ise aşağıda göreceğiniz ve elasticsearch'de bilmemiz gereken terimlere değineceğiz. Son iki maddemiz olan shards ve replicas'lara biraz ayrıcalık tanıyacağız. Çünkü makalenin odak noktası olarak onları belirledim. Sonraki bölümlerde detaylarıyla diğer maddelerede değineceğiz.

  1. Node
  2. Cluster
  3. Index
  4. Type
  5. Mapping
  6. Document
  7. Shard ve Replica

Bazı yabancı kaynakları incelerseniz node'lardan önce cluster'ları incelediklerini görebilirsiniz. Bu gerçekten garibime gidiyor. Neden mi? Aşağıda değindim. Haydi başlayalım.

Node

Elasticsearch node ismi

Bir server üzerine kurduğumuz ve sonraki makalelerimizde göreceğimiz document'larımızı index'leyip, üzerlerinde query'ler çalıştıracağımız tek bir elasticsearch instance'ına verdiğimiz isimdir. Buna örnek olarak bir önceki makalemizde ubuntu server üzerine kurduğumuz elasticsearch instance'ını verebiliriz. Kendileri bir node olurlar. 

Kurduğumuz bir node özellikle müdahele etmediysek random bir isim alır. Elasticsearch geliştiricileri random bir string vermektense Marvel karakterlerinden bir tanesini random seçerek atanmasını sağlamışlardır. Hatta gelin bir önceki makalede kurduğumuz elasticsearch node'unun ismine bir bakalım.

Bunun için /_nodes endpoint'ine HTTP GET request atmamız yeterli olacaktır. Sense yardımıyla bir request atalım ve node'umuza Marvel karakterlerinden atanan ismi görelim.

Beklentim bir Hulk idi fakat ilk defa duyduğum Balthakk ismi ile karşılaştım smiley

Eğer sonraki alt konuda inceleyeceğimiz gibi bir cluster'ımız varsa ve çok fazla node üzerinde çalışıyorsak yönetilebilirlik açısından default isimler yerine bizim vereceğimiz isimleri tercih etmek durumunda kalabiliiz. Bir node'un ismini sadece bir HTTP POST ile sonradan değiştirebiliyoruz. REST API'lar üzerine kurulu olmasının bir faydası daha! 

Dikkatinizi birde resimdeki ilk key'lerden cluster_name'e çekmek isterim. Bu da node'un dahil edileceği cluster ismimiz. Eğer aynı network'de birden fazla cluster'ımızda varsa default cluster ismi yerine yine kendimiz bir cluster ismi vermek durumunda kalabiliriz diyelim ve şimdi cluster ile konumuza devam edelim.

Devamı
1
Facebook
Son Yorumlar