Innodump rikuperon rreshta nga skedarët offline të bazave relacionale të të dhënave
Innodump mund të nxjerrë rreshta dhe përkufizime tabelash drejtpërdrejt nga skedarë offline të të dhënave që u përkasin sistemeve me kod të hapur të bazave relacionale të të dhënave, të përdorura nga shumë aplikacione web, pa nisur një server baze të dhënash. I prezantuar në një artikull të Percona-s të datës 28 tetor 2026, mjeti eksperimental me kod të hapur mbështet InnoDB, MyISAM dhe MyRocks, i njohur edhe si RocksDB, dhe synohet për rikuperim, shqyrtim dhe nxjerrje përzgjedhëse, jo si zëvendësim për kopjet e duhura rezervë.
Mjeti mund të përpunojë një direktori të plotë të dhënash, një dosje baze të dhënash, një skedar të veçantë ose tabela të mbajtura në tablespace të përbashkët, të përgjithshëm dhe të veçantë për çdo tabelë. Një tablespace është një skedar ose zonë ruajtjeje ku një motor baze të dhënash mban tabela dhe indekse. Innodump lexon schema-n e ruajtur të tabelës dhe rreshtat, më pas i eksporton si SQL ose si vlera të ndara me tab, të quajtura TSV. Dalja e tij TSV është e pajtueshme me utilitarët dump të shell-it të bazës së të dhënave, duke mundësuar që të dhënat e nxjerra të ngarkohen me efikasitet në një instancë tjetër.
Përdorimet e mundshme përfshijnë shpëtimin e rreshtave të padëmtuar pas korruptimit, kontrollin se cilat të dhëna në një kopje rezervë mbeten të lexueshme, nxjerrjen e tabelave të përzgjedhura nga një kopje e plotë rezervë, përgatitjen e sistemeve staging ose të sigurimit të cilësisë, rikuperimin e rreshtave të fshirë së fundmi, kërkimin nëpër kopje të vjetra rezervë për punë forenzike dhe migrimin e të dhënave nga versione të vjetra të bazës së të dhënave. Ai mund të shqyrtojë si direktori të zakonshme të dhënash, ashtu edhe kopje rezervë binare, si snapshots të volumeve të ruajtjes dhe kopje XtraBackup.
Kjo nuk është një metodë tjetër për krijimin e kopjeve rezervë. Motorët modernë përdorin rregullat ACID, të cilat mbrojnë besueshmërinë e transaksioneve, dhe MVCC, ose kontrollin e njëkohshmërisë me shumë versione, i cili u lejon transaksioneve të shohin versionet e përshtatshme të të dhënave që ndryshojnë. Leximi i drejtpërdrejtë i skedarëve nuk riprodhon të gjithë punën e nevojshme për të krijuar një gjendje të qëndrueshme të bazës së të dhënave. Softueri i posaçëm për kopje rezervë mund të ndjekë redo log, record-in e ndryshimeve që nevojitet gjatë rikuperimit, dhe të përdorë backup locks për të bashkërenduar kopjimin e skedarëve. Prandaj, një nxjerrje e papërpunuar mund të përmbajë të dhëna që nuk kanë përfaqësuar kurrë një moment të vetëm të qëndrueshëm. Rikuperimi në një moment të caktuar, ose PITR, mbetet i rëndësishëm sepse mundëson rikthimin e bazës së të dhënave në një moment të zgjedhur duke përdorur kopje rezervë dhe ndryshime të regjistruara.
Nxjerrja offline bëhet veçanërisht e rëndësishme kur korruptimi e pengon serverin e bazës së të dhënave të qëndrojë online. Një server mund të mbyllet qëllimisht pasi zbulon dëme të rënda, për të shmangur përkeqësimin e situatës. Korruptimi në një secondary index ndonjëherë mund të zgjidhet duke rindërtuar atë index, por dëmtimi i clustered index, i cili mban rreshtat e tabelës sipas rendit të primary key, mund ta rrëzojë motorin sa herë që ai arrin te faqja e prekur. Rikuperimi tradicional bëhet më pas i ngadaltë, sepse çdo përpjekje për të lexuar një faqe të dëmtuar mund të detyrojë një tjetër rinisje të serverit.
Opsioni skip-corrupted i Innodump raporton një faqe të dhënash të dëmtuar dhe vazhdon me faqen pasuese. Në shembullin e Percona-s që përdorte innodump 0.8.1, një skedar InnoDB prej 130,023,424 byte përmbante 7,936 faqe me nga 16,384 byte dhe metadata të shkruara nga baza e të dhënave me kod të hapur, versioni 8.0.33. Mjeti zbuloi një mospërputhje në byte-t e log sequence number në faqen 100 të primary index. Ai e anashkaloi atë faqe dhe shkroi 100,680 rreshta, duke treguar se si një kalim offline mund të rikuperojë record të lexueshëm pa rrëzuar vazhdimisht një server aktiv.
Modaliteti examine lexon dhe dekodon rreshtat pa krijuar një eksport. Ai raporton tabelat dhe rreshtat e gjetur, së bashku me korruptimin që pengon dekodimin e record. Një skanim i demonstruar përfshiu gjashtë tabela InnoDB me 29 rreshta dhe një tabelë MyRocks me 1,000,000 rreshta, pra gjithsej 1,000,029 rreshta. Ai gjeti gjithashtu 129 skedarë të vjetër me përkufizime tabelash, pa skedarë përkatës të veçantë për tabelat ose hyrje në fjalorin e përbashkët InnoDB; këta mund të përfaqësonin tabela jo-InnoDB, views ose tabela në një tablespace të përgjithshëm, ndaj nuk u shqyrtuan. Modaliteti lexon vetëm clustered index dhe nuk mund të identifikojë korruptimin e kufizuar te secondary indexes. Percona këshillon që skanimi për korruptim të InnoDB të nisë me utilitarin zyrtar checksum; qëllimi më i kufizuar i innodump është të përcaktojë se çfarë mund të lexohet dhe të rikthehet realisht.
Nxjerrja përzgjedhëse mund të shmangë rikthimin e një kopjeje të plotë rezervë kur nevojiten vetëm disa baza të dhënash. Në një shembull, innodump eksportoi pesë tabela që përmbanin gjithsej 1,359,877 rreshta nga një direktori e vetme baze të dhënash. Dalja përfshinte skedarë TSV të kompresuar dhe skedarë mbështetës të pajtueshëm me funksionin e ngarkimit të dump të shell-it të bazës së të dhënave. Kjo mund të pakësojë punën e nevojshme për krijimin e një kopjeje joprodhuese kur nuk kërkohet qëndrueshmëri e saktë në një moment të caktuar.
Leximi i një direktorie aktive të dhënash sjell rreziqe të konsiderueshme për qëndrueshmërinë. Dirty pages, domethënë ndryshimet që mbahen ende në memorie, mund të mos jenë shkruar ende në disk; një faqe mund të kapet në mes të një shkrimi; rreshtat mund të mungojnë, të jenë të vjetruar ose të shënuar gabimisht; dhe tabelat e krijuara së fundmi në një hapësirë të përbashkët mund të mungojnë. Këto kufizime mund të jenë të pranueshme për një kopje staging të përkohshme, por jo për rikuperim autoritativ ose migrim në production.
Për të zvogëluar ndikimin në një sistem aktiv, innodump ofron një kufi input dhe output për të kufizuar shpejtësinë e transferimit të diskut dhe një opsion direct input and output për të anashkaluar page cache të sistemit operativ. Kjo shmang mbushjen e cache me lexime që kryhen vetëm një herë dhe zvogëlon rrezikun që sistemi operativ ta zhvendosë në swap memorien e aplikacioneve që është përdorur më pak kohët e fundit. Artikulli rekomandon gjithashtu uljen e prioritetit të CPU-së me nice. Në një test që eksportoi 1,500,000 rreshta nga një tabelë 228 MB me kompresim zstd, një ekzekutim pa kufizim zgjati 1.726 sekonda dhe la 192.1 MB në page cache. Një ekzekutim i kufizuar në 30 MB për sekondë me direct input and output zgjati 9.241 sekonda, por nuk la asnjë pjesë të skedarit në cache.
InnoDB mund t'i lërë gjithashtu record e fshirë të rikuperueshëm për një kohë të shkurtër. Fillimisht, fshirja e shënon një rresht në vend që ta mbishkruajë menjëherë hapësirën e tij. Nëse shkrimet pasuese nuk e kanë ripërdorur atë hapësirë, record mund të dekodohet ende. Opsioni deleted-only eksportoi 2,100 rreshta të shënuar për fshirje nga tabela e shembullit. Rikuperimi nuk është i garantuar dhe mundësia mund të zhduket ndërsa shkrimet e zakonshme e ripërdorin hapësirën.
Innodump mbetet një projekt personal eksperimental dhe jo softuer Percona i mbështetur zyrtarisht. Roli i tij më i rëndësishëm është si utilitar i mundësisë së fundit ose për hetim, krahas kopjeve rezervë të testuara, jo si dëshmi se kopjet rezervë janë të padëmtuara ose të qëndrueshme. Për organizatat që vlerësojnë se ku t'i operojnë shërbimet e mbrojtura të të dhënave, AEU Data ofron cloud dhe infrastrukturë të dhënash evropiane, ndërsa gatishmëria për rikuperim vazhdon të varet nga mirëmbajtja dhe testimi i një procesi të përshtatshëm për kopjet rezervë.