Kopie zapasowe baz danych — porównanie MariaDB Mariabackup i Percona Xtrabackup

Twój serwer bazy danych przechowuje niektóre z najcenniejszych informacji przedsiębiorstwa. Gwarantowanie niezawodnych kopii zapasowych baz danych, aby zapobiec utracie danych w razie wypadku lub awarii sprzętu, jest kluczowym polem wyboru.

Niezależnie od tego, czy jest to mocno obciążony serwer 24x7, czy środowisko o niskim wolumenie transakcji, będziesz potrzebować tworzenia kopii zapasowych bezproblemową procedurą bez zakłócania wydajności serwera w środowisku produkcyjnym.

W tym blogu omówimy dwa z najczęściej używanych narzędzi do wykonania tego zadania, a mianowicie Percona XtraBackup i Mariabackup. Przyjrzymy się podobieństwom i różnicom między nimi, a także tym, jak z nich korzystać.

Co to jest Percona XtraBackup?

Percona XtraBackup to narzędzie typu open source do wykonywania kopii zapasowych baz danych MariaDB, MySQL i Percona Server. Wykonuje on-line non-blocking (dla obsługiwanych silników), mocno skompresowany i zabezpiecza pełne kopie zapasowe w systemach transakcyjnych, dzięki czemu aplikacje pozostają w pełni dostępne przez cały czas trwania okna tworzenia kopii zapasowych.

Za pomocą tego narzędzia możesz:

• Twórz gorące kopie zapasowe InnoDB, które uzupełniają się szybko i niezawodnie, bez zatrzymywania bazy danych lub obciążania serwera
• Tworzenie przyrostowych kopii zapasowych
• Przenoś tabele między serwerami MySQL on-line
• Łatwe tworzenie nowych podrzędnych replikacji MySQL
• Przesyłaj skompresowane kopie zapasowe MySQL na inny serwer
• Oszczędność miejsca na dysku i przepustowości sieci

Co to jest Mariabackup?

Mariabackup to narzędzie typu open source dostarczane przez MariaDB do wykonywania fizycznych kopii zapasowych online. Jest to rozwidlenie Percona XtraBackup zaprojektowane do pracy z zaszyfrowanymi i skompresowanymi tabelami i jest zalecaną metodą tworzenia kopii zapasowych dla baz danych MariaDB.

W serwerze MariaDB Server 10.1 wprowadzono kompresję MariaDB i szyfrowanie danych w spoczynku, ale istniejące rozwiązania do tworzenia kopii zapasowych nie zapewniały pełnej obsługi tych funkcji. Dlatego MariaDB zdecydowała się rozszerzyć XtraBackup (wersja 2.3.8) i nazwała to rozwiązanie Mariabackup.

Różnice między Percona XtraBackup i Mariabackup

Jak zauważyliśmy wcześniej, Mariabackup jest zalecanym narzędziem do tworzenia kopii zapasowych dla MariaDB, a główną różnicą w stosunku do XtraBackup jest to, że działa z zaszyfrowanymi i skompresowanymi tabelami.

W każdym razie, jeśli z jakiegoś szczególnego powodu chcesz używać XtraBackup w swojej bazie danych MariaDB, należy wziąć pod uwagę kilka kwestii w zależności od posiadanej wersji serwera MariaDB:

• MariaDB 10.1:Dzięki nieskompresowanym i nieszyfrowanym danym MariaDB możesz korzystać z XtraBackup. Jeśli używane jest szyfrowanie lub kompresja, lub gdy innodb_page_size jest ustawione na wartość inną niż 16K, nie będzie działać.
• MariaDB 10.2:Możesz również spróbować użyć XtraBackup, ale pamiętaj, że problemy są prawdopodobnie spowodowane błędem niezgodności formatu dziennika cofania MySQL 5.7, który został naprawiony w MariaDB 10.2.2. Z powodu tego błędu kopie zapasowe przygotowane za pomocą XtraBackup mogą nie odzyskać niektórych transakcji. Tylko jeśli uruchomisz serwer z ustawieniem innodb_undo_logs=1, nie będzie to problemem.
• MariaDB 10.3 i nowsze:ten przypadek jest prostszy. XtraBackup nie jest kompatybilny.

Ponadto podczas korzystania z Mariabackup należy wziąć pod uwagę pewne ograniczenia:

• MyRocks:Począwszy od MariaDB 10.2.16 i MariaDB 10.3.8, Mariabackup będzie tworzyć kopie zapasowe danych MyRocks Storage Engine. Częściowa kopia zapasowa danych MyRocks nie jest obecnie obsługiwana. Przyrostowa kopia zapasowa będzie przechowywać pełną kopię danych MyRocks.
• Funkcjonalność eksportu pliku:Mariabackup przed wersją 10.2.9 nie obsługiwała funkcji --export (tworzy plik eksportu w celu wyeksportowania danych z bazy danych). Możesz obejść to ograniczenie, przygotowując kopię zapasową w zwykły sposób (bez opcji --export), a następnie uruchomić serwer i wykonać FLUSH TABLES FOR EXPORT.
• Pliki dziennika:wersje Mariabackup do 10.2.8 nie tworzą pustych plików dziennika i opierają się na akcji --copy-back wykonywanej przez użytkownika (co usuwa stare pliki dziennika innodb, jeśli takie istnieją). Jeśli użytkownik nie użyje --copy-back lub upewni się, że katalog danych jest pusty przed przywróceniem, kopie zapasowe utworzone w tych wersjach mogą stać się niespójne/uszkodzone (z powodu obecności pozostałych dzienników InnoDB).
• Gcrypt:szyfrowanie oparte na narzędziu do tworzenia kopii zapasowych (gcrypt) nie jest obsługiwane w Mariabackup.
• Opcja Innobackupex:Brak dowiązania symbolicznego do innobackupex (zamiast tego użyj parametru --innobackupex). Narzędzie innobackupex wprowadza poprawki i zapewnia dodatkowe funkcje w stosunku do narzędzia innobackup do tworzenia kopii zapasowych tabel InnoDB i MyISAM.
• Opcja Compact:opcja --compact nie jest obsługiwana.
• Opcja odbudowywania indeksów:opcja --rebuild_indexes nie jest obsługiwana.
• Tar dla plików kopii zapasowych:obsługa --stream=tar została usunięta w Mariabackup 10.1.24 (opcja --streams przesyła pliki kopii zapasowych na standardowe wyjście).

Wreszcie, ale nie mniej ważne, Mariabackup można zainstalować w systemie Windows.

Jak to zrobić — Percona XtraBackup i Mariabackup

Zobaczmy, jak możemy go zainstalować i używać.

Instalacja

Istnieją różne metody instalacji zarówno XtraBackup, jak i Mariabackup. Spróbujmy zainstalować z repozytoriów.

Instalacja XtraBackup

W Debianie/Ubuntu

$ wget https://repo.percona.com/apt/percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo dpkg -i percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo apt-get update
$ sudo apt-get install percona-xtrabackup-24

W RedHat/CentOS

$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm
$ sudo yum install percona-xtrabackup-24

Instalacja Mariabackup

W Debianie / Ubuntu

Mariabackup jest częścią MariaDB Server począwszy od MariaDB 10.1.23.

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu bionic main'
$ sudo apt-get update
$ sudo apt-get install mariadb-server-10.1

W CentOS/RedHat

$ sudo vi /etc/yum.repos.d/MariaDB.repo
[mariadb]
name=MariaDB
baseurl=http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
$ sudo yum install MariaDB-backup

Konfiguracja

Zarówno Xtrabackup, jak i Mariabackup odczytują sekcje [mysqld] i [xtrabackup] dowolnego pliku konfiguracyjnego MySQL, w tej kolejności. W ten sposób może odczytywać parametry MySQL, takie jak parametry datadir lub InnoDB.

Możemy modyfikować parametry zawarte w sekcji [mysqld], modyfikując ich wartość w [xtrabackup], jak wspomnieliśmy wcześniej, są one odczytywane w kolejności, więc ostatnia rzecz, jaką mamy w [xtrabackup], będzie miała priorytet.

[mysqld]
datadir=/data/datadir
[xtrabackup]
target_dir=/backups/

Użytkownik z minimalnymi uprawnieniami wymaganymi do pełnych kopii zapasowych to RELOAD, LOCK TABLES, PROCESS i REPLICATION CLIENT:

mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'Password';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';

Następnie możesz dodać tego użytkownika w plikach konfiguracyjnych MySQL:

[xtrabackup]
user=backupuser
password=Password

Możesz również użyć Xtrabackup lub Mariabackup do wykonywania transferów stanu, gdy używasz klastra Percona XtraDB lub MariaDB Galera. Musisz ustawić zmienne wsrep_sst_method i wsrep_sst_auth w plikach konfiguracyjnych:

[mysqld]
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=backupuser:Password

Lub

[mysqld]
wsrep_sst_method=mariabackup
wsrep_sst_auth=backupuser:Password

Użycie

Ponieważ Mariabackup jest oparta na XtraBackup, może być używana w podobny sposób.

Zobaczmy teraz przykład wykorzystania obu metod do tworzenia, przygotowywania i przywracania pełnej kopii zapasowej.

Tworzenie kopii zapasowej

Aby utworzyć nową kopię zapasową za pomocą XtraBackup lub Mariabackup, musisz dodać opcje --backup i --target-dir do wiersza poleceń:

$ xtrabackup --backup --target-dir=/backups/

Lub

$ mariabackup --backup --target-dir=/backups/

Katalog docelowy, w którym będzie przechowywana kopia zapasowa, można określić w plikach konfiguracyjnych MySQL. Proces tworzenia kopii zapasowej nie zastąpi istniejących plików. Jeśli plik istnieje, tworzenie kopii zapasowej nie powiedzie się.

Transaction log of lsn (9755450) to (9755467) was copied.
181122 23:02:44 completed OK!

Jeśli wszystko poszło dobrze, ostatnia linia, którą widzisz, powinna brzmieć „zakończono OK!”. Możesz anulować tworzenie kopii zapasowej w dowolnym momencie, ponieważ nie modyfikuje ona zawartości bazy danych.

[[email protected] ~]# ls -l /backups/
total 102448
-rw-r----- 1 root root       488 Nov 22 23:02 backup-my.cnf
-rw-r----- 1 root root       482 Nov 22 23:02 ib_buffer_pool
-rw-r----- 1 root root 104857600 Nov 22 23:02 ibdata1
drwxr-x--- 2 root root      4096 Nov 22 23:02 mysql
drwxr-x--- 2 root root      4096 Nov 22 23:02 performance_schema
drwxr-x--- 2 root root      4096 Nov 22 23:02 sakila
drwxr-x--- 2 root root     12288 Nov 22 23:02 sys
-rw-r----- 1 root root        64 Nov 22 23:02 xtrabackup_binlog_info
-rw-r----- 1 root root       113 Nov 22 23:02 xtrabackup_checkpoints
-rw-r----- 1 root root       533 Nov 22 23:02 xtrabackup_info
-rw-r----- 1 root root      2560 Nov 22 23:02 xtrabackup_logfile

Powinna to być zawartość kopii zapasowej. Może się to zmienić w zależności od twoich baz danych.

Przygotowywanie kopii zapasowej

Po utworzeniu kopii zapasowej za pomocą XtraBackup lub Mariabackup należy przygotować ją do przywrócenia. Pliki danych nie są spójne, dopóki nie zostaną przygotowane, ponieważ zostały skopiowane w różnym czasie podczas tworzenia kopii zapasowej. Jeśli spróbujesz go przywrócić i uruchomić bazę danych, wykryje ona uszkodzenie i sama się zawiesi, aby zapobiec uruchomieniu na niespójnych danych.

Aby przygotować kopię zapasową, musisz uruchomić polecenie xtrabackup lub mariabackup z opcją --prepare i określić katalog docelowy, w którym przechowywana jest kopia zapasowa.

$ xtrabackup --prepare --target-dir=/backups/

Lub

$ mariabackup --prepare --target-dir=/backups/
InnoDB: Shutdown completed; log sequence number 9757224
181122 23:05:29 completed OK!

Ostatni wiersz, który zobaczysz, powinien mieć postać „Zakończono zamykanie; numer sekwencyjny dziennika xxxxxxx” i „zakończono OK!” jeśli wszystko pójdzie dobrze. Nie zaleca się anulowania procesu przygotowania, ponieważ może to spowodować uszkodzenie pliku danych, a kopia zapasowa stanie się bezużyteczna.

Jeśli chcesz użyć tej kopii zapasowej z kopią przyrostową później, powinieneś użyć opcji --apply-log-only podczas jej przygotowywania, w przeciwnym razie nie będziesz mógł tego zrobić.

Przywracanie kopii zapasowej

Po przygotowaniu kopii zapasowej możesz użyć opcji przywracania z parametrami --copy-back lub --move-back, aby skopiować lub przenieść kopię zapasową do katalogu datadir. Jeśli nie masz wystarczającej ilości miejsca na dysku, prawdopodobnie powinieneś użyć opcji przenoszenia. Ponadto musimy określić katalog docelowy, w którym przechowywana jest kopia zapasowa. Pamiętaj, że katalog danych musi być pusty, a usługa bazy danych powinna być wyłączona przed przywróceniem kopii zapasowej.

$ xtrabackup --copy-back --target-dir=/backups/

Lub

$ mariabackup --copy-back --target-dir=/backups/

Najpierw skopiuje/przeniesie tabele i indeksy MyISAM, następnie tabele i indeksy InnoDB, a na końcu pliki dziennika. Zachowa atrybuty pliku podczas ich kopiowania, może być konieczna zmiana własności plików na mysql przed uruchomieniem serwera bazy danych, ponieważ będą one własnością użytkownika, który utworzył kopię zapasową.

$ sudo chown -R mysql:mysql /var/lib/mysql

Istnieje kilka parametrów, których można używać z Xtrabackup i Mariabackup. Możesz sprawdzić te parametry tutaj dla XtraBackup i tutaj dla Mariabackup.

Zarządzanie kopiami zapasowymi w ClusterControl

Jak widzieliśmy powyżej, tworzenie kopii zapasowej nie jest nauką rakietową. Można to również zaplanować za pomocą crona (ale uważaj na ciche awarie!). Jednak skrypt do regularnego tworzenia kopii zapasowych nie jest rozwiązaniem do zarządzania kopiami zapasowymi. Potrzebujesz sposobu na zgłaszanie kopii zapasowych i ostrzeganie o awariach. Teraz konfiguracja kopii zapasowych w swoim środowisku i sprawdzanie, czy kopie zapasowe działają bez błędów, nie oznacza, że ​​wszystko jest w porządku. Być może słyszałeś o kopii zapasowej Schrödingera, która mówi, że stan kopii zapasowej jest nieznany do momentu próby przywrócenia. Ponieważ najgorszą rzeczą, jaka może się wydarzyć, jest katastrofa i zdajesz sobie sprawę, że kopie zapasowe są z jakiegoś powodu błędne. Próbujesz przywrócić pliki, które zostały zarchiwizowane, ale nie przywraca to, co myślisz, że masz kopię zapasową, lub w ogóle nie przywraca! Następnie są takie rzeczy, jak przenoszenie plików kopii zapasowych poza witrynę, np. do zewnętrznej pamięci masowej w chmurze, do odzyskiwania po awarii. Szyfrowanie i obsługa kluczy są ważne dla bezpieczeństwa. Należy również zarządzać przechowywaniem lokalnych, a także zewnętrznych/archiwizowanych kopii zapasowych.

Zobaczmy, jak ClusterControl może pomóc.

Jeśli chcesz użyć funkcji ClusterControl Backup, przejdź do ClusterControl -> Wybierz Cluster -> Backup, a tam możesz zobaczyć swoje bieżące kopie zapasowe, utworzyć lub zaplanować nową.

Korzystając z opcji utwórz lub zaplanuj, możemy wybrać zarówno metodę XtraBackup, jak i Mariabackup. W tej samej sekcji możemy wybrać serwer, z którego ma zostać wykonana kopia zapasowa, włączyć częściową kopię zapasową, wybrać, gdzie chcesz przechowywać kopię zapasową i czy chcesz przesłać kopię zapasową do chmury (AWS, Azure lub Google Cloud).

Następnie możemy wybrać parametry kopii zapasowej, takie jak kompresja, szyfrowanie i przechowywanie.

Powinny to być polecenia, które ClusterControl uruchomi dla Ciebie:

[16:37:58]: 192.168.100.120: Launching ( LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/my.cnf --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - > /root/backups/BACKUP-13/backup-full-2018-11-14_193757.xbstream.gz ) 2>&1.

Lub

[16:29:57]: 192.168.100.131: Launching ( LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - > /root/backups/BACKUP-11/backup-full-2018-11-14_192957.xbstream.gz ) 2>&1.

To polecenie może się różnić w zależności od wybranych parametrów.

Jak widzieliśmy, ClusterControl jest dobrym przyjacielem, jeśli chcemy korzystać z XtraBackup lub Mariabackup. Możemy w łatwy sposób uruchamiać złożone polecenia tworzenia kopii zapasowych, wybierając opcje w interfejsie użytkownika ClusterControl.
ClusterControl obsługuje zarówno pełną, jak i przyrostową kopię zapasową, dzięki czemu możemy skonfigurować całą naszą strategię tworzenia kopii zapasowych z przyjaznego interfejsu użytkownika.

Wniosek

Podczas tworzenia kopii zapasowej serwera MariaDB zaleca się użycie narzędzia Mariabackup. Jeśli jednak z jakiegoś powodu wolisz korzystać z XtraBackup, nadal możesz. Musisz jednak pamiętać o obowiązujących ograniczeniach, jak zauważyliśmy na tym blogu. Na koniec omówiliśmy, że skrypt do tworzenia kopii zapasowych bazy danych nie jest tym samym, co rozwiązanie do zarządzania kopiami zapasowymi, i szybko przyjrzeliśmy się ClusterControl.

Daj nam znać, jeśli przeoczyliśmy jakiekolwiek różnice między XtraBackup i MariaBackup.

Nieblokujące kopie zapasowe są obsługiwane przez silniki pamięci masowej InnoDB, XtraDB i HailDB. Kopie zapasowe następujących silników pamięci masowej można utworzyć, na krótko wstrzymując zapisy pod koniec tworzenia kopii zapasowej:MyISAM, Merge i Archive, w tym tabele partycjonowane, wyzwalacze i opcje bazy danych.