Jak dostosować kopie zapasowe MySQL i MariaDB za pomocą ClusterControl

Funkcja scentralizowanego zarządzania kopiami zapasowymi ClusterControl obsługuje standardowe mysqldump, kopie zapasowe Percona Xtrabackup i Mariabackup dostarczane przez MariaDB. Uważamy, że wybrane argumenty wiersza poleceń dla odpowiednich metod są optymalne dla większości obciążeń baz danych i są zgodne z najlepszymi praktykami tworzenia kopii zapasowych MySQL. Opieramy się na wszystkich informacjach zwrotnych, które otrzymaliśmy przez lata, pracując z administratorami baz danych i administratorami. Jednak w niektórych okolicznościach konfiguracja może nie wystarczyć. Nadal możesz chcieć dostosować go do swojego środowiska, korzystając z odpowiedniej metody tworzenia kopii zapasowej. W tym poście pokażemy, jak to zrobić.

mysqldump

Aby wykonać kopię zapasową z interfejsu użytkownika ClusterControl, przejdź do sekcji ClusterControl -> Wybierz Cluster -> Kopia zapasowa. Tutaj możesz zobaczyć wygenerowane kopie zapasowe i możesz utworzyć lub zaplanować nową.

W interfejsie użytkownika ClusterControl mamy kilka różnych opcji wykonania kopii zapasowej. Możemy stworzyć jeden plik zrzutu dla każdej bazy danych, włączyć częściową kopię zapasową, przechowywać kopię zapasową na węźle lub na serwerze ClusterControl; możemy określić katalog i podkatalog kopii zapasowej lub możemy automatycznie zarchiwizować kopię zapasową w chmurze (AWS, Google Cloud lub Azure) za pomocą funkcji przesyłania do chmury.

Ponadto możemy użyć kompresji, zaszyfrować naszą kopię zapasową i określić okres przechowywania.

Domyślnie ClusterControl pozwala nam wybrać pomiędzy 4 różnymi typami zrzutów w celu wykonania kopii zapasowej:

• Schemat i dane:schemat i dane bazy danych
• Tylko schemat:schemat bazy danych
• Tylko dane:dane bazy danych
• Tylko MySQL Db:baza danych systemu MySQL

Załóżmy, że mamy 5 baz danych i zdecydowaliśmy się wykonać kopię zapasową wszystkich z nich. Oto, co ClusterControl wykona podczas wykonywania kopii zapasowej przy użyciu metody mysqldump (polecenia są obcinane odwrotnym ukośnikiem w celu zapewnienia czytelności):

• Schemat i dane

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --single-transaction \
  --skip-lock-tables \
  --triggers \
  --routines \
  --events \
  --set-gtid-purged=OFF \
  --databases mysql proxydemo sakila sbtest mydb \
  --ignore-table='mysql.innodb_index_stats' \
  --ignore-table='mysql.innodb_table_stats' \
  |gzip -6 -c > /root/backups/BACKUP-1/mysqldump_2018-11-06_203010_schemaanddata.sql.gz'.

• Tylko schemat

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --no-data \
  --add-drop-table \
  --triggers \
  --routines \
  --events \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --set-gtid-purged=OFF \
  --databases mysql proxydemo sakila sbtest mydb \
  |gzip -6 -c > /root/backups/BACKUP-2/mysqldump_2018-11-06_210040_schemaonly.sql.gz'.

• Tylko dane

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --no-create-info \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --skip-triggers \
  --skip-add-locks \
  --set-gtid-purged=OFF \
  --databases mysql proxydemo sakila sbtest mydb \
  --ignore-table='mysql.innodb_index_stats' \
  --ignore-table='mysql.innodb_table_stats' \
  |gzip -6 -c > /root/backups/BACKUP-3/mysqldump_2018-11-06_210445_dataonly.sql.gz'.

• Tylko baza danych MySQL

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --skip-add-locks \
  --set-gtid-purged=OFF mysql \
  |gzip -6 -c > /root/backups/BACKUP-5/mysqldump_2018-11-06_211135_mysqldbonly.sql.gz'.

Jeśli nasz węzeł MySQL generuje logi binarne, będziemy mieli parametr master-data=2 zawarty w powyższych poleceniach i 1 dodatkowy typ zrzutu:

• Pełny

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --master-data=1 \
  --single-transaction \
  --skip-lock-tables \
  --skip-lock-tables \
  --triggers \
  --routines \
  --events \
  --all-databases \
  |gzip -6 -c > /root/backups/BACKUP-6/mysqldump_2018-11-06_211451_complete.sql.gz'.

Z powyższych wierszy poleceń widać, że w każdym poleceniu mysqldump ClusterControl dołącza plik konfiguracyjny MySQL do swojego argumentu --defaults-file. Dzięki temu proces mysqldump może odczytać zawartość dyrektywy mysqldump. Domyślnie ClusterControl konfiguruje poświadczenia użytkownika kopii zapasowej w osobnym pliku w /etc/my.cnf.d/secrets-backup.cnf i max_allowed_packet w my.cnf, podobnie jak poniżej:

$ my.cnf

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8

$ secrets-backup.cnf

[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniE

Zaletą tego jest to, że możemy dołączyć kilka dodatkowych opcji dla mysqldump. Niestety argument --defaults-file można określić tylko jako pierwszy argument. Zwróć uwagę, że ostatnie argumenty wiersza poleceń mają pierwszeństwo przed tym, co zostało skonfigurowane w my.cnf zgodnie z dyrektywą [mysqldump] na podstawie kolejności, w jakiej się pojawiają. Na przykład, jeśli dodamy skip-comments=0 w my.cnf, podczas gdy na końcu polecenia mysqldump znajduje się --skip-comments (lub --skip-comments=1), to pierwsze zostanie zignorowane i zostanie użyty ten ostatni.

Niemniej jednak nadal możemy go używać jako części dostosowywania kopii zapasowych, korzystając z innych opcji tworzenia kopii zapasowych mysqldump. Na przykład możemy wykluczyć tabele, których nie chcemy archiwizować, używając parametru ignore-table (z formatowaniem „database.table”). Dodaj następujące wiersze do pliku konfiguracyjnego MySQL:

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1

Po skonfigurowaniu możemy po prostu wyzwolić nowe zadanie mysqldump z ClusterControl, a mysqldump pominie te tabele. Nie jest wymagane ponowne uruchomienie MySQL.

Więcej informacji znajdziesz w dokumentacji mysqldump.

Percona Xtrabackup

ClusterControl wykonuje Xtrabackup w zależności od wybranych opcji. Może być pełny lub przyrostowy i można wybrać kilka zmiennych z interfejsu użytkownika ClusterControl. Rozważ następujące kwestie:

W tym kroku możesz wybrać kilka zmiennych, o których wspomnieliśmy wcześniej w sekcji mysqldump, a następnie:

Możemy określić niektóre szczegóły, takie jak węzeł desynchronizacji podczas tworzenia kopii zapasowej, wątki kopiowania równoległego Xtrabackup i inne.

W oparciu o powyższe opcje, kompletne polecenie Xtrabackup będzie wyglądało następująco:

$ ulimit -n 256000 && LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf  --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - | socat - TCP4:192.168.100.110:9999 ) 2>&1.

Pierwsze polecenie „ulimit -n 256000” ma na celu zapewnienie, że Percona Xtrabackup ma wystarczające uprawnienia dostępu do ogromnej liczby deskryptorów plików (w przypadku, gdy bazy danych zawierają wiele tabel). Zwróć uwagę na --defaults-file=/etc/mysql/my.cnf, który jest podobny do mysqldump, gdzie innobackupex odczytuje zawartość konfiguracji MySQL na podstawie następujących dyrektyw i zmiennych:

[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]

Jeśli chcesz dostosować opcje tworzenia kopii zapasowych dla Percona Xtrabackup, możesz dodać je bezpośrednio w dyrektywie [xtrabackup]. Na przykład, powiedzmy, że chcemy, aby Xtrabackup wyświetlał pozycję dziennika binarnego po wykonaniu kopii zapasowej, możemy dodać coś takiego:

[xtrabackup]
user=backupuser
password=[random password]
slave-info=1

Wyzwolenie zadania xtrabackup będzie wtedy zawierało plik o nazwie xtrabackup_slave_info file. Nie jest wymagane ponowne uruchomienie MySQL.

Możesz sprawdzić dokumentację Percony, aby uzyskać więcej informacji o tym, jak to działa.

Mariabackup

Mariabackup to rozwidlenie Percona XtraBackup z dodatkową obsługą kompresji MariaDB 10.1 i szyfrowania danych w spoczynku. Jest dołączony do MariaDB 10.1.23 i nowszych.

Metoda tworzenia kopii zapasowej może być pełna lub przyrostowa i możesz wybrać te same zmienne, które masz dla Percona XtraBackup, takie jak kompresja, wątki kopiowania równoległego Xtrabackup lub szyfrowanie.

Polecenie Mariabackup to:

$ /usr/bin/mariabackup \
--defaults-file=/etc/my.cnf \
--backup \
--galera-info \
--parallel 1 \
--stream=xbstream \
--no-timestamp \
| gzip -6 - > /root/backups/BACKUP-8/backup-full-2018-11-07_015807.xbstream.gz ) 2>&1.

Mariabackup opiera się na Percona XtraBackup, więc wykorzystuje te same informacje, co Percona do tworzenia kopii zapasowej. Domyślnie ClusterControl dodaje następujące wiersze do pliku my.cnf:

[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0

Oraz poświadczenia w pliku secrets-backup.cnf:

[xtrabackup]
user=backupuser
password=[random password]

Jeśli chcesz dodać jakąś zmienną, możesz dodać ją do sekcji [xtrabackup].

Więcej informacji o tym, który parametr należy dodać, można znaleźć w dokumentacji MariaDB.

W każdym przypadku możesz sprawdzić swoje kopie zapasowe w sekcji Kopia zapasowa w interfejsie ClusterControl:

Mamy nadzieję, że pomoże to lepiej skonfigurować kopie zapasowe MySQL — możesz pobrać ClusterControl z naszej strony internetowej (jest bezpłatny).