Elasticsearch strategie tworzenia kopii zapasowych na gorąco

Question

Byłoby interesujące, gdyby ktoś mógł udostępnić swoje najlepsze strategie "hot-backup" dla ElasticSearch.

Zapraszam również do udostępniania narzędzi i bibliotek związanych z tym problemem i pomagam.

Aktualizacja: Dziękuję @javanna za odpowiedź, to całkiem kompletne i zapewnia dobry kierunek dla dalszych działań.

Przeprowadziłem również małe badania i znalazłem kilka artykułów/dyskusji, które mogą pomóc, jeśli ktoś ma zainteresowanie.

• Elasticsearch backup strategies
• Backup/restore Elasticsearch index i related snippet on github:gist
• Elastic Search Backup and Recovery dyskusja (sprawdź komentarz Paula Smitha, również podzielił link przydatny do jego tool for verifying indexes)

Aktualizacja: Elasticsearch 1,0 mieć "oficjalne" rozwiązanie kopii zapasowej - Snapshot/Restore API i jest to teraz jedyna słuszna droga. ElasticSearch będzie identyfikować odłamki kapitana i dbać o spójność. Kopie zapasowe będą wykonywane przyrostowo, więc będziesz mógł to zrobić bardzo szybko i tak często, jak chcesz.

Answer 1

Repliki są rodzajem kopii zapasowej, a funkcja elastycznego przeszukiwania nigdy nie przydziela jednego w tym samym węźle, w którym znajduje się oryginalny podstawowy fragment. Ale nadal istnieje ryzyko utraty danych w zależności od liczby odłamków, replik i węzłów w klastrze.

Spojrzałbym na moduł Gateway, dzięki któremu można zapisać indeks i metadane klastra. Istnieje inny typ bramy. Patrzę na przykład na Shared FS, która pozwala skopiować indeks i metadane do systemu plików, który jest współdzielony między wszystkimi twoimi węzłami. Możesz również ręcznie uruchomić migawkę przez Gateway Snapshot API.

Można również wykonać kopię katalogu danych (na każdym węźle) po wyłączeniu przepłukiwania przez index.translog.disable_flush index setting. W ten sposób upewnisz się, że podczas kopiowania nie zostanie wydane polecenie lucene. Po wykonaniu kopii musisz ponownie włączyć kolor.

UPDATE

wszystkie typy bram z wyjątkiem jednego lokalnego zostały przestarzała i zostanie usunięta w przyszłej wersji. Elasticsearch 1.0 zostanie wydany z lepszym rozwiązaniem do tworzenia kopii zapasowych.

Answer 2

Jest to sprzeczne z działaniem ElasticSearch, ale rozważam posiadanie dwóch osobnych instancji ElasticSearch, które nie są sobie wzajemnie świadome. W kodzie aplikacji każde polecenie zostanie wysłane do obu instancji. Jeśli polecenie nie powiedzie się dla 1 wystąpienia, spróbuj ponownie wykonać to polecenie 1 minutę później i kontynuuj ponawianie próby. Teraz możesz zachować 1 instancję jako zapasową kopię zapasową lub możesz nawet użyć jej do zwiększenia wydajności, równoważąc obciążenie zapytań między 2 instancjami.

Powodem, dla którego nie lubię konfigurowania replik w ElasticSearch, jest ból w konfigurowaniu, który węzeł otrzymuje replikę, a jeśli chcesz zmienić organizację w przyszłości, musisz po prostu przejść przez tonę obręcze. ElasticSearch robi tonę równoważenia za kulisami i próbuje zrobić wszystko dla ciebie. Które może być dobre ...jeśli masz potężne serwery i nie obchodzi cię, co dostaje co ... ale może być ból inaczej.