MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

ClusterControl — Zaawansowane zarządzanie kopiami zapasowymi — mariabackup Część I

ClusterControl może, między innymi, działać jako doskonałe narzędzie pomagające zaprojektować i wykonać harmonogram tworzenia kopii zapasowych. Dostępnych jest wiele funkcji, w tym weryfikacja kopii zapasowej, przejrzyste szyfrowanie kopii zapasowych i wiele innych. To, czego często brakuje, to zdolność ClusterControl do dostrajania narzędzi do tworzenia kopii zapasowych, których używamy do tworzenia kopii zapasowych. W tym blogu chcielibyśmy omówić niektóre ustawienia, które można zastosować do MariaBackup. Zaczynajmy.

Konfiguracja początkowa

Początkowa konfiguracja to klaster MariaDB z jednym głównym i jedną repliką, w tej chwili opóźnione z powodu importu danych działających w tle.

Mamy dwa węzły ProxySQL i dwa węzły Keepalved, zapewniając wirtualny adres IP i upewniając się, że ProxySQL jest osiągalny. Zapełniamy klaster (stąd opóźnienie) danymi generowanymi przez sysbench. Użyliśmy następującego polecenia, aby uruchomić ten proces:

sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.111 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --table-size=1000000 prepare

Spowoduje to wygenerowanie około 7,6 GB danych, na których będziemy testować różne ustawienia tworzenia kopii zapasowych.

Ustawienia kompresji

Jak już wspomnieliśmy, istnieje wiele ustawień, których można użyć do dostosowania MariaBackup i innych narzędzi zaangażowanych w proces tworzenia kopii zapasowej.

W tym poście na blogu chcielibyśmy skupić się na poziomie kompresji i zobaczyć czy ma to jakikolwiek realny wpływ na nasz proces tworzenia kopii zapasowych. Czy zmienia to długość wykonywania kopii zapasowej? Czy zmienia rozmiar kopii zapasowej? Jak? Czy ma sens używanie czegokolwiek innego niż ustawienie domyślne? Przyjrzyjmy się temu wkrótce.

Zamierzamy uruchomić kopie zapasowe przy użyciu wszystkich ustawień z menu rozwijanego Poziom kompresji:

Kopie zapasowe będą przechowywane lokalnie w węźle, aby zminimalizować wpływ przez sieć. Będziemy korzystać z pełnej wersji MariaBackup. Dane w bazie danych nie są w żaden sposób szyfrowane ani kompresowane.

Rozpoczniemy 9 zadań tworzenia kopii zapasowych, każde z innym ustawieniem poziomu kompresji. To ustawienie jest przekazywane do programu gzip, który jest domyślnie używany do kompresji danych. Spodziewamy się wydłużenia czasu wykonywania kopii zapasowej i zmniejszenia rozmiaru kopii zapasowej, gdy zwiększymy to ustawienie.

Jak widać, z wyjątkiem backupu 4, który możemy po prostu liczyć jako przejściowe wahania, czas wykonywania kopii zapasowej wzrasta od 3 minut i 41 sekund do 17 minut i 57 sekund. Rozmiar kopii zapasowej zmniejsza się z 3,5 GB do 3,3 GB. Możemy również sprawdzić dokładny rozmiar kopii zapasowej:

du -s /root/backups/*
3653288 /root/backups/BACKUP-1
3643088 /root/backups/BACKUP-2
3510420 /root/backups/BACKUP-3
3486304 /root/backups/BACKUP-4
3449392 /root/backups/BACKUP-5
3437504 /root/backups/BACKUP-6
3429152 /root/backups/BACKUP-7
3425492 /root/backups/BACKUP-8
3405348 /root/backups/BACKUP-9

Potwierdza to, że w rzeczywistości rozmiar kopii zapasowej zmniejsza się z każdym poziomem kompresji, ale różnice między pierwszym i ostatnim testowanym poziomem są dość niewielkie. Najmniejsza kopia zapasowa ma 93,2% rozmiaru największej. Z drugiej strony jego czas wykonania (1077 sekund) jest prawie 5 razy dłuższy niż czas wykonania największej kopii zapasowej (221 sekund).

Pamiętaj, że Twój przebieg będzie się różnić. Możesz użyć danych, które kompresują się lepiej, co zwiększy wpływ poziomu kompresji. Opierając się na wynikach tego testu, dla zestawu danych sysbench nie ma sensu używać poziomu kompresji wyższego niż 3.

Kompresja Qpress

Kolejną opcją, którą chcielibyśmy dzisiaj przetestować, jest kompresja Qpress. Qpress to metoda kompresji, której można użyć do zastąpienia gzip.

Jak widać, jest zdecydowanie szybszy niż gzip, ale zawiera znaczny wzrost wielkości danych. Po 100 sekundach kompresji otrzymaliśmy 4,6 GB danych.

Wybranie najodpowiedniejszej metody kompresji może wymagać serii testów, ale mamy nadzieję, że widzisz, że zdecydowanie warto to zrobić. W przypadku dużych zestawów danych możliwość wymiany nieco większego archiwum na prawie 5-krotnie szybszy proces tworzenia kopii zapasowych może być całkiem przydatna. Jeśli rozważymy użycie Qpress, możemy zamienić miejsce na dysku nawet na 10 razy szybszy proces backupu. Może to oznaczać różnicę między 20-godzinną kopią zapasową a 2-godzinną kopią zapasową. Oczywiście wzrost przestrzeni dyskowej potrzebnej do przechowywania takich danych będzie widoczny, ale wtedy, gdy się nad tym zastanowisz, uzyskanie większego wolumenu dysku jest wykonalne. Dodawanie dodatkowych godzin do dnia, gdy 24 godziny nie wystarczą, aby wykonać kopię zapasową, nie jest.

Mamy nadzieję, że ten krótki blog był dla Ciebie wnikliwy i zachęci Cię do zabawy z różnymi ustawieniami, których można używać w MariaBackup. Jeśli chcesz podzielić się z nimi swoim doświadczeniem, chętnie zobaczymy Twoje komentarze.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jak GET_FORMAT() działa w MariaDB

  2. Jak monitorować kontenery MySQL za pomocą Prometheusa — wdrożenie w trybie Standalone i Swarm::Część pierwsza

  3. Jak TIMEDIFF() działa w MariaDB

  4. Jak działa KOERCYBILNOŚĆ() w MariaDB

  5. Konwertuj wyniki zapytania na listę rozdzielaną przecinkami w MariaDB