Augstā riska datubāžu administrēšanas un vietņu uzticamības inženierijas pasaulē pastāv labi zināma aksioma: Šrēdingera dublējumkopija. Jebkuras dublējumkopijas stāvoklis nav zināms, līdz jūs mēģināt to atjaunot. Līdz tam brīdim tā pastāv kvantu stāvoklī, būdama gan pilnībā izmantojama, gan pilnībā bojāta.
DevOps inženieriem un datubāžu administratoriem (DBA) atklājums, ka kritiska datubāzes dublējumkopija ir bojāta aktīva incidenta laikā, ir vislielākais murgs. Tas pārvērš rutīnas atjaunošanas darbību katastrofālā datu zaudēšanas notikumā. Šis datu integritātes “klusais slepkava” bieži paliek nepamanīts, jo dublēšanas uzdevumi bieži ziņo par veiksmīgu Exit Code 0 pat tad, ja pamatā esošie dati ir kompromitēti.
Šajā visaptverošajā rokasgrāmatā mēs izanalizēsim dublējumkopiju bojājumu anatomiju, izpētīsim datubāzēm specifiskas validācijas metodes un parādīsim, kā izveidot automatizētus, drošus atjaunošanas konveijerus ražošanas vidēm.
Dublējumkopiju bojājumu anatomija
Lai atklātu bojājumus, vispirms ir jāsaprot, kā tie rodas. Dublējumkopiju bojājumi parasti iedalās divās kategorijās: fiziskie (infrastruktūras līmenī) un loģiskie (lietojumprogrammas līmenī).
Fiziskie bojājumi
Fiziskie bojājumi rodas, kad tiek mainīti faktiskie biti uz datu nesēja. Tas var notikt nolasīšanas procesā no avota diska, tīkla pārsūtīšanas laikā vai mērķa krātuvē.
* Bitu bojāšanās (Bit Rot): Pakāpeniska datu nesēju degradācija var klusi mainīt bitus.
* Pārsūtīšanas kļūdas: Lai gan TCP ir kontrolsummas, tās ir vājas (16-bitu). Augstas caurlaidības vidēs var rasties klusa datu bojāšanās tīklā, ko TCP nespēj uztvert.
* Atmiņas kontroliera kļūdas: RAID kontrolieru vai SAN audumu aparatūras kļūdas var ierakstīt nederīgus datus, vienlaikus ziņojot operētājsistēmai par panākumiem.
Loģiskie bojājumi
Loģiskie bojājumi ir, iespējams, bīstamāki, jo pati dublējumkopijas datne ir pilnībā neskarta, bet tajā esošie dati ir bojāti.
* Atkritumi iekšā, atkritumi ārā (GIGO): Ja jūsu aktīvajai datubāzei ir bojāts indekss vai lapa, jūsu dublēšanas rīks var uzticīgi nokopēt šo bojāto lapu. Dublēšanas uzdevums ir veiksmīgs, bet atjaunošana neizdosies vai radīs bojātu datubāzi.
* Nepabeigti darījumi: Failu sistēmas līmeņa momentuzņēmumi, kas uzņemti, pienācīgi neiesaldējot datubāzes I/O (piemēram, neizmantojot FLUSH TABLES WITH READ LOCK MySQL), rada bojātas lapas un neatjaunojamus stāvokļus.
Proaktīva atklāšana: Kontrolsummas un kriptogrāfiskā jaukšana
Pirmā aizsardzības līnija pret fiziskiem bojājumiem ir kriptogrāfiskā validācija. Paļaušanās uz failu izmēriem vai modificēšanas datumiem nav pietiekama.
Datubāzes līmeņa kontrolsummu iespējošana
Mūsdienu relāciju datubāžu pārvaldības sistēmas (RDBMS) atbalsta lapas līmeņa kontrolsummas. Kad tās ir iespējotas, datubāze aprēķina kontrolsummu katrai lapai pirms tās ierakstīšanas diskā. Kad lapa tiek nolasīta (ar vaicājumu vai dublēšanas procesu), kontrolsumma tiek pārbaudīta.
PostgreSQL gadījumā jūs varat iespējot datu kontrolsummas klastera inicializācijas laikā:
# Inicializēt jaunu PostgreSQL klasteri ar iespējotām kontrolsummām
initdb --data-checksums -D /var/lib/postgresql/data
Piezīme: Ja jums ir esošs PostgreSQL klasteris, varat izmantot pg_checksums utilītu, lai tās iespējotu bezsaistē.
Microsoft SQL Server gadījumā pārliecinieties, ka PAGE_VERIFY ir iestatīts uz CHECKSUM (noklusējums mūsdienu versijās, bet vērts pārbaudīt vecākās sistēmās):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Dublējumkopiju validēšana krātuvē
Kad dublējumkopija nonāk jūsu krātuvē, tās integritāte ir kriptogrāfiski jāpārbauda. Uzņēmumu dublēšanas platformas, piemēram, CloudSave, automātiski aprēķina un verificē dublējumkopiju bloku SHA-256 jaucējkodus pārsūtīšanas un uzglabāšanas laikā. Ja pārvaldāt pielāgotus skriptus, tas jādara manuāli:
# Ģenerēt SHA-256 jaucējkodu pēc dublējumkopijas izveides
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Verificēt jaucējkodu krātuves serverī
sha256sum -c prod_db_backup.tar.gz.sha256
Datubāzēm specifiskas validācijas metodes
Dažādi datubāžu dzinēji piedāvā vietējos rīkus to dublējumkopiju integritātes pārbaudei.
PostgreSQL: pg_verifybackup
Ieviests PostgreSQL 13, pg_verifybackup ir būtisks rīks fiziskajām dublējumkopijām, kas veiktas ar pg_basebackup. Tas nolasa backup_manifest failu, kas ģenerēts dublēšanas laikā, un pārbauda, vai visi faili ir klāt un to kontrolsummas sakrīt.
# Palaist verifikāciju fiziskās bāzes dublējumkopijas direktorijai
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Ja kādā no datu failiem ir mainījies kaut viens bits, pg_verifybackup izmetīs fatālu kļūdu, ļaujot jūsu uzraudzības sistēmām nekavējoties brīdināt DBA komandu.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server nodrošina vietējo komandu, lai pārbaudītu dublējumkopijas faila fizisko integritāti, faktiski to neatjaunojot. Tā pārbauda dublējumkopijas galvenes un validē lapu kontrolsummas (ja tās bija iespējotas dublēšanas laikā).
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Brīdinājums: RESTORE VERIFYONLY tikai apstiprina, ka dublējumkopijas fails ir nolasāms un fiziskās kontrolsummas sakrīt. Tas negarantē loģisko integritāti. Lai nodrošinātu loģisko integritāti, ir jāveic pilna atjaunošana un jāpalaiž DBCC CHECKDB.
MySQL / InnoDB: Percona XtraBackup
MySQL vidēs fiziskās dublējumkopijas bieži apstrādā Percona XtraBackup. Dublēšanas process sastāv no failu kopēšanas, bet dublējumkopija nav konsekventa, līdz netiek lietoti darījumu žurnāli (redo logs). --prepare fāze darbojas kā iebūvēta integritātes pārbaude.
# Dublējumkopijas sagatavošana pielieto redo žurnālus.
# Ja dublējumkopija ir bojāta, šis solis neizdosies.
xtrabackup --prepare --target-dir=/data/backups/mysql/
Zelta standarts: Automatizēta atjaunošanas testēšana
Kontrolsummas un verifikācijas komandas ir nepieciešamas, bet ar tām nepietiek. Vienīgais veids, kā pārliecinoši pierādīt, ka dublējumkopija ir derīga, ir to atjaunot. Mūsdienu DevOps vidēs šim procesam jābūt pilnībā automatizētam.
Izmantojot dublējumkopijas kā kodu, varat izveidot CI/CD konveijeru savu datubāžu atjaunošanai. Šim konveijeram ir jāizveido īslaicīga infrastruktūra, jāveic atjaunošana, jāpalaiž validācijas vaicājumi un jāizdzēš vide.
Automatizēta atjaunošanas konveijera izveide
Zemāk ir Bash skripta piemērs, ko varētu katru dienu aktivizēt ar cron darbu vai CI izpildītāju (piemēram, GitLab CI vai GitHub Actions), lai validētu PostgreSQL loģisko izgāzumu (dump).
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Sākas automatizētais atjaunošanas tests..."
# 1. Palaist īslaicīgu PostgreSQL konteineru
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# Gaidīt, līdz PostgreSQL ir gatavs
echo "[INFO] Gaidām datubāzes inicializāciju..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Izveidot mērķa datubāzi
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Veikt atjaunošanu
echo "[INFO] Atjaunojam dublējumkopiju..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump
# 4. Palaist loģiskās validācijas vaicājumus
echo "[INFO] Palaižam validācijas vaicājumus..."
# Pārbaudīt, vai lietotāju tabulā ir vairāk nekā 10 000 ierakstu
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")
if [ "$USER_COUNT" -lt 10000 ]; then
echo "[ERROR] Loģiskā validācija neizdevās. Gaidīts >10000 lietotāju, atrasti $USER_COUNT"
# Šeit aktivizēt PagerDuty / Slack brīdinājumu
exit 1
else
echo "[SUCCESS] Loģiskā validācija veiksmīga. Lietotāju skaits: $USER_COUNT"
fi
# 5. Izdzēst īslaicīgo vidi
echo "[INFO] Tīrīšana..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Automatizētais atjaunošanas tests veiksmīgi pabeigts."
Kas jāvalidē?
Veicot automatizētu atjaunošanas testēšanu, nepārbaudiet tikai to, vai datubāze startējas. Palaidiet lietojumprogrammai specifiskus validācijas vaicājumus:
1. Rindu skaits: Pārliecinieties, ka galvenajās tabulās ir gaidītais rindu skaits (piemēram, users tabula nedrīkst būt tukša).
2. Jaunākie dati: Vaicājiet ierakstus, kas izveidoti pēdējo 24 stundu laikā, lai nodrošinātu, ka dublējumkopija nav novecojusi.
3. Referenciālā integritāte: Palaidiet skriptus, lai pārbaudītu bāreņu ārējās atslēgas, kas norāda uz loģiskiem bojājumiem.
Uzraudzība un brīdinājumi par dublējumkopiju anomālijām
Bojājumu atklāšana pirms katastrofas iestāšanās prasa spēcīgu novērojamību. Papildus binārajiem veiksmes/neveiksmes stāvokļiem jums vajadzētu uzraudzīt savu dublēšanas darbu metadatus, lai atklātu anomālijas.
Heiristiskā uzraudzība
Integrējiet savus dublēšanas metadatus Prometheus un vizualizējiet tos ar Grafana. Iestatiet brīdinājumus par šādām heiristikām:
* Pēkšņs izmēra kritums: Ja jūsu ikdienas dublējumkopija konsekventi ir 500 GB, bet šodienas dublējumkopija ir 50 MB, darbs var būt pabeigts veiksmīgi (Exit Code 0), bet, visticamāk, tas dublēja tukšu shēmu.
* Ilguma anomālijas: Ja dublējumkopija, kas parasti aizņem 2 stundas, pabeidzas 5 minūtēs, kaut kas tika izlaists. Savukārt, ja tas aizņem 10 stundas, iespējama diska I/O degradācija, kas var novest pie bojājumiem.
* WAL/arhīva žurnālu uzkrāšanās: Ja jūsu datubāze ģenerē Write-Ahead Logs (WAL), bet dublēšanas sistēma tos nearhivē pietiekami ātri, jūs riskējat ar pārtraukumu savā Point-in-Time Recovery (PITR) ķēdē.
3-2-1 noteikuma ieviešana ar integritātes pārbaudēm
Nozares standarta 3-2-1 dublēšanas noteikums (3 datu kopijas, 2 dažādi nesēji, 1 ārpus telpām) ir efektīvs tikai tad, ja visas kopijas ir verificētas.
Šeit uzņēmuma risinājuma, piemēram, CloudSave, izmantošana ievērojami samazina darbības izmaksas. Tā vietā, lai rakstītu un uzturētu sarežģītus bash skriptus katram datubāzes mezglam, CloudSave integrējas tieši jūsu infrastruktūrā, lai automatizētu 3-2-1 dzīves ciklu. Tas nodrošina nemainīgu krātuvi — aizsardzību pret izspiedējvīrusiem — un ietver iebūvētus, automatizētus atjaunošanas verifikācijas grafikus. CloudSave var automātiski izveidot izolētas smilškastes vides, piemontēt dublējumkopiju, palaist jūsu pielāgotos SQL validācijas skriptus un ziņot par veselības stāvokli atpakaļ uz jūsu centrālo informācijas paneli.
Secinājums
Bojātas datubāžu dublējumkopijas ir kluss slepkava, kas var iznīcināt uzņēmumus. Paļaušanās tikai uz dublēšanas skripta Exit Code 0 ir bīstama azartspēle.
Lai patiesi aizsargātu savas ražošanas vides, jums jāpieņem padziļinātas aizsardzības stratēģija:
1. Iespējojiet lapas līmeņa kontrolsummas savā datubāzes dzinējā.
2. Izmantojiet vietējos verifikācijas rīkus (pg_verifybackup, RESTORE VERIFYONLY) uzreiz pēc dublējumkopijas izveides.
3. Uzraugiet dublēšanas metadatus (izmēru, ilgumu) heiristiskām anomālijām.
4. Ieviesiet automatizētu, īslaicīgu atjaunošanas testēšanu kā daļu no sava ikdienas darbības konveijera.
Pārejot no pasīvas “palaist un aizmirst” dublēšanas mentalitātes uz aktīvu “nepārtrauktas atjaunošanas validācijas” modeli, jūs nodrošināt, ka tad, kad neizbēgami notiks katastrofa, jūsu dati būs gatavi, uzticami un pilnībā atjaunojami.
