Mysql
 sql >> Baza danych >  >> RDS >> Mysql

Zautomatyzuj wdrażanie swojego klastra MySQL lub Postgres z kopii zapasowej

ClusterControl 1.7.1 wprowadza nową funkcję o nazwie Utwórz klaster z kopii zapasowej, która umożliwia wdrożenie nowego klastra opartego na MySQL lub Postgres i przywracanie danych z kopii zapasowej. Ten wpis na blogu pokazuje, jak działa ta nowa funkcja i jak ten rodzaj automatyzacji może zapewnić ulepszenia w operacjach infrastrukturalnych.

Wprowadzenie:tworzenie klastra z kopii zapasowej

Zarządzanie kopiami zapasowymi to ulubiona funkcja naszych użytkowników, a my właśnie przenieśliśmy ją na wyższy poziom. Ta nowa funkcja brzmi prosto — ClusterControl 1.7.1 jest w stanie wdrożyć nowy klaster z istniejącej kopii zapasowej. Istnieje jednak wiele procedur i kontroli związanych z wdrożeniem klastra klasy produkcyjnej bezpośrednio z kopii zapasowej. Samo przywracanie wiąże się z własnymi wyzwaniami, takimi jak:

  • Całkowite lub częściowe konsekwencje przywracania
  • Podstawowa kopia zapasowa i kolejność jej przyrostowych kopii zapasowych (w przypadku przyrostowej kopii zapasowej)
  • Odszyfrowywanie kopii zapasowej (jeśli jest zaszyfrowane)
  • Opcje narzędzia przywracania
  • Dekompresja (jeśli skompresowana)
  • Transmisja strumieniowa kopii zapasowej ze źródła na serwer docelowy
  • Wykorzystanie miejsca na dysku podczas przywracania i po nim
  • Raportowanie postępu przywracania

Połączenie powyższego ze złożonością i powtarzalnością zadań wdrażania klastra bazy danych pozwala zaoszczędzić czas i zmniejszyć ryzyko związane z uruchamianiem podatnych na błędy procedur. Najtrudniejszą częścią z punktu widzenia użytkownika jest wybór kopii zapasowej do przywrócenia. ClusterControl zajmie się podnoszeniem ciężarów za sceną i zgłosi wynik końcowy po zakończeniu.

Kroki są w zasadzie proste:

  1. Skonfiguruj bezhasło SSH z węzła ClusterControl do nowych serwerów.
  2. Wybierz jedną logiczną kopię zapasową z listy kopii zapasowych lub utwórz ją w sekcji Kopie zapasowe -> Utwórz kopię zapasową .
  3. Kliknij Przywróć -> Utwórz klaster z kopii zapasowej i postępuj zgodnie z kreatorem wdrażania.

Ta funkcja jest obecnie stworzona specjalnie dla MySQL Galera Cluster i PostgreSQL. Oto, co zobaczysz w interfejsie użytkownika po kliknięciu „Przywróć” na istniejącej kopii zapasowej:

Dolna opcja jest tym, czego szukamy. Następnie znajduje się okno dialogowe podsumowania wybranej kopii zapasowej przed konfiguracją wdrożenia:

Następnie ten sam kreator wdrażania klastra bazy danych dla odpowiedniego klastra (MySQL Galera Cluster lub PostgreSQL) zostanie wyświetlony w celu skonfigurowania nowego klastra:

Pamiętaj, że musisz podać tę samą nazwę użytkownika i hasło root/admin bazy danych, co w kopii zapasowej. W przeciwnym razie wdrożenie zakończy się niepowodzeniem w połowie podczas uruchamiania pierwszego węzła. Ogólnie procedury przywracania i wdrażania będą odbywać się w następującej kolejności:

  1. Zainstaluj niezbędne oprogramowanie i zależności na wszystkich węzłach bazy danych.
  2. Uruchom pierwszy węzeł.
  3. Przesyłaj strumieniowo i przywracaj kopię zapasową w pierwszym węźle (z flagą automatycznego restartu).
  4. Skonfiguruj i dodaj resztę węzłów.

Nowy klaster bazy danych zostanie wyświetlony w panelu klastra ClusterControl po zakończeniu zadania.

Co możesz dzięki temu zyskać?

Istnieje wiele rzeczy, które mogą przynieść korzyści z tej funkcji, jak wyjaśniono w poniższych sekcjach.

Przetestuj swój zbiór danych w różnych warunkach

Czasami możesz się zastanawiać, czy nowa wersja bazy danych będzie działać lub działać w przypadku obciążenia bazy danych, a przetestowanie jej to jedyny sposób, aby się dowiedzieć. Tutaj przydaje się ta funkcja. Pozwala przeprowadzać testy i testy porównawcze na wielu zaangażowanych zmiennych, które mogłyby wpłynąć na stabilność lub wydajność bazy danych, na przykład sprzęt bazowy, wersję oprogramowania, dostawcę i obciążenia bazy danych lub aplikacji.

Dla prostego przykładu, istnieje duża poprawa w wykonywaniu DDL między MySQL 5.6 a MySQL 5.7. Poniższa operacja DROP na tabeli z 10 milionami wierszy dowodzi tego wszystkiego:

mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)
mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

Posiadanie innego klastra do porównania faktycznie pozwala nam zmierzyć poprawę i uzasadnić migrację.

Migracja bazy danych z logiczną kopią zapasową

Logiczna kopia zapasowa, taka jak mysqldump i pg_dumpall to najbezpieczniejszy sposób na uaktualnienie, obniżenie wersji lub migrację danych z jednej wersji lub dostawcy do innej. Wszystkie logiczne kopie zapasowe można wykorzystać do przeprowadzenia migracji bazy danych. Kroki aktualizacji bazy danych są w zasadzie proste:

  1. Utwórz (lub zaplanuj) logiczną kopię zapasową - mysqldump dla MySQL lub pg_dumpall dla PostgreSQL
  2. Skonfiguruj bezhasło SSH z węzła ClusterControl na nowe serwery.
  3. Wybierz jedną utworzoną logiczną kopię zapasową z listy kopii zapasowych.
  4. Kliknij Przywróć -> Utwórz klaster z kopii zapasowej i postępuj zgodnie z kreatorem wdrażania.
  5. Zweryfikuj przywrócenie danych w nowym klastrze.
  6. Wskaż swoją aplikację do nowego klastra.

Szybszy całkowity czas odzyskiwania klastra

Wyobraź sobie katastrofalną awarię, która uniemożliwia działanie klastra, na przykład awarię centralnego magazynu, która dotknęła wszystkie podłączone do niego maszyny wirtualne, możesz uzyskać klaster zastępczy niemal natychmiast (pod warunkiem, że pliki kopii zapasowej są przechowywane poza uszkodzonymi węzłami baz danych , mówić rzeczy oczywiste). Tę funkcję można zautomatyzować za pomocą klienta s9s, w którym można uruchomić zadanie za pomocą interfejsu wiersza poleceń, na przykład:

$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

Jedną z rzeczy, na które należy zwrócić uwagę podczas korzystania z tej funkcji, jest użycie tej samej nazwy użytkownika i hasła administratora, które są przechowywane w kopii zapasowej. Ponadto należy wcześniej skonfigurować protokół SSH bez hasła do wszystkich węzłów bazy danych. W przeciwnym razie, jeśli wolisz skonfigurować go interaktywnie, po prostu użyj interfejsu internetowego interfejsu użytkownika.

Skalowanie w poziomie za pomocą replikacji asynchronicznej

W przypadku MySQL Galera Cluster nowo utworzony klaster ma możliwość skalowania w poziomie poprzez asynchroniczną replikację MySQL. Załóżmy, że przywróciliśmy już nowy klaster w biurze na podstawie najnowszej kopii zapasowej z klastra produkcyjnego w centrum danych i chcielibyśmy, aby klaster biurowy kontynuował replikację z klastra produkcyjnego, jak pokazano na poniższym diagramie:

Następnie możesz skonfigurować łącze replikacji asynchronicznej w następujący sposób:

  1. Wybierz jeden węzeł w produkcji i włącz rejestrowanie binarne (jeśli jest wyłączone). Przejdź do Węzły -> wybierz węzeł -> Akcje węzła -> Włącz rejestrowanie binarne.

  2. Włącz logowanie binarne we wszystkich węzłach klastra biurowego. To działanie wymaga stopniowego ponownego uruchomienia, które zostanie wykonane automatycznie, jeśli wybierzesz „Tak” w menu rozwijanym „Węzeł automatycznego ponownego uruchamiania”:

    W przeciwnym razie możesz wykonać tę operację bez przestoju, używając Zarządzaj -> Uaktualnij -> Ponowne uruchamianie (lub ręcznie uruchamiaj ponownie jeden węzeł na raz).

  3. Utwórz użytkownika replikacji w klastrze produkcyjnym, używając opcji Zarządzaj -> Schematy i użytkownicy -> Użytkownicy -> Utwórz nowego użytkownika:

  4. Następnie wybierz jeden węzeł do replikacji do węzła głównego w klastrze produkcyjnym i skonfiguruj łącze replikacji:

    mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
    mysql> START SLAVE;
  5. Sprawdź, czy replikacja jest uruchomiona:

    mysql> SHOW SLAVE STATUS\G
    Upewnij się, że Slave_IO_Thread i Slave_SQL_thread zgłaszają „Tak”. Klaster w biurze powinien zacząć doganiać węzeł główny, jeśli pozostaje w tyle.

Na razie to wszystko!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jakie jest najlepsze rozwiązanie do puli połączeń bazy danych w Pythonie?

  2. Zwróć n-ty rekord z zapytania MySQL

  3. mysql, iteruj przez nazwy kolumn

  4. tomcat7 — źródło danych jdbc — najprawdopodobniej spowoduje to wyciek pamięci

  5. Django :Tabela nie istnieje