Klastry Follower to funkcja ScaleGrid, która umożliwia synchronizację dwóch niezależnych systemów baz danych (tego samego typu). W przeciwieństwie do klonowania lub replikacji pozwala to zachować aktywną kopię danych produkcyjnych z określonego punktu w czasie. Ten dodatkowy klaster, znany jako klaster obserwujących, może być wykorzystywany do wielu zastosowań, w tym do analizowania, optymalizacji i testowania wydajności aplikacji dla MongoDB, MySQL i PostgreSQL. W tym poście na blogu omówimy trzy najważniejsze scenariusze wykorzystania klastrów obserwujących w Twojej aplikacji.
Czym klastry obserwatorów różnią się od replikacji?
W przeciwieństwie do statycznego klonu, te dane są importowane zgodnie z ustalonym harmonogramem, dzięki czemu klaster obserwatorów jest zawsze zsynchronizowany z klastrem produkcyjnym. Oto kilka krytycznych sposobów, w jakie różni się od replikacji:
- Możesz kontrolować, jak często system docelowy synchronizuje się ze źródłem — raz w tygodniu, raz dziennie lub nawet rzadziej. Pomaga to zmniejszyć obciążenie systemu źródłowego.
- Ponieważ są to dwa niezależne systemy, masz znacznie większą elastyczność w zakresie synchronizowanych danych. Możesz mieć różne poświadczenia użytkownika, a nawet usunąć niektóre dane z miejsca docelowego w oparciu o wymagania bezpieczeństwa (uwaga:wymaga to skryptów po stronie użytkownika – nie jest to wbudowana funkcja klastrów obserwujących).
- System „obserwatora” jest zapisywalny, więc można go używać jako środowiska pomostowego do testowania zmian w aplikacji. To nie jest coś, co możesz zrobić na węźle repliki.
Uwaga:ScaleGrid implementuje klastry obserwatorów przy użyciu migawek pamięci. Nie jest dostępna dla naszych ofert baz danych w pamięci, takich jak hosting dla Redis™*.
1. Konfiguracja tworzenia/testowania bazy danych
Wszyscy tam byliśmy – podobno dobrze przetestowany fragment kodu zostaje wdrożony w produkcji, a potem rozpętuje się piekło. Produkcyjne przepływy pracy zawodzą lub są tak powolne, że w zasadzie nie nadają się do użytku. Inżynierowie budzą się ze swoich łóżek, aby rozpocząć pełną operację gaszenia pożaru. Kilka nieprzespanych nocy później pojawia się ta przerażająca przyczyna.
Aplikacja zachowuje się inaczej w konfiguracjach produkcyjnych i inżynieryjnych.
Innymi słowy, przetestowaliśmy to na „danych testowych”. Co, jak się okazuje, w niczym nie przypominało danych produkcyjnych. W ogóle.
Oczywistym sposobem uniknięcia tej sytuacji jest przeprowadzenie testów na danych produkcyjnych. Oczywiście nie rzeczywista produkcja – to będzie flirt z katastrofą. Na sklonowanej kopii danych produkcyjnych. Chociaż obawy dotyczące prywatności i bezpieczeństwa danych sprawiają, że jest to niewykonalne w wielu sytuacjach, jeśli pozwalają na to wymagania dotyczące prywatności, jest to najlepsze rozwiązanie. Nie musimy już polegać na inżynierach generujących odpowiednie zestawy danych – jeśli przekażą dane testowe, przekażą również dane produkcyjne.
Oznacza to, że dane testowe nie będą tak bardzo zsynchronizowane z produkcją, że nie jest to już dobre przybliżenie. I jesteśmy z powrotem w punkcie wyjścia.
Tu właśnie pojawiają się grupy obserwujących.
Korzystając z klastrów obserwujących, możesz okresowo importować dane z produkcyjnej bazy danych do bazy danych dev/test. A ponieważ cały import odbywa się za pomocą migawek pamięci masowej, a nie zrzutu logicznego, proces ten jest niemal natychmiastowy. Możesz zaplanować importowanie raz na 24 godziny, raz w tygodniu lub z dowolną częstotliwością odpowiadającą Twojemu scenariuszowi.
Z klastrami programistycznymi i QA ustawionymi tak, aby podążały za klastrem produkcyjnym, możesz spać spokojnie. Jeśli Twoja aplikacja przekaże testowy zestaw danych, zdecydowanie nadaje się do wdrożenia w środowisku produkcyjnym!
2. Analiza danych
Jeśli pracowałeś jako administrator baz danych, prawdopodobnie rozmawiałeś ze swoim zespołem na temat „tajemniczego” spowolnienia wydajności systemu w pewnych momentach. W większości przypadków winowajcą okazuje się zadanie analityczne, które uzyskuje dostęp do mnóstwa danych i w efekcie spowalnia cały system.
Jako dostawca DBaaS wielokrotnie prowadziliśmy tę rozmowę z naszymi klientami. Oto dwie opcje, które zwykle proponujemy:
- Jeśli zadanie analizy działa na serwerze głównym/głównym, przenieś je na serwer pomocniczy/replikę.
- Jeśli zadanie analityczne działa już w węźle dodatkowym, a pogorszenie wydajności jest niedopuszczalne, zalecamy przeniesienie zadań do dedykowanego klastra analitycznego.
Dzięki naszej funkcji klastra obserwatorów bardzo łatwo jest aktualizować klaster analityczny o rzeczywiste dane produkcyjne. Możesz utworzyć harmonogram obserwatorów, aby zsynchronizować najnowsze dane z produkcji tuż przed rozpoczęciem zadania analitycznego.
Najlepsza część? Synchronizacja obserwujących nie wykonuje żadnych operacji na poziomie bazy danych — przywraca jedynie najnowszą migawkę! Tak więc nie ma żadnego wpływu na klaster produkcyjny.
3. Raportowanie
Innym częstym przypadkiem użycia, w którym nasi klienci korzystają z funkcji klastrów obserwujących, jest generowanie raportów. Procesy raportowania zwykle działają rzadko, ale uzyskują dostęp do dużych ilości danych i zajmują większość zasobów klastra bazy danych. Gdy pogorszenie wydajności jest niedopuszczalne, zalecamy naszym klientom przeniesienie obciążenia raportowania do nowego klastra.
Ponieważ operacje raportowania są rzadkie, wielu naszych klientów woli korzystać z naszej funkcji wstrzymywania/wznawiania, aby „wstrzymywać” klastry raportowania, gdy nie są one używane. Pomaga to znacznie zaoszczędzić na kosztach infrastruktury. Zazwyczaj klastry raportowania są również znacznie „mniejsze” (mniejszy procesor/RAM), co pomaga obniżyć koszty.
Po utworzeniu klastra obserwatorów z naszego interfejsu użytkownika możesz użyć tego przepływu pracy do zautomatyzowania przepływu raportów:
- Użyj naszego interfejsu API do wznowienia, aby wznowić klaster.
- Poczekaj, aż klaster powróci do stanu działania (w tym celu możesz użyć swojego interfejsu API get-status).
- W razie potrzeby uruchom tworzenie kopii zapasowej w klastrze produkcyjnym (zazwyczaj, jeśli regularne tworzenie kopii zapasowych jest zaplanowane w środowisku produkcyjnym, możesz pominąć ten krok. Jeśli jednak chcesz, aby raporty były uruchamiane na najnowszych danych, jest to niezbędne).
- Poczekaj na zakończenie tworzenia kopii zapasowej.
- Uruchom zadanie synchronizacji na obserwatorze – spowoduje to znalezienie najnowszej migawki w klastrze źródłowym i przywrócenie do miejsca docelowego.
- Poczekaj na zakończenie zadania synchronizacji.
- Uruchom swoje zadania raportowania.
- Użyj naszego interfejsu API pauzy, aby wstrzymać klaster do następnego zadania raportowania!
Czy uważasz, że klastry obserwujących dobrze pasują do konkretnego przypadku użytkownika? Możesz dowiedzieć się wszystkiego o tym, jak wdrażać i zarządzać klastrami obserwujących dla MongoDB, MySQL i PostgreSQL w naszych dokumentach pomocy!
Jeśli nie masz pewności, czy klastry obserwujących są właściwym rozwiązaniem dla Twojego przypadku użycia, zostaw komentarz lub skontaktuj się z nami pod adresem [email protected] – my chętnie omówimy, która funkcja najlepiej odpowiada Twoim wymaganiom.
