Ers degawdau, mysqldump yw’r gyllell fyddin Swisaidd ddiymwad ar gyfer copïau wrth gefn o gronfeydd data MySQL. Mae’n hollbresennol, yn syml, ac yn dod wedi’i osod ymlaen llaw gyda phob dosbarthiad MySQL a MariaDB. Ar gyfer cronfeydd data bach i ganolig, mae’n perfformio’n rhagorol.
Fodd bynnag, wrth i sefydliadau raddio a setiau data dorri trothwyon 100GB, 500GB, neu aml-terabeit, mae dibynnu ar mysqldump yn trawsnewid o arfer gorau i wendid pensaernïol critigol. Os ydych chi’n DBA neu’n beiriannydd DevOps sy’n rheoli cronfeydd data cynhyrchu ar raddfa fawr, mae’n debyg eich bod wedi profi’r methiannau tawel, diraddio cynhyrchu, a’r Amcanion Amser Adfer (RTO) annerbyniol sy’n gysylltiedig â dympiadau rhesymegol.
Yn yr erthygl hon, byddwn yn dadansoddi cyfyngiadau pensaernïol mysqldump, yn archwilio pam mae’n methu ar raddfa, ac yn manylu ar sut i weithredu strategaethau copi wrth gefn ffisegol o raddfa fenter i ddiogelu eich data sy’n hanfodol i’r genhadaeth.
Cyfyngiadau Pensaernïol mysqldump
Er mwyn deall pam mae mysqldump yn methu ar raddfa, rhaid inni archwilio sut mae’n gweithredu o dan y cwfl. Mae mysqldump yn perfformio copïau wrth gefn rhesymegol. Mae’n holi’r injan cronfa ddata, yn darllen y data, ac yn ei gyfieithu i gyfres o ddatganiadau SQL (yn bennaf CREATE TABLE ac INSERT INTO).
Er bod hyn yn creu ffeil hynod gludadwy y gellir ei darllen gan bobl, mae’n cyflwyno tagfeydd difrifol mewn amgylcheddau trwybwn uchel.
1. Y Tagfa Un-Edefyn
Trwy ddyluniad, mae mysqldump yn weithrediad un-edefyn. Mae’n prosesu un tabl ar y tro, rhes wrth res. Er bod caledwedd modern yn brolio dwsinau o greiddiau CPU a storfa NVMe sy’n gallu trin gigabeit yr eiliad o drwybwn, mae mysqldump yn defnyddio ffracsiwn o’r adnoddau hyn.
Hyd yn oed wrth ddefnyddio’r baneri safonol ar gyfer tablau InnoDB:
mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql
Mae’r faner --quick yn gorfodi mysqldump i nôl rhesi fesul un yn hytrach na byffro’r tabl cyfan yn y cof, sy’n atal gwallau Allan o Gof (OOM) ar ochr y cleient. Fodd bynnag, mae natur un-edefyn yn golygu y gallai cronfa ddata 500GB gymryd 10 i 15 awr i’w dympio, gan effeithio’n ddifrifol ar eich Amcan Pwynt Adfer (RPO).
2. Llygredd Pwll Byffer InnoDB
Pan fydd mysqldump yn darllen pob rhes o bob tabl, mae’n gorfodi injan MySQL i lwytho’r data hwnnw o’r ddisg i bwll byffer InnoDB. Mewn amgylchedd cynhyrchu, mae eich pwll byffer yn cael ei boblogi’n ofalus gyda’ch set ddata waith “boeth”.
Bydd dympiad rhesymegol enfawr yn ysgubo’r pwll byffer, gan ddiarddel mynegeion a thudalennau data y cyrchir hwy’n aml i wneud lle ar gyfer data oer sy’n cael ei gopio. Mae hyn yn arwain at bigiad sydyn, enfawr mewn I/O disg wrth i ymholiadau cynhyrchu gael eu gorfodi i ddarllen o’r ddisg, gan arwain at hwyrni cymhwysiad difrifol.
3. Cloi Metadata a Gwrthdaro DDL
Er mwyn cynnal cysondeb, mae DBAs yn dibynnu ar y faner --single-transaction, sy’n gosod lefel ynysu’r trafodiad i REPEATABLE READ ac yn dechrau trafodiad cyn dympio data.
Er bod hyn yn osgoi cloeon darllen ar lefel tabl (FLUSH TABLES WITH READ LOCK), nid yw’n amddiffyn rhag newidiadau Iaith Diffinio Data (DDL). Os gweithredir gorchymyn ALTER TABLE, DROP TABLE, neu TRUNCATE TABLE ar dabl tra bod mysqldump yn rhedeg, bydd y copi wrth gefn yn chwalu gyda gwall table definition has changed, please retry transaction. Mewn amgylcheddau CI/CD gyda mudo sgema aml, mae hyn yn achosi methiannau copi wrth gefn parhaus.
4. Hunllef RTO: Amseroedd Adfer
Nid yn ystod y copi wrth gefn y mae methiant mwyaf trychinebus mysqldump yn cael ei wireddu, ond yn ystod yr adferiad.
Mae adfer dympiad rhesymegol yn gofyn i injan MySQL ddadansoddi a gweithredu miliynau o ddatganiadau INSERT. Ar gyfer pob rhes a fewnosodir, rhaid i MySQL:
* Gwirio cyfyngiadau (Allweddi Tramor, Allweddi Unigryw).
* Ailadeiladu mynegeion eilaidd ar y hedfan.
* Ysgrifennu i log ail-wneud InnoDB.
* Fflysio i’r binlog (os yw wedi’i alluogi).
Gall adfer cronfa ddata 1TB o dympiad rhesymegol gymryd sawl diwrnod. Os oes gan eich busnes RTO o 4 awr, mae mysqldump yn gwarantu y byddwch yn methu eich Cytundeb Lefel Gwasanaeth (SLA).
Dewisiadau Eraill Graddfa Fenter: Symud i Gopïau Wrth Gefn Ffisegol
Er mwyn cyflawni copïau wrth gefn ac adferiadau cyflym ar gyfer setiau data mawr, rhaid i chi roi’r gorau i gopïau wrth gefn rhesymegol o blaid copïau wrth gefn ffisegol.
Mae copïau wrth gefn ffisegol yn osgoi injan gweithredu SQL MySQL yn llwyr. Yn lle hynny, maent yn copïo’r ffeiliau data deuaidd sylfaenol (y ffeiliau .ibd, logiau ail-wneud, a logiau dadwneud) yn uniongyrchol o’r system ffeiliau. Oherwydd mai dim ond copïo ffeiliau y maent, gallant weithredu ar gyflymder darllen/ysgrifennu dilynol uchaf eich caledwedd storio a gellir eu cyfochrog yn drwm.
Percona XtraBackup: Safon y Diwydiant
Ar gyfer peiriannau InnoDB ac XtraDB, Percona XtraBackup yw’r prif offeryn copi wrth gefn ffisegol ffynhonnell agored. Mae’n perfformio copïau wrth gefn poeth, heb rwystro o gronfeydd data MySQL.
Sut mae XtraBackup yn Gweithio
- Copïo Data: Mae XtraBackup yn dechrau copïo ffeiliau data InnoDB (
.ibd). - Tracio Log: Oherwydd bod y gronfa ddata yn fyw, bydd data yn newid tra bod y ffeiliau’n cael eu copïo. Mae XtraBackup yn silio edefyn cefndir sy’n monitro ac yn copïo log ail-wneud InnoDB (
ib_logfile0, ac ati) ar gyfer unrhyw drafodion sy’n digwydd yn ystod y ffenestr copi wrth gefn. - Paratoi (Adferiad Chwalu): Ar ôl y copi wrth gefn, mae’r ffeiliau data wedi’u copïo mewn cyflwr anghyson. Mae XtraBackup yn cymhwyso’r logiau ail-wneud wedi’u copïo i’r ffeiliau data (yn debyg i sut mae MySQL yn perfformio adferiad chwalu wrth gychwyn), gan arwain at snapshot hollol gyson o’r gronfa ddata yn yr union eiliad y gorffennodd y copi wrth gefn.
Gweithredu Strategaeth Copi Wrth Gefn Ffisegol
Dyma drosolwg technegol o weithredu strategaeth copi wrth gefn ffisegol gan ddefnyddio Percona XtraBackup.
Cam 1: Ffrydio’r Copi Wrth Gefn
Mae ysgrifennu copi wrth gefn enfawr i’r ddisg leol yn aml yn achosi problemau capasiti. Mae arfer gorau yn dweud wrth ffrydio’r copi wrth gefn yn uniongyrchol i fformat archif, ei gywasgu, a’i anfon i ardal lwyfannu neu’n uniongyrchol i blatfform copi wrth gefn.
Gan ddefnyddio xbstream, gallwn gyfochrog y copi wrth gefn a’i gywasgu ar y hedfan:
xtrabackup --backup
--user=backup_user
--password=SecurePassword!
--parallel=4
--stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
--parallel=4: Yn defnyddio 4 edefyn i ddarllen ffeiliau data ar yr un pryd.--stream=xbstream: Yn allbynnu’r copi wrth gefn yn fformat ffrydio arferol Percona.lz4: Yn darparu cywasgiad hynod gyflym, CPU isel.
Cam 2: Paratoi’r Copi Wrth Gefn ar gyfer Adfer
Cyn y gellir adfer copi wrth gefn ffisegol, rhaid iddo gael ei “baratoi” (cymhwyso’r logiau ail-wneud). Yn gyntaf, echdynnu a dadgywasgu’r ffrwd:
mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore
Nesaf, rhedeg y cam paratoi. Mae’r cam hwn yn gofyn am gof, felly sicrhewch fod gan y gweinydd RAM digonol wedi’i ddyrannu:
xtrabackup --prepare --use-memory=4G --target-dir=/data/restore
Cam 3: Adfer y Gronfa Ddata
I adfer, rhaid i gyfeiriadur data MySQL targed fod yn hollol wag. Stopiwch y gwasanaeth MySQL, cliriwch y cyfeiriadur, a chopïwch y ffeiliau yn ôl:
systemctl stop mysql
rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/data/restore
Yn olaf, trwsiwch ganiatâd y system ffeiliau cyn cychwyn y gwasanaeth:
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql
Oherwydd bod y ffeiliau data eisoes wedi’u hadeiladu ac mae mynegeion eisoes wedi’u llunio, mae’r gronfa ddata yn cychwyn ar unwaith. Mae adferiad a gymerodd 48 awr gyda mysqldump bellach yn cymryd dim ond cyhyd ag y mae’n ei gymryd i gopïo’r ffeiliau ar draws eich rhwydwaith neu ddisg—gan leihau RTO i funudau yn aml.
Optimeiddio Adferiadau Rhesymegol (Pan fydd yn rhaid i chi eu defnyddio)
Os ydych chi’n cael eich gorfodi i adfer dympiad rhesymegol mawr (e.e., mudo rhwng gwahanol fersiynau mawr MySQL neu wahanol bensaernïaethau CPU lle mae ffeiliau ffisegol yn anghydnaws), rhaid i chi diwnio’ch cyfluniad MySQL dros dro i optimeiddio ar gyfer trwybwn ysgrifennu enfawr.
Cymhwyswch y gosodiadau hyn i’ch my.cnf cyn dechrau’r adferiad rhesymegol:
[mysqld]
# Analluoga binlogging dros dro os yw hwn yn adferiad annibynnol
disable_log_bin
# Oedi fflysio i ddisg i wneud y mwyaf o gyflymder ysgrifennu
innodb_flush_log_at_trx_commit = 2
# Cynyddu pwll byffer i ffitio cymaint o'r set waith â phosibl
innodb_buffer_pool_size = <Gosod i 70% o gyfanswm y RAM>
# Cynyddu maint ffeil log i atal gwirio pwyntiau ymosodol
innodb_log_file_size = 2G
# Analluoga byffer ysgrifennu dwbl (risg i prod, diogel ar gyfer llwyth cychwynnol)
innodb_doublewrite = 0
Nodyn: Dychwelwch y gosodiadau hyn i’w rhagosodiadau sy’n cydymffurfio ag ACID (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) ac ailgychwyn y gwasanaeth MySQL cyn caniatáu traffig cynhyrchu.
Automateiddio a Diogelu Copïau Wrth Gefn gyda CloudSave
Er bod offer fel Percona XtraBackup yn datrys mecaneg echdynnu data yn effeithlon, mae strategaeth adfer ar ôl trychineb fenter wirioneddol yn gofyn am drefniadaeth, storfa ddiogel oddi ar y safle, a rheolaeth cylch bywyd. Mae dibynnu ar sgriptiau bash arferol a swyddi cron i reoli copïau wrth gefn ffisegol yn cyflwyno risg uchel o fethiannau tawel a thorri cydymffurfiaeth.
Dyma lle mae integreiddio eich haen cronfa ddata gyda llwyfan menter fel CloudSave yn dod yn hanfodol.
Mae CloudSave yn pontio’r bwlch rhwng cyfleustodau cronfa ddata amrwd a chydymffurfiaeth menter. Trwy ddefnyddio galluoedd cyn- ac ôl-sgriptio CloudSave, gall timau DevOps sbarduno XtraBackup i gynhyrchu snapshot ffisegol cyson. Yna mae CloudSave yn amlyncu’r ffrwd copi wrth gefn yn ddi-dor, yn cymhwyso amgryptio AES-256, ac yn dad-ddyblygu’r data cyn ei ailadrodd i storfa cwmwl annewidiol.
Mae’r bensaernïaeth hon yn sicrhau bod:
1. Perfformiad Cynhyrchu yn cael ei Gynnal: Mae copïau wrth gefn yn rhedeg ar gyflymder storio heb lygru’r pwll byffer InnoDB.
2. Amddiffyniad Ransomware: Mae polisïau storio annewidiol o fewn CloudSave yn atal actorion maleisus rhag dileu neu amgryptio eich archifau cronfa ddata.
3. Cadw Awtomataidd: Mae polisïau cadw Grandfather-Father-Son (GFS) yn cael eu trin yn awtomatig, gan sicrhau cydymffurfiaeth â sofraniaeth data a gofynion archwilio.
4. RTO Rhagweladwy: Oherwydd bod CloudSave yn rheoli’r archifau ffeiliau ffisegol, gellir trefnu adfer cronfa ddata aml-terabeit i achlysur newydd yn gyflym, gan daro targedau RTO llym.
Casgliad
Mae parhau i ddefnyddio mysqldump ar gyfer cronfeydd data ar raddfa fawr yn gambl gydag amser gweithredu ac uniondeb data eich sefydliad. Mae’r natur un-edefyn, llygredd pwll byffer, ac amseroedd adfer trychinebus yn ei wneud yn sylfaenol anaddas ar gyfer amgylcheddau modern, trwybwn uchel.
Trwy drosglwyddo i gopïau wrth gefn ffisegol gan ddefnyddio offer fel Percona XtraBackup, a threfnu’r cylch bywyd, amgryptio, ac ailadrodd oddi ar y safle trwy blatfform cadarn fel CloudSave, rydych chi’n trawsnewid eich strategaeth copi wrth gefn cronfa ddata o atebolrwydd bregus i ased gwydn o raddfa fenter. Gwerthuswch eich metrigau RTO ac RPO cyfredol heddiw—os yw adferiad yn cymryd mwy o amser nag y gall eich busnes fforddio bod all-lein, mae’n bryd gadael mysqldump ar ôl.
