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.

Aastakümneid on mysqldump olnud vaieldamatu Šveitsi armeenuga MySQL-i andmebaaside varundamiseks. See on kõikjal levinud, lihtne ja eelinstallitud igasse MySQL-i ja MariaDB distributsiooni. Väikeste ja keskmise suurusega andmebaaside puhul toimib see suurepäraselt.

Kuid kui organisatsioonid kasvavad ja andmekogumid ületavad 100 GB, 500 GB või mitme terabaidi piiri, muutub mysqldump-ile tuginemine parimast tavast kriitiliseks arhitektuuriliseks haavatavuseks. Kui olete andmebaasiadministraator (DBA) või DevOps-insener, kes haldab suuremahulisi tootmisandmebaase, olete tõenäoliselt kogenud vaikivaid tõrkeid, tootmise jõudluse langust ja vastuvõetamatuid taastamisaja eesmärke (RTO), mis on seotud loogiliste dumpidega.

Selles artiklis analüüsime mysqldump-i arhitektuurilisi piiranguid, uurime, miks see mastaapsuse korral ebaõnnestub, ja kirjeldame, kuidas rakendada ettevõtte tasemel füüsilise varundamise strateegiaid oma missioonikriitiliste andmete kaitsmiseks.

mysqldump-i arhitektuurilised piirangud

Et mõista, miks mysqldump mastaapsuse korral ebaõnnestub, peame uurima, kuidas see kapoti all töötab. mysqldump teostab loogilisi varukoopiaid. See pärib andmebaasimootorit, loeb andmeid ja tõlgib need SQL-lausete jadaks (peamiselt CREATE TABLE ja INSERT INTO).

Kuigi see loob väga kaasaskantava ja inimloetava faili, tekitab see suure läbilaskevõimega keskkondades tõsiseid kitsaskohti.

1. Ühelõimeline kitsaskoht

Oma olemuselt on mysqldump ühelõimeline operatsioon. See töötleb ühte tabelit korraga, rida-realt. Kuigi kaasaegne riistvara uhkeldab kümnete protsessorituumade ja NVMe-salvestusseadmetega, mis suudavad edastada gigabaite sekundis, kasutab mysqldump vaid murdosa nendest ressurssidest.

Isegi kui kasutate InnoDB tabelite jaoks standardseid lippe:

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

Lipp --quick sunnib mysqldump-i ridu ükshaaval hankima, selle asemel et puhverdada kogu tabelit mällu, mis hoiab ära mälumahu ületamise (OOM) vead kliendi poolel. Siiski tähendab ühelõimelisus seda, et 500 GB andmebaasi dumpimine võib võtta 10 kuni 15 tundi, mis mõjutab tõsiselt teie taastepunkti eesmärki (RPO).

2. InnoDB puhverbasseini reostus

Kui mysqldump loeb iga tabeli iga rida, sunnib see MySQL-i mootorit laadima need andmed kettalt InnoDB puhverbasseini. Tootmiskeskkonnas on teie puhverbassein hoolikalt täidetud teie “kuuma” tööandmestikuga.

Massiivne loogiline dump pühib puhverbasseini puhtaks, tõrjudes välja sageli kasutatavad indeksid ja andmelehed, et teha ruumi varundatavatele “külmadele” andmetele. See põhjustab järsu ja massiivse ketta I/O hüppe, kuna tootmispäringud on sunnitud lugema kettalt, mis viib rakenduse tõsise latentsuseni.

3. Metaandmete lukud ja DDL-konfliktid

Järjepidevuse säilitamiseks toetuvad DBA-d lipule --single-transaction, mis määrab tehingute isolatsioonitasemeks REPEATABLE READ ja alustab tehingut enne andmete dumpimist.

Kuigi see väldib tabelitasemel lugemislukke (FLUSH TABLES WITH READ LOCK), ei kaitse see andmemääratluse keele (DDL) muudatuste eest. Kui ALTER TABLE, DROP TABLE või TRUNCATE TABLE käsk täidetakse tabelis ajal, mil mysqldump töötab, jookseb varukoopia kokku veaga table definition has changed, please retry transaction. CI/CD keskkondades, kus skeemi migratsioonid on sagedased, põhjustab see pidevaid varundamise tõrkeid.

4. RTO õudusunenägu: Taastamisajad

mysqldump-i kõige katastroofilisem puudus ei ilmne mitte varundamise, vaid taastamise ajal.

Loogilise dump-i taastamine nõuab, et MySQL-i mootor parsiks ja täidaks miljoneid INSERT-lauseid. Iga sisestatud rea puhul peab MySQL:
* Kontrollima piiranguid (välisvõtmed, unikaalsed võtmed).
* Taastama sekundaarsed indeksid jooksvalt.
* Kirjutama InnoDB redo-logisse.
* Loputama binlogi (kui see on lubatud).

1 TB andmebaasi taastamine loogilisest dumpist võib võtta mitu päeva. Kui teie ettevõtte RTO on 4 tundi, garanteerib mysqldump, et rikute oma teenusetaseme lepingut (SLA).

Ettevõtte tasemel alternatiivid: Üleminek füüsilistele varukoopiatele

Kiirete varukoopiate ja taastamiste saavutamiseks suurte andmekogumite puhul peate loobuma loogilistest varukoopiatest ja eelistama füüsilisi varukoopiaid.

Füüsilised varukoopiad mööduvad MySQL-i SQL-i täitmismootorist täielikult. Selle asemel kopeerivad nad aluseks olevad binaarsed andmefailid (.ibd-failid, redo-logid ja undo-logid) otse failisüsteemist. Kuna nad lihtsalt kopeerivad faile, saavad nad töötada teie salvestusriistvara maksimaalsel järjestikusel lugemis-/kirjutamiskiirusel ja neid saab tugevalt paralleelida.

Percona XtraBackup: Tööstusstandard

InnoDB ja XtraDB mootorite jaoks on Percona XtraBackup peamine avatud lähtekoodiga füüsilise varundamise tööriist. See teostab MySQL-i andmebaaside “kuumi”, blokeerimata varukoopiaid.

Kuidas XtraBackup töötab

  1. Andmete kopeerimine: XtraBackup alustab InnoDB andmefailide (.ibd) kopeerimist.
  2. Logide jälgimine: Kuna andmebaas on aktiivne, muutuvad andmed failide kopeerimise ajal. XtraBackup käivitab taustalõime, mis jälgib ja kopeerib InnoDB redo-logi (ib_logfile0 jne) kõigi tehingute jaoks, mis toimuvad varundamise ajal.
  3. Ettevalmistus (krahhijärgne taastamine): Pärast varundamist on kopeeritud andmefailid ebajärjekindlas olekus. XtraBackup rakendab kopeeritud redo-logid andmefailidele (sarnaselt sellele, kuidas MySQL teostab käivitamisel krahhijärgset taastamist), mille tulemuseks on andmebaasi täiesti järjepidev hetktõmmis täpselt sel hetkel, kui varundamine lõppes.

Füüsilise varundamise strateegia rakendamine

Siin on tehniline ülevaade füüsilise varundamise strateegia rakendamisest, kasutades Percona XtraBackupi.

1. samm: Varukoopia voogedastus

Massiivse varukoopia kirjutamine kohalikule kettale põhjustab sageli mahuprobleeme. Parim tava on voogedastada varukoopia otse arhiivivormingusse, tihendada see ja saata see vahealasse või otse varundusplatvormile.

Kasutades xbstream-i, saame varundamist paralleelida ja jooksvalt tihendada:

xtrabackup --backup 
  --user=backup_user 
  --password=SecurePassword! 
  --parallel=4 
  --stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
  • --parallel=4: Kasutab 4 lõime andmefailide samaaegseks lugemiseks.
  • --stream=xbstream: Väljastab varukoopia Percona kohandatud voogedastusvormingus.
  • lz4: Pakub äärmiselt kiiret ja madala protsessorikasutusega tihendamist.

2. samm: Varukoopia ettevalmistamine taastamiseks

Enne füüsilise varukoopia taastamist tuleb see “ette valmistada” (redo-logide rakendamine). Kõigepealt ekstraktige ja dekompresseerige voog:

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

Järgmisena käivitage ettevalmistusfaas. See samm nõuab mälu, seega veenduge, et serveril on piisavalt RAM-i eraldatud:

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

3. samm: Andmebaasi taastamine

Taastamiseks peab sihtkoha MySQL-i andmekataloog olema täiesti tühi. Peatage MySQL-i teenus, tühjendage kataloog ja kopeerige failid tagasi:

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

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

Lõpuks parandage failisüsteemi õigused enne teenuse käivitamist:

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

Kuna andmefailid on juba ehitatud ja indeksid kompileeritud, käivitub andmebaas koheselt. Taastamine, mis mysqldump-iga võttis 48 tundi, võtab nüüd vaid nii kaua, kui kulub failide kopeerimiseks üle võrgu või ketta – vähendades sageli RTO minutiteni.

Loogiliste taastamiste optimeerimine (kui peate neid kasutama)

Kui olete sunnitud taastama suure loogilise dump-i (nt migreerimine erinevate MySQL-i suurversioonide vahel või erinevate protsessoriarhitektuuride vahel, kus füüsilised failid ei ühildu), peate ajutiselt häälestama oma MySQL-i konfiguratsiooni, et optimeerida massiivset kirjutamiskiirust.

Rakendage need sätted oma my.cnf-i enne loogilise taastamise alustamist:

[mysqld]
# Keela binlogging ajutiselt, kui tegemist on eraldiseisva taastamisega
disable_log_bin

# Viivita kettale kirjutamist, et maksimeerida kirjutamiskiirust
innodb_flush_log_at_trx_commit = 2

# Suurenda puhverbasseini, et mahutada võimalikult palju tööandmestikku
innodb_buffer_pool_size = <Määra 70% kogu RAM-ist>

# Suurenda logifaili suurust, et vältida agressiivset kontrollimist
innodb_log_file_size = 2G

# Keela doublewrite-puhver (riskantne tootmises, ohutu esmasel laadimisel)
innodb_doublewrite = 0

Märkus: Taastage alati need sätted nende ACID-ühilduvate vaikeväärtuste juurde (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) ja taaskäivitage MySQL-i teenus enne tootmisliikluse lubamist.

Varukoopiate automatiseerimine ja turvamine CloudSave’iga

Kuigi tööriistad nagu Percona XtraBackup lahendavad andmete tõhusa ekstraktimise mehaanika, nõuab tõeline ettevõtte katastroofi taastamise strateegia orkestreerimist, turvalist välist salvestusruumi ja elutsükli haldust. Kohandatud bash-skriptidele ja cron-töödele tuginemine füüsiliste varukoopiate haldamiseks toob kaasa suure vaikivate tõrgete ja nõuetele mittevastavuse riski.

Siin muutub kriitiliseks oma andmebaasikihi integreerimine ettevõtte platvormiga nagu CloudSave.

CloudSave ületab lõhe toorete andmebaasiutiliitide ja ettevõtte nõuete vahel. Kasutades CloudSave’i pre- ja post-skriptimise võimalusi, saavad DevOps-meeskonnad käivitada XtraBackupi, et luua järjepidev füüsiline hetktõmmis. CloudSave seejärel sujuvalt neelab varundusvoo, rakendab AES-256 krüpteerimise ja deduplikeerib andmed enne nende replikeerimist muutumatusse pilvesalvestusse.

See arhitektuur tagab, et:
1. Tootmise jõudlus on säilitatud: Varukoopiad töötavad salvestusseadme kiirusel ilma InnoDB puhverbasseini reostamata.
2. Ransomware kaitse: CloudSave’i muutumatud salvestuspoliitikad takistavad pahatahtlikel osalistel teie andmebaasiarhiive kustutamast või krüpteerimast.
3. Automatiseeritud säilitamine: GFS (Grandfather-Father-Son) säilitamispoliitikaid hallatakse automaatselt, tagades vastavuse andmete suveräänsuse ja auditeerimise nõuetele.
4. Prognoositav RTO: Kuna CloudSave haldab füüsiliste failide arhiive, saab mitme terabaidise andmebaasi taastamist uude instantsi kiiresti orkestreerida, saavutades ranged RTO-eesmärgid.

Kokkuvõte

mysqldump-i kasutamise jätkamine suuremahuliste andmebaaside jaoks on hasartmäng teie organisatsiooni tööaja ja andmete terviklikkusega. Ühelõimelisus, puhverbasseini reostus ja katastroofilised taastamisajad muudavad selle põhimõtteliselt sobimatuks kaasaegsetesse, suure läbilaskevõimega keskkondadesse.

Üleminekuga füüsilistele varukoopiatele, kasutades tööriistu nagu Percona XtraBackup, ning orkestreerides elutsüklit, krüpteerimist ja välist replikatsiooni läbi tugeva platvormi nagu CloudSave, muudate oma andmebaasi varundamise strateegia haprast kohustusest vastupidavaks, ettevõtte tasemel varaks. Hinnake oma praeguseid RTO ja RPO mõõdikuid juba täna – kui taastamine võtab kauem aega, kui teie ettevõte saab endale lubada võrguühenduseta olemist, on aeg mysqldump seljataha jätta.

Rubriigid