Yakın zamanda üzerinde 100M+ data bulunan 3 nodelu bir elastic-cluster’ı başka bir server’a taşıma serüvenimden bahsetmek istedim. Belki bu konu hakkında birilerine yol göstermek hemde benim yaptığım yanlışları görmek adına iyi olacağını düşünüyorum. Denediklerimi sırası ile yazıyorum. Hepsinde göz atmakta fayda var ben gördüğüm dezavantajlarda altlarına yazıyorum.
Data aktarmaya başlamadan önce
Sunucularınızın ve clusterızın speclerini bilmeniz çok önemli. Özellikle indexleriniz sürekli kullanımda ise makinelerinizde CPU artışını takip etmeniz gerekiyor. Eğer hızlı scale edebiliyorsanız arttırmanızda fayda var.
Veri bütünlüğünü korumak açısından taşıma sırasında indexerinize gelen veri akışını kesmeniz veya taşıyacağınız indexi, başka bir isimle reindexleyip taşımayı onun üzerinden işlem yapmanızı öneririm. Böylece data kaybını en aza indirmiş olursunuz.
Ben bu kısımda garantici takılmayı tercih ettim. Önce bir yedek alıp yedeği taşımak sonrasında yeni gelenleri üzerine yazma yolunu seçtim.
Elastic versiyonunu mutlaka kontrol edin. Özellikle elastic 1 -> 6 gibi major bir değişikliğe gidiyorsanız değişiklikleri dikkatlice okumanız gerekiyor. Ben 7.2’den 7.9’da sorunsuz bir şekilde geçiş yapabildim. Benim indexlerimin yapısını etkileyen herhangi bir major update olmadığı için daha rahat bir geçiş oldu.
Dataları direk olarak diğer server’a tekrar indexle
Ben bunu taşırım ya bir tane aktarıcı yazarım nodejs ile yoluma devam ederim diye düşünerek başladım. Basit bir nodejs aktarıcı yazarak taşımayı denedim.Basitce sürekli scroll edip aynı datayı diğer servera aktaran bir kod yazdım. 100M+ datanın 1 saatte ancak 4M aktarabildim. Kendi yazdığım aktarıcı burada yetersiz kaldı. Çok uzun sürdüğünü fark ettim.
Onun yerine popüler bir nodejs paketi buldum elasticdump aslında yazmaya gerek yokmuş zaten varmış. Bir gece yatmadan önce bu kütüphane ile başlattım 15 saatte tüm datayı aktarabildi.Yani saatte yaklaşık 6-7M lik bir data aktardı. Eziyet gibi biraz açıkcası 😀
Aktarımda bu arada elasticdump ile baya basit. Github sayfasında detayları bulabilirsiniz.
# Copy an index from production to staging with analyzer and mapping: elasticdump \ --input=http://production.es.com:9200/my_index \ --output=http://staging.es.com:9200/my_index \ --type=analyzer elasticdump \ --input=http://production.es.com:9200/my_index \ --output=http://staging.es.com:9200/my_index \ --type=mapping elasticdump \ --input=http://production.es.com:9200/my_index \ --output=http://staging.es.com:9200/my_index \ --type=data
Sonra öğrendim ki böyle serverlar arası data aktarmak için elasticdumpada gerek yok. Kibanayı açıp veya master nodeuzunda curl ile şunu reindex göndermeniz yeterli. Reindex methodonun remote versiyonu:
POST _reindex
{
"source": {
"remote": {
"host": "https://REMOTE_ELASTICSEARCH_ENDPOINT:PORT",
"username": "USER",
"password": "PASSWORD"
},
"index": "INDEX_NAME",
"query": {
"match_all": {}
}
},
"dest": {
"index": "INDEX_NAME"
}
}
Dezavantajları
- Büyük datasetlerinde data aktarım süresi çok uzun
- Offset problemleri var. Programınız yarıda durursa offset verip yeniden başlatayım derken data kaçırabilirsiniz. Elasticdump offset parametresi elastic 7.0 ve üstünde çalışmıyor.( Bizzat yaşadığım bir durumdur )
Snapshot alıp başka servera aktarmak
Bu aslında yapılması gereken yöntemlerden biri. Yukarıda anlattıklarım biraz kolay yol olarak düşünebilirsiniz. Eğer fazla datanız yok ise yukarıdaki yöntemleri kullanmanızı öneririm.
Eğer kendinize ait bir kvm veya aynı infrada bulunan başka bir makineye aktarım yapacak iseniz sunucu üzerinde full disk backup alıp o backup ile yeni makineyi açmak daha sağlıklı olabilir. Böylece hiç veri kaybı yaşamadan makinenizi birebir ayarlarla taşıyabilirsiniz. Bunun için clusterdaki tüm disklerin kopyalarını alıp yeni serverınıza taşımanız ve daha sonrasında elasticsearch.yml içindeki ip configlerini yeniden ayarlamanız gerekiyor.
Ama bunu yapmak yerine elasticsearch’de restore and backup yöntemini kullanabilirsiniz. Ben doc’dan öğrendiklerimi aşağıda adımlarla anlatmaya çalıştım.
Siz genede orjinal doc’dan ilerlemek isterseniz şuradan inceleyebilirsiniz.
Master nodemuzun olan sunucumuzun içine giriyoruz.
Snapshotları aktaracağımız bir dizin oluşturuyoruz. Bu dizin ikinci açtığınız server tarafından da erişilebilir olması gerekiyor. Bu konu için NFS Serveri araştırabilirsiniz veya custom repository oluşturarak amazon veya azure gibi storagelar kullanabilirsiniz. Bu konu için şuraya göz atmanızı öneririm.
mkdir ~/elasticsearch-backup/my-snapshot
Elasticsearch’e bu dizine yazma izni vermeyi atlamıyoruz
sudo chown -R elasticsearch:elasticsearch
İsterseniz kibana da bu komutları çalıştırabilirsiniz. Ben sunucu üzerinde bu komutları kullanmayı tercih ettim. Şimdi snapshot’ımızı register etmemiz gerekiyor yani snapshotun nereye alınacağı hakkında elasticsearchı bilgilendiriyoruz.
curl -XPUT localhost:9200/_snapshot/${SNAPSHOT_NAME} -d '{
"type": "fs",
"settings": {
"location": "elasticsearch-backup/my-snapshot",
"compress": true,
"chunk_size": "10m"
}
}'
Yukarıdaki tanımlamaları yaptıktan sonra hangi indexlerimizin bu snapshotu kapsıyacağını bildiriyoruz.Gene burada wildcard kullanabiliyorsunuz. my-index-* diyebilirsiniz kısaca. İkinci server’a aktaracağımız için bu adımı ikinci serverda yapmaya gerek yok.
curl -XPUT localhost:9200/_snapshot/my-snapshot
{
"indices": "my-index-1,my-index-2,...",
"ignore_unavailable": true,
"include_global_state": false,
"partial": false
}
Böylece rahatlıkla snapshot alabilirsiniz.
Snapshotları geri yükleme
Snapshotları geri yüklemek için tek yapmanız gereken yeni serverınıza girip aynı şekilde repo oluşturmak ve oluşturuduğumuz snapshotları belirttiğimiz klasöre aktarmak.
curl -XPOST localhost:9200/_snapshot/my-repository/_restore
{
"indices": "my-index-1,my-index-2,..",
"index_settings": {
"index.blocks.read_only": false
},
"ignore_index_settings": [
"index.refresh_interval"
]
}
Snapshotları geri yüklerken bu kısımlarda index isimleri ile oynayabilir ve değişiklikler yapabilirsiniz. Bu tarz değişiklikler yapmak için şu yazıdaki fieldlara göz atmanızı öneririm.
Thank you!!1