Popularne kopie zapasowe z Percona XtraBackup w aplikacji WordPress za jednym kliknięciem

• Spis treści
• Wprowadzenie
• Wymagania wstępne
• Krok 1: Utwórz użytkownika systemu innego niż root
• Krok 2: Sprawdź silnik pamięci masowej
• Krok 3: Utwórz użytkownika bazy danych do tworzenia kopii zapasowych
• Krok 4: Zainstaluj Percona XtraBackup
• Krok 5: Utwórz katalogi przechowywania kopii zapasowych
• Krok 6: Utwórz pierwszą pełną kopię zapasową
• Krok 7: Utwórz następujące przyrostowe kopie zapasowe
• Krok 8: Przygotuj pliki kopii zapasowej do przywrócenia bazy danych
• Krok 9: Przywróć bazę danych

Spis treści

• Wprowadzenie
• Wymagania wstępne
• Krok 1: Utwórz użytkownika systemu innego niż root
• Krok 2: Sprawdź silnik pamięci masowej
• Krok 3: Utwórz użytkownika bazy danych do tworzenia kopii zapasowych
• Krok 4: Zainstaluj Percona XtraBackup
• Krok 5: Utwórz katalogi przechowywania kopii zapasowych
• Krok 6: Utwórz pierwszą pełną kopię zapasową
• Krok 7: Utwórz następujące przyrostowe kopie zapasowe
• Krok 8: Przygotuj pliki kopii zapasowej do przywrócenia bazy danych
• Krok 9: Przywróć bazę danych
• Dalsze kroki

Wprowadzenie

Percona XtraBackup to darmowy program oparty na MySQL służący do tworzenia gorących kopii zapasowych. Jest również open source. Za pomocą Percona XtraBackup można tworzyć gorące kopie zapasowe uruchomionych baz danych MySQL, MariaDB lub Percona Server bez zatrzymywania usługi bazy danych lub przekształcania jej w tryb tylko do odczytu. Jest to krytyczna funkcja dla wielu firm internetowych.

W przypadku baz danych wykorzystujących silniki pamięci InnoDB, XtraDB i HailDB Percona XtraBackup może wykonywać nieblokujące kopie zapasowe. W przypadku baz danych korzystających z silników pamięci MyISAM, Merge i Archive Percona XtraBackup może również wykonywać kopie zapasowe, przerywając zapisy na koniec procedury tworzenia kopii zapasowej.

W tym artykule pokażę, jak zainstalować i używać Percona XtraBackup do wykonywania pełnych i przyrostowych kopii zapasowych na gorąco na serwerze Vultr w oparciu o aplikację WordPress za jednym kliknięciem. Wykonamy pełną kopię zapasową i dwie przyrostowe kopie zapasowe, a następnie przywrócimy odpowiednio bazę danych do stanu każdej z trzech kopii.

Wymagania wstępne

Zakładam, że wdrożyłeś od podstaw instancję serwera WordPress Vultr jednym kliknięciem i zalogowałeś się jako root, używając SSH.

Krok 1: Utwórz użytkownika systemu innego niż root

Ze względów bezpieczeństwa zalecaną praktyką jest utworzenie innego konta użytkownika z uprawnieniami administratora, a następnie użycie go do zalogowania się i wykonywania codziennych operacji w systemie. Nadal możesz wykonywać prawie wszystkie polecenia administratora za pomocą sudopolecenia.

1) Utwórz nowego użytkownika. Zastąp sysuserwłasną nazwą użytkownika.

useradd sysuser

2) Ustaw hasło dla nowego użytkownika. Zastąp sysuserwłasną nazwą użytkownika.

passwd sysuser

3) Przyznaj uprawnienia rootowania nowemu użytkownikowi.

visudo

Znajdź akapit poniżej.

## Allow root to run any commands anywhere
root     ALL=(ALL)     ALL

Dodaj wiersz bezpośrednio pod tym akapitem i zastąp sysuserwłasną nazwą użytkownika.

sysuser     ALL=(ALL)     ALL

Zapisz i wyjdź.

:wq

4) Przejdź do nowego konta użytkownika.

logout

Następnie użyj danych logowania nowego użytkownika, aby zalogować się z okna terminala.

Krok 2: Sprawdź silnik pamięci masowej

Domyślnie login root MySQL jest zapisywany na VPS w /root/.my.cnf. Wyświetl hasło w swoim terminalu za pomocą następującego polecenia.

sudo cat /root/.my.cnf

Użyj poświadczenia wyświetlonego na ekranie, aby zalogować się do konsoli MySQL.

mysql -u root -p

W powłoce MySQL uruchom następujące polecenie.

SHOW DATABASES;

Wszystkie bazy danych MySQL zostaną wyświetlone na ekranie. Baza danych o nazwie like wp5273512to baza danych WordPress, którą chcemy wykonać kopię zapasową. W następującym poleceniu zamień wp5273512na własne:

USE wp5273512;

Sprawdź silnik pamięci dla każdej tabeli:

SHOW TABLE STATUS\G

Przekonasz się, że wszystkie tabele w bazie danych WordPress MySQL korzystają z silnika pamięci InnoDB, który idealnie nadaje się do tworzenia gorących kopii zapasowych za pomocą Percona XtraBackup.

W przypadku innych baz danych MySQL korzystających z silnika pamięci MyISAM nadal możemy wykonać ich kopię zapasową za pomocą Percona XtraBackup, krótko przerywając zapis.

Krok 3: Utwórz użytkownika bazy danych do tworzenia kopii zapasowych

Nadal w powłoce MySQL użyj następujących poleceń, aby utworzyć dedykowanego użytkownika bazy danych do tworzenia kopii zapasowych. Pamiętaj, aby zastąpić nazwę użytkownika bazy danych xbuseri hasło xbpasswdwłasnymi:

CREATE USER 'xbuser'@'localhost' IDENTIFIED BY 'xbpasswd';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT, CREATE TABLESPACE, PROCESS, SUPER, CREATE, INSERT, SELECT ON *.* TO 'xbuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Powyższe uprawnienia są niezbędne do pełnej funkcjonalności Percona XtraBackup. Możesz usunąć niektóre z nich, aby uzyskać mniejszą funkcjonalność i większe bezpieczeństwo. Aby uzyskać więcej informacji, zobacz oficjalną stronę Percona XtraBackup .

Krok 4: Zainstaluj Percona XtraBackup

Możesz z łatwością zainstalować Percona XtraBackup z repozytorium RPM Percona:

sudo yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
sudo yum install -y percona-xtrabackup

Krok 5: Utwórz katalogi przechowywania kopii zapasowych

Najpierw musisz dodać użytkownika sysuserdo mysqlgrupy. Zastąp sysuserwłasną nazwą użytkownika.

sudo gpasswd -a sysuser mysql

Utwórz katalog do przechowywania pełnych kopii zapasowych.

sudo mkdir -p /dbbackup/full/

Utwórz inny katalog do przechowywania przyrostowych kopii zapasowych.

sudo mkdir -p /dbbackup/inc/

Zmień właściciela tych katalogów na użytkownika sysuseri grupę sysuser.

sudo chown -R sysuser:sysuser /dbbackup

Wyloguj się, aby wprowadzić zmiany.

logout

Następnie zaloguj się sysuserponownie.

Krok 6: Utwórz pierwszą pełną kopię zapasową

XtraBackup składa się głównie z programu XtraBackup i innobackupexskryptu perl. Zwykle można użyć innobackupexskryptu perl do wykonania różnych procedur operacyjnych dla wygody.

Wpisz następujące polecenie, aby utworzyć pierwszą pełną kopię zapasową. Pamiętaj, aby zastąpić nazwę xbuserużytkownika bazy danych, hasło użytkownika bazy danych xbpasswdi pełny katalog kopii zapasowej /dbbackup/full/własnymi.

sudo innobackupex --user=xbuser  --password=xbpasswd /dbbackup/full/

Po prawidłowym wykonaniu tego polecenia zobaczysz komunikat potwierdzający „innobackupex: zakończono OK!” w ostatnim wierszu wyniku.

Wszystkie nowo utworzone pliki tej pełnej kopii zapasowej zostaną zapisane w katalogu ze znacznikiem czasu pod /dbbackup/full/. Na przykład /dbbackup/full/2015-05-22_05-45-54.

Krok 7: Utwórz następujące przyrostowe kopie zapasowe

Wpisz następujące polecenie, aby utworzyć pierwszą przyrostową kopię zapasową. Odpowiednio zamień zmienne w poleceniu.

sudo innobackupex --user=xbuser  --password=xbpasswd --incremental --incremental-basedir=/dbbackup/full/2015-05-22_05-45-54 /dbbackup/inc/

Znów zobaczysz „innobackupex: zakończono OK!” na końcu danych wyjściowych, gdy polecenie zostanie wykonane pomyślnie. Pliki kopii zapasowych będą przechowywane w katalogu ze znacznikiem czasu pod /dbbackup/inc/.

Wpisz następujące polecenie, aby utworzyć drugą przyrostową kopię zapasową. Zamień odpowiednio zmienne w poleceniu.

sudo innobackupex --user=xbuser  --password=xbpasswd --incremental --incremental-basedir=/dbbackup/inc/2015-05-22_05-48-12 /dbbackup/inc/

Po sukcesie zobaczysz „innobackupex: ukończono OK!” wiadomość ponownie. Sprawdź /dbbackup/inc/folder ponownie, aby zobaczyć pliki kopii zapasowej.

Krok 8: Przygotuj pliki kopii zapasowej do przywrócenia bazy danych

Wszystkie pliki kopii zapasowej bazy danych należy przygotować, zanim będą mogły zostać użyte do przywrócenia bazy danych.

Uwaga : przed wykonaniem procedur przygotowywania i przywracania lepiej przechowywać kopię całego katalogu kopii zapasowych (np. /dbbackup/) W innym miejscu, na wypadek, gdyby uszkodzenie kopii zapasowej plików było spowodowane pomyłką.

W każdym katalogu kopii zapasowej znajduje się plik o nazwie xtrabackup_checkpointszawierającej typ kopii oraz numery początkowe i końcowe dziennika ( from_lsni to_lsn). Możesz użyć tych liczb do wyjaśnienia strategii przywracania bazy danych. Spójrz na poniższe przykłady.

W xtrabackup_checkpointspliku pierwszej pełnej kopii zapasowej mam:

backup_type = full-backuped
from_lsn = 0
to_lsn = 2932478

W xtrabackup_checkpointspliku pierwszej przyrostowej kopii zapasowej mam:

backup_type =incremental
from_lsn = 2932478
to_lsn = 2970177

W xtrabackup_checkpointspliku drugiej przyrostowej kopii zapasowej mam:

backup_type = incremental
from_lsn = 2970177
to_lsn = 3004672

W skrócie, powinieneś poradzić sobie z każdą kopią zapasową w rosnącej kolejności lsn. Jeśli sekwencja lsn jest niekompletna lub nieuporządkowana, możesz stracić dane.

Uwaga : następujące polecenia dotyczą trzech katalogów, zamień je na własne.

Aby przywrócić bazę danych do stanu pierwszej pełnej kopii zapasowej, musisz przygotować pliki kopii zapasowej za pomocą następującego polecenia:

sudo innobackupex --apply-log /dbbackup/full/2015-05-22_05-45-54

Aby przywrócić bazę danych do stanu pierwszej przyrostowej kopii zapasowej, należy przygotować pliki kopii zapasowej za pomocą następujących poleceń:

sudo innobackupex --apply-log --redo-only /dbbackup/full/2015-05-22_05-45-54
sudo innobackupex --apply-log /dbbackup/full/2015-05-22_05-45-54 --incremental-dir=/dbbackup/inc/2015-05-22_05-48-12
sudo innobackupex --apply-log /dbbackup/full/2015-05-22_05-45-54

Aby przywrócić bazę danych do stanu drugiej przyrostowej kopii zapasowej, należy przygotować pliki kopii zapasowej za pomocą następujących poleceń:

sudo innobackupex --apply-log --redo-only /dbbackup/full/2015-05-22_05-45-54
sudo innobackupex --apply-log --redo-only /dbbackup/full/2015-05-22_05-45-54 --incremental-dir=/dbbackup/inc/2015-05-22_05-48-12
sudo innobackupex --apply-log /dbbackup/full/2015-05-22_05-45-54 --incremental-dir=/dbbackup/inc/2015-05-22_05-51-32
sudo innobackupex --apply-log /dbbackup/full/2015-05-22_05-45-54

Uwagi :

W przypadku przyrostowych kopii zapasowych należy użyć tej --redo-onlyopcji na wszystkich oprócz ostatniej przyrostowej kopii zapasowej. Niemniej jednak użycie tej opcji przy ostatniej przyrostowej kopii zapasowej jest nadal nieszkodliwe dla spójności danych - spowoduje tylko pewne opóźnienie z powodu wycofania bazy danych.

Ostatnie polecenie każdego scenariusza przyrostowego jest opcjonalne, ale zalecane, ponieważ przyspieszy przywracanie.

Po przygotowaniu zmiany zapisane w przyrostowych plikach kopii zapasowej zostaną dołączone do przygotowanych podstawowych plików pełnej kopii zapasowej, dlatego zawsze należy używać przygotowanych plików pełnej kopii zapasowej do przywrócenia bazy danych, bez względu na to, czy wybierzesz kopię pełną czy przyrostową kopię zapasową.

Krok 9: Przywróć bazę danych

Przed przywróceniem bazy danych należy zatrzymać usługę bazy danych.

sudo service mysqld stop

Musisz również opróżnić katalog bazy danych. Możesz przenieść bieżące pliki bazy danych w inne miejsce, aby zachować ostrożność.

sudo mkdir /currentdb
sudo mv /var/lib/mysql/* /currentdb

Przywróć bazę danych z przygotowanymi plikami „pełnej kopii zapasowej”.

sudo innobackupex --copy-back /dbbackup/full/2015-05-22_05-45-54

Ponieważ procedura przywracania zmodyfikuje właściciela katalogu bazy danych, musisz go zmienić z powrotem, mysql:mysqlaby działał.

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

Uruchom ponownie usługę bazy danych.

sudo service mysqld start

Otóż ​​to. W tym momencie możesz odwiedzić witrynę WordPress, aby sprawdzić, czy proces przywracania powiódł się.