Przerwy w produkcji są prawie gwarantowane w pewnym momencie. Wiemy o tym, dlatego planujemy kopie zapasowe, tworzymy zapasowe bazy danych, konwertujemy pojedyncze instancje w klastry.
Przyznając potrzebę odpowiedniego scenariusza odzyskiwania, musimy przeanalizować możliwy harmonogram awarii i scenariusze awarii oraz wdrożyć kroki w celu przywrócenia bazy danych. Planowane wykonanie przestoju może pomóc w przygotowaniu, zdiagnozowaniu i odzyskaniu sprawności po następnym. Aby złagodzić wpływ przestojów, organizacje potrzebują odpowiedniego planu naprawczego, który obejmowałby wszystkie czynniki wymagane do uruchomienia usługi.
Zarządzanie kopiami zapasowymi nie jest tak łagodne, jak planowanie zadania kopii zapasowej. Należy wziąć pod uwagę wiele czynników, takich jak przechowywanie, przechowywanie, weryfikacja, a także to, czy tworzone kopie zapasowe są fizyczne, czy logiczne, oraz czy łatwo przeoczyć zabezpieczenia.
Wiele organizacji różni się podejściem do kopii zapasowych, próbując mieć kombinację kopii zapasowych obrazu serwera (migawki), kopii logicznych i fizycznych przechowywanych w wielu lokalizacjach. Ma to na celu uniknięcie lokalnych lub regionalnych katastrof, które wyczyściłyby nasze bazy danych i kopie zapasowe przechowywane w tym samym centrum danych.
Chcemy zapewnić bezpieczeństwo. Dane i kopie zapasowe powinny być szyfrowane. Ale istnieje wiele implikacji, gdy obie opcje są na miejscu. W tym artykule przyjrzymy się procedurom tworzenia kopii zapasowych, gdy mamy do czynienia z zaszyfrowanymi bazami danych.
Szyfrowanie w spoczynku dla Percona Server dla MySQL 8.0
Począwszy od MySQL 5.7.11, społeczność MySQL zaczęła obsługiwać szyfrowanie w przestrzeni tabel InnoDB. Nazywa się to przezroczystym szyfrowaniem przestrzeni tabel lub określane jako szyfrowanie w stanie spoczynku.
Główną różnicą w porównaniu z wersją Enterprise jest sposób przechowywania kluczy — klucze nie znajdują się w bezpiecznym skarbcu, co jest wymagane do zapewnienia zgodności z przepisami. To samo dotyczy Percona Server, począwszy od wersji 5.7.11, możliwe jest szyfrowanie przestrzeni tabel InnoDB. W Percona Server 8.0 znacznie rozszerzono obsługę szyfrowania logów binarnych. Dodano wersję 8.0
(Zgodnie z dokumentem wydania Percona 8.0):
- Tymczasowe szyfrowanie plików
- Szyfrowanie przestrzeni tabel InnoDB Undo
- Szyfrowanie przestrzeni tabel systemu InnoDB (szyfrowanie przestrzeni tabel systemu InnoDB)
- default_table_encryption =WYŁ/WŁ (Ogólne szyfrowanie przestrzeni tabel)
- table_encryption_privilege_check =OFF/ON (Weryfikacja ustawień szyfrowania)
- Ponowne szyfrowanie dziennika InnoDB (tylko dla szyfrowania kluczem głównym) (Redo Log Encryption)
- Szyfrowanie plików scalonych InnoDB (weryfikacja ustawień szyfrowania)
- Szyfrowanie bufora podwójnego zapisu Percona Parallel (szyfrowanie przestrzeni tabel InnoDB)
Dla osób zainteresowanych migracją z wersji MySQL Enterprise do Percona – możliwa jest również integracja z serwerem Hashicorp Vault za pomocą wtyczki keyring_vault, pasującej do funkcji dostępnych w wersji Oracle MySQL Enterprise.
Szyfrowanie danych w spoczynku wymaga wtyczki klucza. Są tu dwie opcje:
- keyring_file — plik płaski z kluczem szyfrowania
- Wtyczka Keyring Vault – usługa
Jak włączyć szyfrowanie przestrzeni tabel
Aby włączyć szyfrowanie, uruchom bazę danych z opcją --early-plugin-load:
albo ręcznie:
$ mysqld --early-plugin-load="keyring_file=keyring_file.so"lub modyfikując plik konfiguracyjny:
[mysqld]
early-plugin-load=keyring_file.soUruchamiając Percona Server 8.0 można zaszyfrować dwa rodzaje obszarów tabel. Ogólna przestrzeń tabel i systemowa przestrzeń tabel. Przestrzeń tabel Sys jest kontrolowana za pomocą parametru innodb_sys_tablespace_encrypt. Domyślnie obszar tabel sys nie jest zaszyfrowany, a jeśli już go masz, nie można go przekonwertować do stanu zaszyfrowanego, należy utworzyć nową instancję (uruchom instancję za pomocą opcji --bootstrap).
Ogólny obszar tabel obsługuje szyfrowanie jednej ze wszystkich tabel w obszarze tabel lub żadnej. Nie można uruchomić szyfrowania w trybie mieszanym. W celu stworzenia zjedzonej przestrzeni tabel z szyfrowaniem należy użyć flagi ENCRYPTION='Y/N'.
Przykład:
mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';Tworzenie kopii zapasowej zaszyfrowanej bazy danych
Gdy dodajesz zaszyfrowane obszary tabel, konieczne jest dołączenie pliku kluczy w poleceniu xtrabackup. Aby to zrobić, musisz określić ścieżkę do pliku kluczy jako wartość opcji --keyring-file-data.
$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_fileUpewnij się, że przechowujesz plik kluczy w bezpiecznej lokalizacji. Upewnij się również, że zawsze masz kopię zapasową pliku. Xtrabackup nie skopiuje pliku kluczy do katalogu kopii zapasowej. Aby przygotować kopię zapasową, musisz samodzielnie wykonać kopię pliku kluczy.
Przygotowywanie kopii zapasowej
Gdy mamy już plik kopii zapasowej, powinniśmy przygotować go do odzyskania. Tutaj również musisz określić dane pliku kluczy.
$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_fileKopia zapasowa jest teraz przygotowana i można ją przywrócić za pomocą opcji --copy-back. W przypadku, gdy brelok został obrócony, będziesz musiał przywrócić brelok (który został użyty do pobrania i przygotowania kopii zapasowej).
W celu przygotowania kopii zapasowej xtrabackup potrzebujemy dostępu do pęku kluczy. Xtrabackup nie komunikuje się bezpośrednio z serwerem MySQL i nie odczytuje domyślnego pliku konfiguracyjnego my.cnf podczas przygotowywania, określ ustawienia pęku kluczy za pomocą wiersza poleceń:
$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnfKopia zapasowa jest teraz przygotowana i można ją przywrócić za pomocą opcji --copy-back:
$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/Wykonywanie przyrostowych kopii zapasowych
Proces wykonywania przyrostowych kopii zapasowych z szyfrowaniem obszaru tabel InnoDB jest podobny do robienia tych samych przyrostowych kopii zapasowych z niezaszyfrowanym obszarem tabel.
Aby utworzyć przyrostową kopię zapasową, zacznij od pełnej kopii zapasowej. Plik binarny xtrabackup zapisuje plik o nazwie xtrabackup_checkpoints w katalogu docelowym kopii zapasowej. Ten plik zawiera wiersz pokazujący to_lsn, który jest numerem LSN bazy danych na końcu kopii zapasowej.
Najpierw musisz utworzyć pełną kopię zapasową za pomocą następującego polecenia:
$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyringTeraz, gdy masz pełną kopię zapasową, możesz na jej podstawie utworzyć przyrostową kopię zapasową. Użyj polecenia takiego jak:
$ xtrabackup --backup --target-dir=/data/backups/inc1 \
--incremental-basedir=/data/backups/base \
--keyring-file-data=/var/lib/mysql-keyring/keyringKatalog /data/backups/inc1/ powinien teraz zawierać pliki delta, takie jak ibdata1.delta i test/table1.ibd.delta.
Znaczenie powinno być oczywiste. Teraz można użyć tego katalogu jako podstawy do kolejnej przyrostowej kopii zapasowej:
$ xtrabackup --backup --target-dir=/data/backups/inc2 \
--incremental-basedir=/data/backups/inc1 \
--keyring-file-data=/var/lib/mysql-keyring/keyringPrzygotowywanie przyrostowych kopii zapasowych
Jak dotąd proces tworzenia kopii zapasowej bazy danych jest podobny do zwykłego tworzenia kopii zapasowej, z wyjątkiem flagi, w której określiliśmy lokalizację pliku kluczy.
Niestety, krok --prepare w przypadku przyrostowych kopii zapasowych nie jest taki sam, jak w przypadku normalnych kopii zapasowych.
W normalnych kopiach zapasowych wykonywane są dwa rodzaje operacji w celu zapewnienia spójności bazy danych:zatwierdzone transakcje są odtwarzane z pliku dziennika w odniesieniu do plików danych, a niezatwierdzone transakcje są wycofywane. Podczas przygotowywania kopii zapasowej należy pominąć wycofywanie niezatwierdzonych transakcji, ponieważ transakcje, które były niezatwierdzone w momencie tworzenia kopii zapasowej, mogą być w toku i prawdopodobnie zostaną zatwierdzone w następnej przyrostowej kopii zapasowej. Powinieneś użyć opcji --apply-log-only, aby zapobiec fazie wycofywania.
Jeśli nie użyjesz opcji --apply-log-only, aby zapobiec fazie wycofywania, twoje przyrostowe kopie zapasowe będą bezużyteczne. Po wycofaniu transakcji nie można zastosować dalszych przyrostowych kopii zapasowych.
Począwszy od utworzonej pełnej kopii zapasowej, możesz ją przygotować, a następnie zastosować do niej przyrostowe różnice. Przypomnij sobie, że masz następujące kopie zapasowe:
/data/backups/base
/data/backups/inc1
/data/backups/inc2Aby przygotować podstawową kopię zapasową, musisz uruchomić --prepare jak zwykle, ale zapobiegaj fazie wycofywania:
$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyringAby zastosować pierwszą przyrostową kopię zapasową do pełnej kopii zapasowej, należy użyć następującego polecenia:
$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \
--incremental-dir=/data/backups/inc1 \
--keyring-file-data=/var/lib/mysql-keyring/keyringjeśli plik kluczy został obrócony między podstawową a przyrostową kopią zapasową, będziesz musiał użyć pęku kluczy, który był używany podczas wykonywania pierwszej przyrostowej kopii zapasowej.
Przygotowywanie drugiej przyrostowej kopii zapasowej to podobny proces
$ xtrabackup --prepare --target-dir=/data/backups/base \
--incremental-dir=/data/backups/inc2 \
--keyring-file-data=/var/lib/mysql-keyring/keyringUwaga; --apply-log-only powinno być używane podczas scalania wszystkich przyrostów z wyjątkiem ostatniego. Dlatego poprzedni wiersz nie zawiera opcji --apply-log-only. Nawet jeśli opcja --apply-log-only została użyta w ostatnim kroku, kopia zapasowa nadal będzie spójna, ale w takim przypadku serwer wykona fazę wycofywania.
Ostatnim krokiem jest przywrócenie go za pomocą opcji --copy-back opcja. W przypadku, gdy brelok został obrócony, musisz przywrócić brelok, który został użyty do pobrania i przygotowania kopii zapasowej.
Chociaż opisana metoda przywracania działa, wymaga dostępu do tego samego pliku kluczy, z którego korzysta serwer. Może to nie być możliwe, jeśli kopia zapasowa jest przygotowywana na innym serwerze lub w znacznie późniejszym czasie, gdy klucze w pęku kluczy zostaną wyczyszczone lub, w przypadku awarii, gdy serwer przechowalni kluczy w ogóle nie jest dostępny.
Opcja --transition-key=
Tworzenie kopii zapasowej za pomocą hasła
Poniższy przykład ilustruje, jak w tym przypadku można utworzyć kopię zapasową:
$ xtrabackup --backup --user=root -p --target-dir=/data/backup \
--transition-key=MySecetKeyPrzywracanie kopii zapasowej za pomocą wygenerowanego klucza
Podczas przywracania kopii zapasowej będziesz musiał wygenerować nowy klucz główny. Oto przykład dla keyring_file:
$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
--transition-key=MySecetKey --generate-new-master-key \
--keyring-file-data=/var/lib/mysql-keyring/keyringW przypadku keyring_vault będzie to wyglądać tak:
$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
--transition-key=MySecetKey --generate-new-master-key \
--keyring-vault-config=/etc/vault.cnf
