Sådan sikkerhedskopieres en krypteret database med Percona Server til MySQL 8.0

Produktionsafbrydelser er næsten garanteret at ske på et tidspunkt. Vi ved det, så vi planlægger sikkerhedskopier, opretter standby-databaser til gendannelse, konverterer enkelte forekomster til klynger.

Vi indrømmer behovet for et korrekt gendannelsesscenarie, og vi må analysere den mulige katastrofetidslinje og fejlscenarier og implementere trin til at bringe din database op. Planlagt afbrydelsesudførelse kan hjælpe med at forberede, diagnosticere og komme sig efter den næste. For at afbøde virkningen af nedetid har organisationer brug for en passende genopretningsplan, som omfatter alle de faktorer, der er nødvendige for at bringe service ud i livet.

Backup Management er ikke så mildt som blot at planlægge et backupjob. Der er mange faktorer at overveje, såsom opbevaring, opbevaring, verifikation, og om de sikkerhedskopier du tager er fysiske eller logiske, og hvad der er let at overse sikkerheden.

Mange organisationer varierer deres tilgang til sikkerhedskopier, idet de forsøger at have en kombination af sikkerhedskopier af serverbilleder (snapshots), logiske og fysiske sikkerhedskopier gemt flere steder. Det er for at undgå lokale eller regionale katastrofer, der ville udslette vores databaser og sikkerhedskopier, der er gemt i det samme datacenter.

Vi vil gerne gøre det sikkert. Data og sikkerhedskopier skal være krypteret. Men der er mange konsekvenser, når begge muligheder er på plads. I denne artikel vil vi tage et kig på sikkerhedskopieringsprocedurer, når vi beskæftiger os med krypterede databaser.

Encryption-at-Rest for Percona Server til MySQL 8.0

Startende fra MySQL 5.7.11 begyndte fællesskabsversionen af MySQL at understøtte InnoDB tablespace-kryptering. Det kaldes Transparent Tablespace Encryption eller omtales som Encryption-at-Rest.

Den største forskel i forhold til virksomhedsversionen er måden nøglerne opbevares på - nøgler er ikke placeret i en sikker boks, hvilket er påkrævet for at overholde lovgivningen. Det samme gælder for Percona Server, fra version 5.7.11 er det muligt at kryptere InnoDB tablespace. I Percona Server 8.0 er understøttelsen af kryptering af binære logfiler blevet kraftigt udvidet. Version 8.0 tilføjet

(Percona 8.0 release doc):

Midlertidig filkryptering
InnoDB Fortryd Tablespace Encryption
InnoDB System Tablespace Encryption (InnoDB System Tablespace Encryption)
default_table_encryption =OFF/ON (Generel Tablespace Encryption)
table_encryption_privilege_check =OFF/ON (Bekræftelse af krypteringsindstillingerne)
InnoDB redo log-kryptering (kun for hovednøglekryptering) (Redo Log Encryption)
InnoDB fletningsfilkryptering (bekræftelse af krypteringsindstillingen)
Percona Parallel doublewrite buffer kryptering (InnoDB Tablespace Encryption)

For dem, der er interesseret i migrering fra MySQL Enterprise-version til Percona - Det er også muligt at integrere med Hashicorp Vault-server via et keyring_vault-plugin, der matcher funktionerne i Oracles MySQL Enterprise-udgave.

Data at rest-kryptering kræver et nøglering-plugin. Der er to muligheder her:

keyring_file - en flad fil med en krypteringsnøgle
Plugin til nøglering Vault - en tjeneste

Sådan aktiverer du Tablespace Encryption

For at aktivere kryptering skal du starte din database med --early-plugin-load muligheden:

enten i hånden:

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

eller ved at ændre konfigurationsfilen:

[mysqld]

early-plugin-load=keyring_file.so

Start af Percona Server 8.0 kan to typer tablespaces krypteres. Generel tablespace og system tablespace. Sys tablespace styres via parameteren innodb_sys_tablespace_encrypt. Som standard er sys tablespacet ikke krypteret, og hvis du allerede har et, er det ikke muligt at konvertere det til krypteret tilstand, en ny instans skal oprettes (start en instans med --bootstrap-indstillingen).

Generelt tablespace understøtter kryptering enten af alle tabeller i tablespace eller ingen. Det er ikke muligt at køre kryptering i blandet tilstand. Brug flaget ENCRYPTION='Y/N' for at skabe et tablespace med kryptering.

Eksempel:

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

Sikkerhedskopiering af en krypteret database

Når du tilføjer krypterede tablespaces, er det nødvendigt at inkludere nøglering-fil i xtrabackup-kommandoen. For at gøre det skal du angive stien til en nøglering-fil som værdien af --keyring-file-data-indstillingen.

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

Sørg for at opbevare nøgleringfilen på et sikkert sted. Sørg også for altid at have en sikkerhedskopi af filen. Xtrabackup vil ikke kopiere nøglering-filen i backup-mappen. For at forberede sikkerhedskopien skal du selv lave en kopi af nøgleringsfilen.

Forberedelse af sikkerhedskopien

Når vi har vores sikkerhedskopifil, bør vi forberede den til gendannelsen. Her skal du også angive nøglering-fil-data.

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

Sikkerhedskopien er nu forberedt og kan gendannes med --copy-back-indstillingen. I tilfælde af at nøgleringen er blevet drejet, skal du gendanne nøgleringen (som blev brugt til at tage og forberede sikkerhedskopien).

For at forberede backup xtrabackup, skal vi have adgang til nøgleringen. Xtrabackup taler ikke direkte til MySQL-serveren og læser ikke standard my.cnf-konfigurationsfilen under forberedelse, angiv nøgleringsindstillinger via kommandolinjen:

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

Sikkerhedskopien er nu forberedt og kan gendannes med --copy-back-indstillingen:

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

Udførelse af trinvise sikkerhedskopier

Processen med at tage trinvise sikkerhedskopier med InnoDB tablespace-kryptering svarer til at tage de samme trinvise backups med et ukrypteret tablespace.

For at lave en trinvis sikkerhedskopiering skal du begynde med en fuld sikkerhedskopi. Xtrabackup binæren skriver en fil kaldet xtrabackup_checkpoints ind i backup'ens målmappe. Denne fil indeholder en linje, der viser to_lsn, som er databasens LSN i slutningen af sikkerhedskopien.

Først skal du oprette en fuld sikkerhedskopi med følgende kommando:

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

Nu hvor du har en fuld backup, kan du lave en trinvis backup baseret på den. Brug en kommando som f.eks. følgende:

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

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

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

Mappen /data/backups/inc1/ skulle nu indeholde deltafiler, såsom ibdata1.delta og test/table1.ibd.delta.

Betydningen burde være indlysende. Det er nu muligt at bruge denne mappe som base for endnu en inkrementel backup:

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

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

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

Forberedelse af trinvise sikkerhedskopier

Indtil videre ligner processen med at sikkerhedskopiere databasen en almindelig sikkerhedskopi, bortset fra flaget, hvor vi specificerede placeringen af nøgleringfilen.

Desværre er --prepare-trinnet for inkrementelle sikkerhedskopier ikke det samme som for normale sikkerhedskopier.

I normale sikkerhedskopier udføres to typer operationer for at gøre databasen konsistent:forpligtede transaktioner afspilles fra logfilen mod datafilerne, og ikke-forpligtede transaktioner rulles tilbage. Du skal springe tilbagerulningen af ikke-forpligtede transaktioner over, når du forbereder en sikkerhedskopi, fordi transaktioner, der var ikke-forpligtede på tidspunktet for din backup, kan være i gang, og det er sandsynligt, at de vil blive begået i den næste trinvise backup. Du bør bruge --apply-log-only muligheden for at forhindre tilbagerulningsfasen.

Hvis du ikke bruger --apply-log-only muligheden for at forhindre tilbagerulningsfasen, så vil dine trinvise sikkerhedskopier være ubrugelige. Efter at transaktioner er blevet rullet tilbage, kan yderligere trinvise sikkerhedskopier ikke anvendes.

Begyndende med den fulde sikkerhedskopi, du oprettede, kan du forberede den og derefter anvende de trinvise forskelle på den. Husk, at du har følgende sikkerhedskopier:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

For at forberede basissikkerhedskopieringen skal du køre --forbered som normalt, men forhindre tilbagerulningsfasen:

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

For at anvende den første trinvise sikkerhedskopiering til den fulde backup, skal du bruge følgende kommando:

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

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

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

hvis nøgleringen er blevet roteret mellem basis- og inkrementel backup, skal du bruge den nøglering, der var i brug, da den første trinvise backup blev taget.

Forberedelse af den anden trinvise backup er en lignende proces

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

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

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

Bemærk; --apply-log-only skal bruges, når alle inkrementaller flettes, undtagen den sidste. Det er derfor, den forrige linje ikke indeholder muligheden --apply-log-only. Selvom --apply-log-only blev brugt på det sidste trin, ville backup stadig være konsistent, men i så fald ville serveren udføre rollback-fasen.
Det sidste trin er at gendanne den med --copy-back mulighed. Hvis nøgleringen er blevet roteret, skal du gendanne nøgleringen, som blev brugt til at tage og forberede sikkerhedskopien.

Mens den beskrevne gendannelsesmetode virker, kræver den adgang til den samme nøglering, som serveren bruger. Det er muligvis ikke muligt, hvis sikkerhedskopien er forberedt på en anden server eller på et meget senere tidspunkt, når nøgler i nøgleringen renses, eller, i tilfælde af en funktionsfejl, når nøgleringsboksserveren slet ikke er tilgængelig.

Muligheden --transition-key= skal bruges for at gøre det muligt for xtrabackup at behandle sikkerhedskopien uden adgang til nøgleringsboksserveren. I dette tilfælde udleder xtrabackup AES-krypteringsnøglen fra den angivne adgangssætning og vil bruge den til at kryptere tablespace-nøgler for tablespaces, der sikkerhedskopieres.

Oprettelse af en sikkerhedskopi med en adgangssætning

Følgende eksempel illustrerer, hvordan sikkerhedskopien kan oprettes i dette tilfælde:

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

--transition-key=MySecetKey

Gendannelse af sikkerhedskopien med en genereret nøgle

Når du gendanner en sikkerhedskopi, skal du generere en ny hovednøgle. Her er eksemplet for nøglering_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 tilfælde af keyring_vault, vil det se sådan ud:

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

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

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