Categories
Database Backup

** Discover why mysqldump fails large MySQL databases and learn how to implement enterprise-grade physical backups using Percona XtraBackup and CloudSave to drastically reduce your RTO.

Dešimtmečius mysqldump buvo neginčijamas „šveicariškas peilis“ MySQL duomenų bazių atsarginėms kopijoms kurti. Jis yra visur paplitęs, paprastas ir iš anksto įdiegtas kiekvienoje MySQL bei MariaDB distribucijoje. Mažoms ir vidutinio dydžio duomenų bazėms jis veikia puikiai.

Tačiau organizacijoms augant ir duomenų rinkiniams viršijant 100 GB, 500 GB ar kelių terabaitų ribas, pasikliovimas mysqldump iš geriausios praktikos virsta kritiniu architektūriniu pažeidžiamumu. Jei esate duomenų bazių administratorius (DBA) ar „DevOps“ inžinierius, valdantis didelio masto gamybines duomenų bazes, tikriausiai susidūrėte su tyliomis klaidomis, gamybos našumo mažėjimu ir nepriimtinais atkūrimo laiko tikslais (RTO), susijusiais su loginėmis kopijomis.

Šiame straipsnyje išnagrinėsime architektūrinius mysqldump apribojimus, išsiaiškinsime, kodėl jis neefektyvus dideliu mastu, ir detaliai aptarsime, kaip įdiegti verslo klasės fizinio atsarginių kopijų kūrimo strategijas, kad apsaugotumėte savo kritinius duomenis.

Architektūriniai mysqldump apribojimai

Norėdami suprasti, kodėl mysqldump neefektyvus dideliu mastu, turime išnagrinėti, kaip jis veikia „po gaubtu“. mysqldump atlieka logines atsargines kopijas. Jis užklausia duomenų bazės variklio, nuskaito duomenis ir paverčia juos SQL teiginių serija (pirmiausia CREATE TABLE ir INSERT INTO).

Nors tai sukuria labai perkeliamą, žmogui suprantamą failą, tai sukelia rimtų kliūčių aplinkose, kuriose vyksta didelis duomenų srautas.

1. Vienos gijos kliūtis

Pagal dizainą mysqldump yra vienos gijos operacija. Jis apdoroja po vieną lentelę, eilutė po eilutės. Nors šiuolaikinė techninė įranga pasižymi dešimtimis CPU branduolių ir NVMe saugyklomis, galinčiomis užtikrinti gigabaitų per sekundę pralaidumą, mysqldump išnaudoja tik dalį šių resursų.

Net naudojant standartines vėliavėles InnoDB lentelėms:

mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql

Vėliavėlė --quick priverčia mysqldump nuskaityti eilutes po vieną, o ne buferizuoti visą lentelę atmintyje, o tai apsaugo nuo „Out of Memory“ (OOM) klaidų kliento pusėje. Tačiau dėl vienos gijos pobūdžio 500 GB duomenų bazės kopijavimas gali užtrukti nuo 10 iki 15 valandų, o tai smarkiai paveikia jūsų atkūrimo taško tikslą (RPO).

2. InnoDB buferio baseino tarša

Kai mysqldump nuskaito kiekvieną kiekvienos lentelės eilutę, jis priverčia MySQL variklį įkelti tuos duomenis iš disko į InnoDB buferio baseiną. Gamybinėje aplinkoje jūsų buferio baseinas yra kruopščiai užpildytas „karštais“ duomenimis.

Didžiulė loginė kopija „išvalys“ buferio baseiną, išstumdama dažnai naudojamus indeksus ir duomenų puslapius, kad atlaisvintų vietos kopijuojamiems „šaltiems“ duomenims. Tai sukelia staigų, didžiulį disko I/O šuolį, nes gamybinės užklausos priverstos skaityti iš disko, o tai lemia didelį programos vėlavimą.

3. Metaduomenų užraktai ir DDL konfliktai

Norėdami išlaikyti nuoseklumą, administratoriai pasikliauja --single-transaction vėliavėle, kuri nustato operacijų izoliacijos lygį į REPEATABLE READ ir pradeda operaciją prieš kopijuojant duomenis.

Nors tai leidžia išvengti lentelės lygio skaitymo užraktų (FLUSH TABLES WITH READ LOCK), tai neapsaugo nuo duomenų apibrėžimo kalbos (DDL) pakeitimų. Jei ALTER TABLE, DROP TABLE arba TRUNCATE TABLE komanda įvykdoma lentelei, kol veikia mysqldump, atsarginė kopija nutrūks su klaida table definition has changed, please retry transaction. CI/CD aplinkose su dažnomis schemų migracijomis tai sukelia nuolatines atsarginių kopijų kūrimo nesėkmes.

4. RTO košmaras: Atkūrimo laikas

Didžiausia mysqldump nesėkmė pasireiškia ne kuriant kopiją, o ją atkuriant.

Loginės kopijos atkūrimas reikalauja, kad MySQL variklis išanalizuotų ir įvykdytų milijonus INSERT teiginių. Kiekvienai įterptai eilutei MySQL turi:
* Patikrinti apribojimus (užsienio raktus, unikalius raktus).
* „Skrydžio metu“ atstatyti antrinius indeksus.
* Įrašyti į InnoDB redo žurnalą.
* Įrašyti į binlog (jei įjungtas).

1 TB duomenų bazės atkūrimas iš loginės kopijos gali užtrukti kelias dienas. Jei jūsų verslo RTO yra 4 valandos, mysqldump garantuoja, kad pažeisite paslaugų lygio sutartį (SLA).

Verslo klasės alternatyvos: Perėjimas prie fizinių atsarginių kopijų

Norėdami pasiekti greitą atsarginių kopijų kūrimą ir atkūrimą dideliems duomenų rinkiniams, turite atsisakyti loginių kopijų ir rinktis fizines atsargines kopijas.

Fizinės atsarginės kopijos visiškai aplenkia MySQL SQL vykdymo variklį. Vietoj to jos tiesiogiai iš failų sistemos kopijuoja pagrindinius dvejetainius duomenų failus (.ibd failus, redo žurnalus ir undo žurnalus). Kadangi tai tik failų kopijavimas, jos gali veikti maksimaliu nuosekliu jūsų saugyklos techninės įrangos skaitymo/rašymo greičiu ir gali būti stipriai lygiagrečiai vykdomos.

Percona XtraBackup: Pramonės standartas

InnoDB ir XtraDB varikliams Percona XtraBackup yra pagrindinis atviro kodo fizinių atsarginių kopijų įrankis. Jis atlieka „karštas“, neužrakinančias MySQL duomenų bazių kopijas.

Kaip veikia XtraBackup

  1. Duomenų kopijavimas: XtraBackup pradeda kopijuoti InnoDB duomenų failus (.ibd).
  2. Žurnalų sekimas: Kadangi duomenų bazė veikia, duomenys keisis, kol failai bus kopijuojami. XtraBackup sukuria fono giją, kuri stebi ir kopijuoja InnoDB redo žurnalą (ib_logfile0 ir kt.) visoms operacijoms, įvykusioms kopijavimo metu.
  3. Paruošimas (atkūrimas po avarijos): Po kopijavimo duomenų failai yra nenuoseklios būsenos. XtraBackup pritaiko nukopijuotus redo žurnalus duomenų failams (panašiai kaip MySQL atlieka atkūrimą po avarijos paleidžiant), todėl gaunamas visiškai nuoseklus duomenų bazės momentinis vaizdas tiksliai tuo momentu, kai kopijavimas buvo baigtas.

Fizinio atsarginių kopijų kūrimo strategijos įgyvendinimas

Štai techninis vadovas, kaip įgyvendinti fizinio atsarginių kopijų kūrimo strategiją naudojant Percona XtraBackup.

1 žingsnis: Atsarginės kopijos srautinis perdavimas

Didžiulės atsarginės kopijos rašymas į vietinį diską dažnai sukelia talpos problemų. Geriausia praktika diktuoja srautinį kopijos perdavimą tiesiai į archyvo formatą, jos suspaudimą ir siuntimą į tarpinę saugyklą arba tiesiai į atsarginių kopijų platformą.

Naudodami xbstream, galime lygiagrečiai vykdyti kopijavimą ir suspausti duomenis „skrydžio metu“:

xtrabackup --backup 
  --user=backup_user 
  --password=SecurePassword! 
  --parallel=4 
  --stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
  • --parallel=4: Naudoja 4 gijas duomenų failams vienu metu skaityti.
  • --stream=xbstream: Išveda kopiją Percona pasirinktiniu srautiniu formatu.
  • lz4: Užtikrina itin greitą, mažai CPU apkraunantį suspaudimą.

2 žingsnis: Atsarginės kopijos paruošimas atkūrimui

Prieš atkuriant fizinę kopiją, ji turi būti „paruošta“ (pritaikant redo žurnalus). Pirmiausia išskleiskite ir dekompresuokite srautą:

mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore

Tada paleiskite paruošimo fazę. Šiam žingsniui reikia atminties, todėl įsitikinkite, kad serveris turi pakankamai RAM:

xtrabackup --prepare --use-memory=4G --target-dir=/data/restore

3 žingsnis: Duomenų bazės atkūrimas

Norint atkurti, tikslinis MySQL duomenų katalogas turi būti visiškai tuščias. Sustabdykite MySQL paslaugą, išvalykite katalogą ir nukopijuokite failus atgal:

systemctl stop mysql
rm -rf /var/lib/mysql/*

xtrabackup --copy-back --target-dir=/data/restore

Galiausiai, prieš paleisdami paslaugą, pataisykite failų sistemos teises:

chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

Kadangi duomenų failai jau sukurti ir indeksai sukompiliuoti, duomenų bazė pasileidžia nedelsiant. Atkūrimas, kuris su mysqldump užtrukdavo 48 valandas, dabar trunka tik tiek, kiek užtrunka failų kopijavimas per tinklą ar diską – dažnai RTO sumažinamas iki minučių.

Loginių atkūrimų optimizavimas (kai privalote juos naudoti)

Jei esate priversti atkurti didelę loginę kopiją (pvz., migruojant tarp skirtingų pagrindinių MySQL versijų arba skirtingų CPU architektūrų, kur fiziniai failai nesuderinami), turite laikinai sureguliuoti MySQL konfigūraciją, kad optimizuotumėte didžiulį rašymo pralaidumą.

Prieš pradėdami loginį atkūrimą, pritaikykite šiuos nustatymus savo my.cnf:

[mysqld]
# Laikinai išjunkite binlogging, jei tai atskiras atkūrimas
disable_log_bin

# Atidėkite išrašymą į diską, kad maksimaliai padidintumėte rašymo greitį
innodb_flush_log_at_trx_commit = 2

# Padidinkite buferio baseiną, kad tilptų kuo daugiau darbo rinkinio
innodb_buffer_pool_size = <Nustatykite 70% viso RAM>

# Padidinkite žurnalo failo dydį, kad išvengtumėte agresyvaus tikrinimo
innodb_log_file_size = 2G

# Išjunkite doublewrite buferį (rizikinga gamybai, saugu pradiniam įkėlimui)
innodb_doublewrite = 0

Pastaba: Visada grąžinkite šiuos nustatymus į jų ACID atitinkančius numatytuosius parametrus (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) ir iš naujo paleiskite MySQL paslaugą prieš leisdami gamybinį srautą.

Atsarginių kopijų automatizavimas ir apsauga su CloudSave

Nors tokie įrankiai kaip Percona XtraBackup išsprendžia duomenų efektyvaus ištraukimo mechaniką, tikrai verslo klasės atkūrimo po avarijos strategijai reikia orkestravimo, saugios saugyklos ne vietoje ir gyvavimo ciklo valdymo. Pasikliovimas pasirinktiniais „bash“ scenarijais ir „cron“ užduotimis fizinėms kopijoms valdyti sukelia didelę tylių klaidų ir atitikties pažeidimų riziką.

Štai čia tampa kritiškai svarbu integruoti duomenų bazės sluoksnį su verslo platforma, tokia kaip CloudSave.

CloudSave sujungia spragą tarp neapdorotų duomenų bazės įrankių ir verslo atitikties. Naudodamos „CloudSave“ scenarijų vykdymo galimybes prieš ir po kopijavimo, „DevOps“ komandos gali inicijuoti XtraBackup, kad būtų sukurtas nuoseklus fizinis momentinis vaizdas. Tada „CloudSave“ sklandžiai priima atsarginės kopijos srautą, pritaiko AES-256 šifravimą ir pašalina dublikatus prieš replikuodama duomenis į nekeičiamą debesies saugyklą.

Ši architektūra užtikrina, kad:
1. Išlaikomas gamybos našumas: Atsarginės kopijos veikia saugyklos greičiu, neužteršdamos InnoDB buferio baseino.
2. Apsauga nuo išpirkos reikalaujančių programų: „CloudSave“ nekeičiamos saugyklos politika neleidžia piktavaliams ištrinti ar užšifruoti jūsų duomenų bazės archyvų.
3. Automatizuotas saugojimas: GFS (Grandfather-Father-Son) saugojimo politika tvarkoma automatiškai, užtikrinant atitiktį duomenų suverenumo ir audito reikalavimams.
4. Nuspėjamas RTO: Kadangi „CloudSave“ valdo fizinių failų archyvus, kelių terabaitų duomenų bazės atkūrimas į naują egzempliorių gali būti greitai suplanuotas, pasiekiant griežtus RTO tikslus.

Išvada

Tolesnis mysqldump naudojimas didelio masto duomenų bazėms yra lošimas su jūsų organizacijos veiklos tęstinumu ir duomenų vientisumu. Vienos gijos pobūdis, buferio baseino tarša ir katastrofiškai ilgas atkūrimo laikas daro jį iš esmės netinkamą šiuolaikinėms, didelio srauto aplinkoms.

Pereidami prie fizinių atsarginių kopijų naudodami tokius įrankius kaip Percona XtraBackup ir orkestruodami gyvavimo ciklą, šifravimą bei replikaciją per patikimą platformą, tokią kaip CloudSave, jūs paverčiate savo duomenų bazės atsarginių kopijų strategiją iš trapios rizikos į atsparų, verslo klasės turtą. Įvertinkite savo dabartinius RTO ir RPO rodiklius šiandien – jei atkūrimas trunka ilgiau, nei jūsų verslas gali sau leisti būti nepasiekiamas, laikas palikti mysqldump praeityje.

Kategorijos