Gadu desmitiem mysqldump ir bijis neapstrīdams „Šveices nazis” MySQL datubāžu dublēšanai. Tas ir visuresošs, vienkāršs un iepriekš instalēts katrā MySQL un MariaDB izplatījumā. Mazām un vidēja izmēra datubāzēm tas darbojas lieliski.
Tomēr, organizācijām augot un datu kopām pārsniedzot 100 GB, 500 GB vai vairāku terabaitu slieksni, paļaušanās uz mysqldump no labākās prakses pārtop par kritisku arhitektūras ievainojamību. Ja esat datubāžu administrators (DBA) vai DevOps inženieris, kas pārvalda liela mēroga ražošanas datubāzes, jūs, visticamāk, esat saskāries ar klusām kļūmēm, ražošanas degradāciju un nepieņemamiem atkopšanas laika mērķiem (RTO), kas saistīti ar loģiskajiem dublējumiem.
Šajā rakstā mēs analizēsim mysqldump arhitektūras ierobežojumus, izpētīsim, kāpēc tas neizdodas liela mēroga vidēs, un detalizēti aprakstīsim, kā ieviest uzņēmuma līmeņa fiziskās dublēšanas stratēģijas, lai aizsargātu jūsu misijai kritiskos datus.
mysqldump arhitektūras ierobežojumi
Lai saprastu, kāpēc mysqldump neizdodas liela mēroga vidēs, mums jāaplūko, kā tas darbojas. mysqldump veic loģiskos dublējumus. Tas vaicā datubāzes dzinējam, nolasa datus un tulko tos SQL paziņojumu sērijā (galvenokārt CREATE TABLE un INSERT INTO).
Lai gan tas izveido ļoti portējamu un cilvēkam lasāmu failu, tas rada nopietnus sastrēgumus vidēs ar augstu caurlaidspēju.
1. Vienpavediena sastrēgums
Pēc dizaina mysqldump ir vienpavediena darbība. Tas apstrādā vienu tabulu pēc otras, rindu pa rindai. Lai gan mūsdienu aparatūra lepojas ar desmitiem CPU kodolu un NVMe krātuvēm, kas spēj nodrošināt gigabaitus sekundē, mysqldump izmanto tikai nelielu daļu no šiem resursiem.
Pat izmantojot standarta karogus InnoDB tabulām:
mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql
Karogs --quick liek mysqldump izgūt rindas pa vienai, nevis buferēt visu tabulu atmiņā, kas novērš atmiņas pārpildes (OOM) kļūdas klienta pusē. Tomēr vienpavediena daba nozīmē, ka 500 GB datubāzes dublēšana var aizņemt 10 līdz 15 stundas, nopietni ietekmējot jūsu atkopšanas punkta mērķi (RPO).
2. InnoDB bufera baseina piesārņojums
Kad mysqldump nolasa katru rindu no katras tabulas, tas liek MySQL dzinējam ielādēt šos datus no diska InnoDB bufera baseinā. Ražošanas vidē jūsu bufera baseins ir rūpīgi aizpildīts ar jūsu „karstajiem” datiem.
Masīvs loģiskais dublējums iztīrīs bufera baseinu, izmetot bieži piekļūtos indeksus un datu lapas, lai atbrīvotu vietu dublējamajiem „aukstajiem” datiem. Tas izraisa pēkšņu, masīvu diska I/O pieaugumu, jo ražošanas vaicājumi ir spiesti lasīt no diska, kas noved pie smagas lietojumprogrammas latentuma.
3. Metadatu bloķēšana un DDL konflikti
Lai saglabātu konsekvenci, administratori paļaujas uz --single-transaction karogu, kas iestata transakciju izolācijas līmeni uz REPEATABLE READ un sāk transakciju pirms datu dublēšanas.
Lai gan tas novērš tabulas līmeņa lasīšanas bloķēšanu (FLUSH TABLES WITH READ LOCK), tas neaizsargā pret datu definīcijas valodas (DDL) izmaiņām. Ja ALTER TABLE, DROP TABLE vai TRUNCATE TABLE komanda tiek izpildīta tabulai, kamēr darbojas mysqldump, dublējums avarēs ar kļūdu table definition has changed, please retry transaction. CI/CD vidēs ar biežām shēmas migrācijām tas izraisa nepārtrauktas dublēšanas kļūmes.
4. RTO murgs: atjaunošanas laiki
Viskatastrofālākā mysqldump kļūme izpaužas nevis dublēšanas, bet gan atjaunošanas laikā.
Loģiskā dublējuma atjaunošanai MySQL dzinējam ir jāparsē un jāizpilda miljoniem INSERT paziņojumu. Par katru ievietoto rindu MySQL ir:
* Jāpārbauda ierobežojumi (ārējās atslēgas, unikālās atslēgas).
* Jāpārbūvē sekundārie indeksi.
* Jāraksta InnoDB redo žurnālā.
* Jāiztukšo binlog (ja iespējots).
1 TB datubāzes atjaunošana no loģiskā dublējuma var aizņemt vairākas dienas. Ja jūsu uzņēmuma RTO ir 4 stundas, mysqldump garantē, ka jūs nepildīsiet savu pakalpojumu līmeņa līgumu (SLA).
Uzņēmuma līmeņa alternatīvas: pāreja uz fiziskajiem dublējumiem
Lai panāktu ātru lielo datu kopu dublēšanu un atjaunošanu, jums ir jāatsakās no loģiskajiem dublējumiem par labu fiziskajiem dublējumiem.
Fiziskie dublējumi pilnībā apiet MySQL SQL izpildes dzinēju. Tā vietā tie kopē pamatā esošos bināros datu failus (.ibd failus, redo žurnālus un undo žurnālus) tieši no failu sistēmas. Tā kā tie tikai kopē failus, tie var darboties ar maksimālo jūsu krātuves aparatūras secīgo lasīšanas/rakstīšanas ātrumu un var tikt ievērojami paralelizēti.
Percona XtraBackup: nozares standarts
InnoDB un XtraDB dzinējiem Percona XtraBackup ir galvenais atvērtā pirmkoda fiziskās dublēšanas rīks. Tas veic MySQL datubāžu karstos, nebloķējošos dublējumus.
Kā darbojas XtraBackup
- Datu kopēšana: XtraBackup sāk kopēt InnoDB datu failus (
.ibd). - Žurnālu izsekošana: Tā kā datubāze ir aktīva, dati mainīsies, kamēr faili tiek kopēti. XtraBackup izveido fona pavedienu, kas uzrauga un kopē InnoDB redo žurnālu (
ib_logfile0utt.) visām transakcijām, kas notiek dublēšanas laikā. - Sagatavošana (avārijas atkopšana): Pēc dublēšanas kopētie datu faili ir nekonsekventā stāvoklī. XtraBackup piemēro kopētos redo žurnālus datu failiem (līdzīgi tam, kā MySQL veic avārijas atkopšanu startēšanas laikā), kā rezultātā tiek iegūts perfekti konsekvents datubāzes momentuzņēmums precīzā brīdī, kad dublēšana tika pabeigta.
Fiziskās dublēšanas stratēģijas ieviešana
Šeit ir tehnisks pārskats par fiziskās dublēšanas stratēģijas ieviešanu, izmantojot Percona XtraBackup.
1. solis: Dublējuma straumēšana
Masīva dublējuma rakstīšana vietējā diskā bieži rada ietilpības problēmas. Labākā prakse ir straumēt dublējumu tieši uz arhīva formātu, saspiest to un nosūtīt uz sagatavošanas zonu vai tieši uz dublēšanas platformu.
Izmantojot xbstream, mēs varam paralelizēt dublēšanu un saspiest to lidojumā:
xtrabackup --backup
--user=backup_user
--password=SecurePassword!
--parallel=4
--stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
--parallel=4: Izmanto 4 pavedienus datu failu vienlaicīgai nolasīšanai.--stream=xbstream: Izvada dublējumu Percona pielāgotajā straumēšanas formātā.lz4: Nodrošina ārkārtīgi ātru, zemas CPU noslodzes saspiešanu.
2. solis: Dublējuma sagatavošana atjaunošanai
Pirms fizisko dublējumu var atjaunot, tas ir jā„sagatavo” (piemērojot redo žurnālus). Vispirms izgūstiet un atspiediet straumi:
mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore
Pēc tam palaidiet sagatavošanas fāzi. Šim solim ir nepieciešama atmiņa, tāpēc pārliecinieties, ka serverim ir piešķirta pietiekama RAM:
xtrabackup --prepare --use-memory=4G --target-dir=/data/restore
3. solis: Datubāzes atjaunošana
Lai atjaunotu, mērķa MySQL datu direktorijai jābūt pilnīgi tukšai. Apturiet MySQL pakalpojumu, iztīriet direktoriju un nokopējiet failus atpakaļ:
systemctl stop mysql
rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/data/restore
Visbeidzot, pirms pakalpojuma startēšanas labojiet failu sistēmas atļaujas:
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql
Tā kā datu faili jau ir izveidoti un indeksi jau ir kompilēti, datubāze startējas nekavējoties. Atjaunošana, kas ar mysqldump aizņēma 48 stundas, tagad aizņem tikai tik daudz laika, cik nepieciešams failu kopēšanai tīklā vai diskā — bieži vien samazinot RTO līdz minūtēm.
Loģisko atjaunošanu optimizēšana (kad tās ir jāizmanto)
Ja esat spiests atjaunot lielu loģisko dublējumu (piemēram, migrējot starp dažādām MySQL versijām vai dažādām CPU arhitektūrām, kur fiziskie faili nav saderīgi), jums īslaicīgi jāpielāgo MySQL konfigurācija, lai optimizētu masīvu rakstīšanas caurlaidspēju.
Pirms loģiskās atjaunošanas sākšanas lietojiet šos iestatījumus savā my.cnf:
[mysqld]
# Īslaicīgi atspējot binlogging, ja šī ir atsevišķa atjaunošana
disable_log_bin
# Aizkavēt iztukšošanu uz disku, lai maksimizētu rakstīšanas ātrumu
innodb_flush_log_at_trx_commit = 2
# Palielināt bufera baseinu, lai ietilptu pēc iespējas vairāk darba kopas
innodb_buffer_pool_size = <Iestatīt uz 70% no kopējās RAM>
# Palielināt žurnāla faila izmēru, lai novērstu agresīvu kontrolpunktu veidošanu
innodb_log_file_size = 2G
# Atspējot doublewrite buferi (riskanti ražošanai, droši sākotnējai ielādei)
innodb_doublewrite = 0
Piezīme: Vienmēr atgrieziet šos iestatījumus uz to ACID atbilstošajiem noklusējumiem (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) un restartējiet MySQL pakalpojumu pirms ražošanas trafika atļaušanas.
Dublējumu automatizācija un nodrošināšana ar CloudSave
Lai gan tādi rīki kā Percona XtraBackup atrisina datu efektīvas izgūšanas mehāniku, patiesai uzņēmuma katastrofu atkopšanas stratēģijai ir nepieciešama orķestrēšana, droša krātuve ārpus telpām un dzīves cikla pārvaldība. Paļaušanās uz pielāgotiem bash skriptiem un cron darbiem fizisko dublējumu pārvaldībai rada augstu kluso kļūmju un atbilstības pārkāpumu risku.
Šeit datubāzes slāņa integrēšana ar uzņēmuma platformu, piemēram, CloudSave, kļūst kritiska.
CloudSave aizpilda plaisu starp neapstrādātām datubāzes utilītprogrammām un uzņēmuma atbilstību. Izmantojot CloudSave pirms- un pēc-skriptēšanas iespējas, DevOps komandas var aktivizēt XtraBackup, lai ģenerētu konsekventu fizisko momentuzņēmumu. Pēc tam CloudSave nemanāmi uzņem dublējuma straumi, piemēro AES-256 šifrēšanu un dedublē datus pirms to replicēšanas uz nemainīgu mākoņa krātuvi.
Šī arhitektūra nodrošina, ka:
1. Tiek saglabāta ražošanas veiktspēja: Dublējumi darbojas ar krātuves ātrumu, nepiesārņojot InnoDB bufera baseinu.
2. Aizsardzība pret izspiedējvīrusiem: Nemainīgas krātuves politikas CloudSave ietvaros neļauj ļaunprātīgiem dalībniekiem dzēst vai šifrēt jūsu datubāzes arhīvus.
3. Automatizēta saglabāšana: GFS (Grandfather-Father-Son) saglabāšanas politikas tiek apstrādātas automātiski, nodrošinot atbilstību datu suverenitātes un audita prasībām.
4. Paredzams RTO: Tā kā CloudSave pārvalda fizisko failu arhīvus, vairāku terabaitu datubāzes atjaunošanu uz jaunu instanci var ātri orķestrēt, sasniedzot stingrus RTO mērķus.
Secinājums
Turpināt izmantot mysqldump liela mēroga datubāzēm ir azartspēle ar jūsu organizācijas darbības laiku un datu integritāti. Vienpavediena daba, bufera baseina piesārņojums un katastrofālie atjaunošanas laiki padara to fundamentāli nepiemērotu mūsdienu vidēm ar augstu caurlaidspēju.
Pārejot uz fiziskajiem dublējumiem, izmantojot tādus rīkus kā Percona XtraBackup, un orķestrējot dzīves ciklu, šifrēšanu un replikāciju ārpus telpām, izmantojot stabilu platformu, piemēram, CloudSave, jūs pārveidojat savu datubāzes dublēšanas stratēģiju no trausla riska par noturīgu, uzņēmuma līmeņa aktīvu. Novērtējiet savus pašreizējos RTO un RPO rādītājus jau šodien — ja atjaunošana aizņem ilgāku laiku, nekā jūsu uzņēmums var atļauties būt bezsaistē, ir pienācis laiks atstāt mysqldump pagātnē.
