Hur man säkerhetskopierar en krypterad databas med Percona Server för MySQL 8.0

Produktionsavbrott är nästan garanterat att inträffa någon gång. Vi vet det så vi planerar säkerhetskopieringar, skapar reservdatabaser för återställning, konverterar enstaka instanser till kluster.

Vi erkänner behovet av ett korrekt återställningsscenario, vi måste analysera möjliga katastroftidslinje och felscenarier och implementera steg för att få upp din databas. Ett planerat avbrottsutförande kan hjälpa till att förbereda, diagnostisera och återhämta sig från nästa. För att mildra effekterna av driftstopp behöver organisationer en lämplig återhämtningsplan, som skulle inkludera alla faktorer som krävs för att ge tjänsten liv.

Säkerhetskopieringshantering är inte så mild som att bara schemalägga ett säkerhetskopieringsjobb. Det finns många faktorer att ta hänsyn till, såsom lagring, lagring, verifiering och om säkerhetskopieringarna du tar är fysiska eller logiska och vad som är lätt att förbise säkerheten.

Många organisationer varierar sin inställning till säkerhetskopior och försöker ha en kombination av säkerhetskopior av serverbilder (ögonblicksbilder), logiska och fysiska säkerhetskopior lagrade på flera platser. Det är för att undvika lokala eller regionala katastrofer som skulle utplåna våra databaser och säkerhetskopior som lagras i samma datacenter.

Vi vill göra det säkert. Data och säkerhetskopior ska vara krypterade. Men det finns många konsekvenser när båda alternativen är på plats. I den här artikeln kommer vi att ta en titt på säkerhetskopieringsprocedurer när vi hanterar krypterade databaser.

Encryption-at-rest för Percona Server för MySQL 8.0

Från och med MySQL 5.7.11 började communityversionen av MySQL stöd för InnoDB-tabellutrymmeskryptering. Det kallas Transparent Tablespace Encryption eller kallas för Encryption-at-Rest.

Den största skillnaden jämfört med företagsversionen är hur nycklarna lagras - nycklar är inte placerade i ett säkert valv, vilket krävs för efterlevnad av regelverk. Detsamma gäller Percona Server, från och med version 5.7.11 är det möjligt att kryptera InnoDB-tabellutrymme. I Percona Server 8.0 har stödet för kryptering av binära loggar utökats kraftigt. Version 8.0 har lagts till 

(Percona 8.0 versionsdokument):

• Tillfällig filkryptering
• InnoDB Ångra Tablespace Encryption
• InnoDB System Tablespace Encryption (InnoDB System Tablespace Encryption)
• default_table_encryption  =AV/PÅ (General Tablespace Encryption)
• table_encryption_privilege_check =AV/PÅ (Verifiera krypteringsinställningarna)
• InnoDB gör om loggkryptering (endast för huvudnyckelkryptering) (Gör om loggkryptering)
• InnoDB sammanslagningsfilkryptering (Verifiera krypteringsinställningen)
• Percona Parallel dubbelskrivningsbuffertkryptering (InnoDB Tablespace Encryption)

För dem som är intresserade av migrering från MySQL Enterprise-version till Percona -  Det är också möjligt att integrera med Hashicorp Vault-server via en keyring_vault-plugin, som matchar funktionerna som finns tillgängliga i Oracles MySQL Enterprise-utgåva.

Kryptering av data i vila kräver ett nyckelringsplugin. Det finns två alternativ här:

• nyckelring_fil - en platt fil med en krypteringsnyckel
• Plugin för nyckelringvalv  - en tjänst

Hur man aktiverar tabellutrymmeskryptering

För att aktivera kryptering starta din databas med alternativet --early-plugin-load:

antingen för hand:

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

eller genom att ändra konfigurationsfilen:

[mysqld]

early-plugin-load=keyring_file.so

Att starta Percona Server 8.0 kan två typer av tabellutrymmen krypteras. Allmän tabellyta och systemtabellyta. Sys-tabellutrymmet styrs via parametern innodb_sys_tablespace_encrypt. Som standard är sys tabellutrymmet inte krypterat, och om du redan har en är det inte möjligt att konvertera det till krypterat tillstånd, en ny instans måste skapas (starta en instans med alternativet --bootstrap).

Allmänt tabellutrymme stöder kryptering antingen av alla tabeller i tabellutrymmet eller ingen. Det är inte möjligt att köra kryptering i blandat läge. Använd flaggan ENCRYPTION='Y/N' för att skapa ett tabellutrymme med kryptering.

Exempel:

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

Säkerhetskopiera en krypterad databas

När du lägger till krypterade tabellutrymmen är det nödvändigt att inkludera nyckelringsfilen i kommandot xtrabackup. För att göra det måste du ange sökvägen till en nyckelringsfil som värdet för alternativet --keyring-file-data.

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

Se till att förvara nyckelringfilen på en säker plats. Se också till att alltid ha en säkerhetskopia av filen. Xtrabackup kommer inte att kopiera nyckelringsfilen i backupkatalogen. För att förbereda säkerhetskopian måste du själv göra en kopia av nyckelringsfilen.

Förbereder säkerhetskopian

När vi har vår säkerhetskopia bör vi förbereda den för återställning. Här måste du också ange nyckelring-fil-data.

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

Säkerhetskopieringen är nu förberedd och kan återställas med alternativet --copy-back. Om nyckelringen har roterats måste du återställa nyckelringen (som användes för att ta och förbereda säkerhetskopian).

För att förbereda säkerhetskopieringen av xtrabackup behöver vi tillgång till nyckelringen. Xtrabackup pratar inte direkt med MySQL-servern och läser inte standardmy.cnf-konfigurationsfilen under förberedelse, ange nyckelringsinställningar via kommandoraden:

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

Säkerhetskopieringen är nu förberedd och kan återställas med alternativet --copy-back:

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

Utföra inkrementella säkerhetskopieringar

Processen att ta inkrementella säkerhetskopior med InnoDB-tabellutrymmeskryptering liknar att ta samma inkrementella säkerhetskopior med en okrypterad tabellyta.

För att göra en inkrementell säkerhetskopia, börja med en fullständig säkerhetskopia. Xtrabackup-binären skriver en fil som heter xtrabackup_checkpoints till backupens målkatalog. Den här filen innehåller en rad som visar to_lsn, som är databasens LSN i slutet av säkerhetskopieringen.

Först måste du skapa en fullständig säkerhetskopia med följande kommando:

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Nu när du har en fullständig säkerhetskopia kan du göra en inkrementell säkerhetskopia baserad på den. Använd ett kommando som följande:

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

katalogen /data/backups/inc1/ bör nu innehålla deltafiler, såsom ibdata1.delta och test/table1.ibd.delta.

Betydningen bör vara självklar. Det är nu möjligt att använda den här katalogen som bas för ännu en inkrementell säkerhetskopiering:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Förbereda inkrementella säkerhetskopior

Än så länge liknar processen att säkerhetskopiera databasen en vanlig säkerhetskopia, förutom flaggan där vi angav platsen för nyckelringfilen.

Tyvärr är --prepare-steget för inkrementella säkerhetskopieringar inte detsamma som för normala säkerhetskopior.

I normala säkerhetskopieringar utförs två typer av operationer för att göra databasen konsistent:begångna transaktioner spelas upp från loggfilen mot datafilerna, och ej anslutna transaktioner rullas tillbaka. Du måste hoppa över återställningen av oengagerade transaktioner när du förbereder en säkerhetskopia, eftersom transaktioner som var obekräftade vid tidpunkten för din säkerhetskopiering kan pågå, och det är troligt att de kommer att begås i nästa inkrementella säkerhetskopiering. Du bör använda alternativet --apply-log-only för att förhindra återställningsfasen.

Om du inte använder alternativet --apply-log-only för att förhindra återställningsfasen, kommer dina inkrementella säkerhetskopior att vara värdelösa. Efter att transaktioner har återställts kan ytterligare inkrementella säkerhetskopior inte tillämpas.

Från och med den fullständiga säkerhetskopian du skapade kan du förbereda den och sedan tillämpa de inkrementella skillnaderna på den. Kom ihåg att du har följande säkerhetskopior:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

För att förbereda grundsäkerhetskopian måste du köra --prepare som vanligt, men förhindra återställningsfasen:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

För att tillämpa den första inkrementella säkerhetskopian på den fullständiga säkerhetskopian bör du använda följande kommando:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

om nyckelringen har roterats mellan basen och den inkrementella backupen som du behöver använda nyckelringen som användes när den första inkrementella backupen togs.

Att förbereda den andra inkrementella säkerhetskopian är en liknande process

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Obs; --apply-log-only ska användas när du slår samman alla inkremental utom den sista. Det är därför den föregående raden inte innehåller alternativet --apply-log-only. Även om --apply-log-only användes i det sista steget, skulle säkerhetskopieringen fortfarande vara konsekvent men i så fall skulle servern utföra återställningsfasen.
Det sista steget är att återställa den med --copy-back alternativ. Om nyckelringen har roterats måste du återställa nyckelringen som användes för att ta och förbereda säkerhetskopian.

Medan den beskrivna återställningsmetoden fungerar, kräver den åtkomst till samma nyckelring som servern använder. Det kanske inte är möjligt om säkerhetskopieringen förbereds på en annan server eller vid ett mycket senare tillfälle, när nycklar i nyckelringen töms, eller, i fallet med ett fel, när nyckelringsvalvets server inte är tillgänglig alls.

Alternativet --transition-key= bör användas för att göra det möjligt för xtrabackup att bearbeta säkerhetskopian utan tillgång till nyckelringsvalvets server. I det här fallet hämtar xtrabackup AES-krypteringsnyckeln från den angivna lösenfrasen och kommer att använda den för att kryptera tabellutrymmesnycklar för tabellutrymmen som säkerhetskopieras.

Skapa en säkerhetskopia med en lösenordsfras

Följande exempel illustrerar hur säkerhetskopian kan skapas i detta fall:

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

Återställa säkerhetskopian med en genererad nyckel

När du återställer en säkerhetskopia måste du skapa en ny huvudnyckel. Här är exemplet för nyckelring_fil:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

I händelse av keyring_vault kommer det att se ut så här:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf