Why mysqldump Fails Large MySQL Databases & How to Fix It

Տասնամյակներ շարունակ mysqldump-ը եղել է MySQL տվյալների բազայի պահուստային պատճենների ստեղծման անվիճելի «շվեյցարական դանակը»։ Այն ամենուր է, պարզ է և նախապես տեղադրված է MySQL-ի և MariaDB-ի յուրաքանչյուր բաշխման մեջ։ Փոքր և միջին չափի տվյալների բազաների համար այն հիանալի է աշխատում։

Այնուամենայնիվ, երբ կազմակերպությունները մեծանում են, և տվյալների ծավալը գերազանցում է 100 ԳԲ, 500 ԳԲ կամ մի քանի տերաբայթի սահմանը, mysqldump-ի վրա հույս դնելը լավագույն փորձից վերածվում է ճարտարապետական լուրջ խոցելիության։ Եթե դուք DBA կամ DevOps ինժեներ եք, որը կառավարում է լայնածավալ արտադրական տվյալների բազաներ, հավանաբար բախվել եք լռելյայն ձախողումների, արտադրողականության անկման և տրամաբանական դամփերի (logical dumps) հետ կապված անընդունելի Վերականգնման ժամանակային նպատակների (RTO) հետ:

Այս հոդվածում մենք կվերլուծենք mysqldump-ի ճարտարապետական սահմանափակումները, կուսումնասիրենք, թե ինչու է այն ձախողվում մասշտաբային աշխատանքների ժամանակ, և մանրամասն կներկայացնենք, թե ինչպես իրականացնել ձեռնարկատիրական մակարդակի ֆիզիկական պահուստավորման ռազմավարություններ՝ ձեր կարևորագույն տվյալները պաշտպանելու համար:

mysqldump-ի ճարտարապետական սահմանափակումները

Հասկանալու համար, թե ինչու է mysqldump-ը ձախողվում մասշտաբային աշխատանքների ժամանակ, մենք պետք է քննենք, թե ինչպես է այն աշխատում «կափարիչի տակ»։ mysqldump-ը կատարում է տրամաբանական պահուստավորում։ Այն հարցումներ է ուղարկում տվյալների բազայի շարժիչին, կարդում է տվյալները և դրանք վերածում SQL հրամանների շարքի (հիմնականում CREATE TABLE և INSERT INTO):

Թեև սա ստեղծում է բարձր շարժունակ և մարդու կողմից ընթեռնելի ֆայլ, այն լուրջ խոչընդոտներ է ստեղծում բարձր թողունակություն ունեցող միջավայրերում:

1. Միաթելային (Single-Threaded) խոչընդոտը

Իր նախագծմամբ՝ mysqldump-ը միաթելային գործողություն է։ Այն մշակում է մեկ աղյուսակ՝ տող առ տող։ Մինչ ժամանակակից սարքավորումները պարծենում են տասնյակ CPU միջուկներով և NVMe պահեստներով, որոնք ունակ են վայրկյանում գիգաբայթերով թողունակության, mysqldump-ն օգտագործում է այդ ռեսուրսների մի փոքր մասը միայն:

Նույնիսկ InnoDB աղյուսակների համար ստանդարտ դրոշակներ օգտագործելիս՝

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

--quick դրոշակը ստիպում է mysqldump-ին տողերը ստանալ մեկ առ մեկ՝ փոխանակ ամբողջ աղյուսակը հիշողության մեջ պահելու, ինչը կանխում է հաճախորդի կողմում հիշողության սպառման (OOM) սխալները: Այնուամենայնիվ, միաթելային բնույթը նշանակում է, որ 500 ԳԲ տվյալների բազան կարող է 10-ից 15 ժամ պահանջել դամփ անելու համար, ինչը լրջորեն ազդում է ձեր Վերականգնման կետի նպատակի (RPO) վրա:

2. InnoDB բուֆերային լողավազանի աղտոտում

Երբ mysqldump-ը կարդում է յուրաքանչյուր աղյուսակի յուրաքանչյուր տող, այն ստիպում է MySQL շարժիչին այդ տվյալները սկավառակից բեռնել InnoDB բուֆերային լողավազան (buffer pool): Արտադրական միջավայրում ձեր բուֆերային լողավազանը խնամքով լցված է ձեր «թեժ» աշխատանքային տվյալներով:

Հսկայական տրամաբանական դամփը կմաքրի բուֆերային լողավազանը՝ հեռացնելով հաճախակի օգտագործվող ինդեքսները և տվյալների էջերը՝ «սառը» տվյալների համար տեղ բացելու նպատակով: Սա հանգեցնում է սկավառակի I/O-ի հանկարծակի, զանգվածային աճի, քանի որ արտադրական հարցումները ստիպված են լինում կարդալ սկավառակից, ինչը հանգեցնում է հավելվածի լուրջ դանդաղման:

3. Մետատվյալների կողպեքներ և DDL կոնֆլիկտներ

Հետևողականությունը պահպանելու համար DBA-ները հույսը դնում են --single-transaction դրոշակի վրա, որը սահմանում է գործարքների մեկուսացման մակարդակը REPEATABLE READ և սկսում է գործարք՝ նախքան տվյալները դամփ անելը:

Թեև սա խուսափում է աղյուսակի մակարդակի ընթերցման կողպեքներից (FLUSH TABLES WITH READ LOCK), այն չի պաշտպանում տվյալների սահմանման լեզվի (DDL) փոփոխություններից: Եթե ALTER TABLE, DROP TABLE կամ TRUNCATE TABLE հրամանը կատարվի աղյուսակի վրա, մինչ mysqldump-ն աշխատում է, պահուստային պատճենը կխափանվի table definition has changed, please retry transaction սխալով: CI/CD միջավայրերում, որտեղ հաճախակի են սխեմայի միգրացիաները, սա առաջացնում է պահուստավորման մշտական ձախողումներ:

4. RTO մղձավանջ. Վերականգնման ժամանակը

mysqldump-ի ամենաաղետալի ձախողումը տեղի է ունենում ոչ թե պահուստավորման, այլ վերականգնման ժամանակ:

Տրամաբանական դամփի վերականգնումը պահանջում է, որ MySQL շարժիչը վերլուծի և կատարի միլիոնավոր INSERT հրամաններ: Յուրաքանչյուր ներմուծված տողի համար MySQL-ը պետք է.
* Ստուգի սահմանափակումները (Օտար բանալիներ, Եզակի բանալիներ):
* Ընթացքում վերակառուցի երկրորդային ինդեքսները:
* Գրի InnoDB redo log-ում:
* Դատարկի binlog-ը (եթե միացված է):

1 ՏԲ տվյալների բազայի վերականգնումը տրամաբանական դամփից կարող է տևել մի քանի օր: Եթե ձեր բիզնեսի RTO-ն 4 ժամ է, mysqldump-ը երաշխավորում է, որ դուք կխախտեք ձեր Ծառայության մակարդակի համաձայնագիրը (SLA):

Ձեռնարկատիրական մակարդակի այլընտրանքներ. Անցում ֆիզիկական պահուստավորման

Մեծ տվյալների հավաքածուների համար արագ պահուստավորման և վերականգնման հասնելու համար դուք պետք է հրաժարվեք տրամաբանական պահուստավորումից՝ հօգուտ ֆիզիկական պահուստավորման:

Ֆիզիկական պահուստավորումը ամբողջությամբ շրջանցում է MySQL SQL կատարման շարժիչը: Փոխարենը, դրանք ուղղակիորեն ֆայլային համակարգից պատճենում են հիմքում ընկած երկուական տվյալների ֆայլերը (.ibd ֆայլերը, redo logs և undo logs): Քանի որ դրանք պարզապես պատճենում են ֆայլերը, դրանք կարող են աշխատել ձեր պահեստային սարքավորման առավելագույն հաջորդական ընթերցման/գրման արագությամբ և կարող են մեծապես զուգահեռացվել:

Percona XtraBackup. Արդյունաբերական ստանդարտ

InnoDB և XtraDB շարժիչների համար Percona XtraBackup-ը առաջատար բաց կոդով ֆիզիկական պահուստավորման գործիքն է: Այն կատարում է MySQL տվյալների բազաների թեժ, չարգելափակող պահուստավորում:

Ինչպես է աշխատում XtraBackup-ը

Տվյալների պատճենում. XtraBackup-ը սկսում է պատճենել InnoDB տվյալների ֆայլերը (.ibd):
Լոգերի հետևում. Քանի որ տվյալների բազան ակտիվ է, ֆայլերը պատճենելու ընթացքում տվյալները կփոխվեն: XtraBackup-ը գործարկում է ֆոնային թել, որը վերահսկում և պատճենում է InnoDB redo log-ը (ib_logfile0 և այլն) պահուստավորման պատուհանի ընթացքում տեղի ունեցող ցանկացած գործարքի համար:
Պատրաստում (Վթարային վերականգնում). Պահուստավորումից հետո պատճենված տվյալների ֆայլերը գտնվում են անհամապատասխան վիճակում: XtraBackup-ը պատճենված redo log-երը կիրառում է տվյալների ֆայլերի վրա (նման այն բանին, թե ինչպես է MySQL-ը կատարում վթարային վերականգնում գործարկման ժամանակ), ինչը հանգեցնում է տվյալների բազայի կատարյալ հետևողական պատկերի (snapshot) պահուստավորման ավարտի պահին:

Ֆիզիկական պահուստավորման ռազմավարության իրականացում

Ահա Percona XtraBackup-ի միջոցով ֆիզիկական պահուստավորման ռազմավարության իրականացման տեխնիկական ուղեցույցը:

Քայլ 1. Պահուստավորման հոսքային փոխանցում (Streaming)

Հսկայական պահուստային պատճենը տեղական սկավառակի վրա գրելը հաճախ առաջացնում է տարողունակության խնդիրներ: Լավագույն փորձը թելադրում է պահուստային պատճենը ուղղակիորեն հոսքով փոխանցել արխիվային ձևաչափի, սեղմել այն և ուղարկել այն պահեստային տարածք կամ անմիջապես պահուստավորման հարթակ:

Օգտագործելով xbstream-ը՝ մենք կարող ենք զուգահեռացնել պահուստավորումը և սեղմել այն ընթացքում.

xtrabackup --backup 
  --user=backup_user 
  --password=SecurePassword! 
  --parallel=4 
  --stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4

--parallel=4. Օգտագործում է 4 թել՝ տվյալների ֆայլերը միաժամանակ կարդալու համար:
--stream=xbstream. Արտածում է պահուստային պատճենը Percona-ի հատուկ հոսքային ձևաչափով:
lz4. Ապահովում է չափազանց արագ, ցածր CPU սպառմամբ սեղմում:

Քայլ 2. Պահուստային պատճենի պատրաստում վերականգնման համար

Նախքան ֆիզիկական պահուստային պատճենը կարող է վերականգնվել, այն պետք է «պատրաստվի» (կիրառելով redo log-երը): Նախ, հանեք և ապասեղմեք հոսքը.

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

Հաջորդը, գործարկեք պատրաստման փուլը: Այս քայլը պահանջում է հիշողություն, ուստի համոզվեք, որ սերվերն ունի բավարար RAM հատկացված.

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

Քայլ 3. Տվյալների բազայի վերականգնում

Վերականգնելու համար թիրախային MySQL տվյալների գրացուցակը պետք է լինի ամբողջությամբ դատարկ: Կանգնեցրեք MySQL ծառայությունը, մաքրեք գրացուցակը և պատճենեք ֆայլերը հետ.

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

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

Վերջապես, ծառայությունը գործարկելուց առաջ ուղղեք ֆայլային համակարգի թույլտվությունները.

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

Քանի որ տվյալների ֆայլերն արդեն կառուցված են, իսկ ինդեքսներն արդեն կազմված են, տվյալների բազան անմիջապես սկսում է աշխատել: Վերականգնումը, որը mysqldump-ի դեպքում տևում էր 48 ժամ, այժմ տևում է այնքան, որքան ժամանակ պահանջվում է ֆայլերը ձեր ցանցով կամ սկավառակով պատճենելու համար՝ հաճախ RTO-ն կրճատելով մինչև րոպեներ:

Տրամաբանական վերականգնումների օպտիմալացում (Երբ ստիպված եք օգտագործել դրանք)

Եթե դուք ստիպված եք վերականգնել հսկայական տրամաբանական դամփ (օրինակ՝ MySQL-ի տարբեր հիմնական տարբերակների կամ տարբեր CPU ճարտարապետությունների միջև միգրացիայի ժամանակ, որտեղ ֆիզիկական ֆայլերը անհամատեղելի են), դուք պետք է ժամանակավորապես կարգավորեք ձեր MySQL կոնֆիգուրացիան՝ զանգվածային գրման թողունակության համար օպտիմալացնելու նպատակով:

Կիրառեք այս կարգավորումները ձեր my.cnf-ում՝ նախքան տրամաբանական վերականգնումը սկսելը.

[mysqld]
# Ժամանակավորապես անջատեք binlogging-ը, եթե սա առանձին վերականգնում է
disable_log_bin

# Հետաձգեք սկավառակի վրա դատարկումը՝ գրման արագությունը առավելագույնի հասցնելու համար
innodb_flush_log_at_trx_commit = 2

# Ավելացրեք բուֆերային լողավազանը՝ աշխատանքային հավաքածուի հնարավորինս մեծ մասը տեղավորելու համար
innodb_buffer_pool_size = <Սահմանել ընդհանուր RAM-ի 70%-ը>

# Ավելացրեք լոգ ֆայլի չափը՝ ագրեսիվ ստուգումները կանխելու համար
innodb_log_file_size = 2G

# Անջատեք doublewrite բուֆերը (ռիսկային է արտադրության համար, անվտանգ է սկզբնական բեռնման համար)
innodb_doublewrite = 0

Նշում. Միշտ վերադարձրեք այս կարգավորումները դրանց ACID-համապատասխան լռելյայն արժեքներին (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) և վերագործարկեք MySQL ծառայությունը՝ նախքան արտադրական երթևեկությունը թույլ տալը:

Պահուստավորման ավտոմատացում և ապահովում CloudSave-ի միջոցով

Թեև Percona XtraBackup-ի նման գործիքները լուծում են տվյալների արդյունավետ արդյունահանման մեխանիկան, աղետներից վերականգնման իրական ձեռնարկատիրական ռազմավարությունը պահանջում է համակարգում, անվտանգ արտաքին պահեստավորում և կյանքի ցիկլի կառավարում: Ֆիզիկական պահուստավորումը կառավարելու համար հատուկ bash սկրիպտների և cron աշխատանքների վրա հույս դնելը մեծացնում է լռելյայն ձախողումների և համապատասխանության խախտումների ռիսկը:

Այստեղ է, որ ձեր տվյալների բազայի շերտը CloudSave-ի նման ձեռնարկատիրական հարթակի հետ ինտեգրելը դառնում է կարևոր:

CloudSave-ը կամրջում է տվյալների բազայի հում օգտակար ծրագրերի և ձեռնարկատիրական համապատասխանության միջև եղած բացը: Օգտագործելով CloudSave-ի նախնական և հետագա սկրիպտավորման հնարավորությունները՝ DevOps թիմերը կարող են գործարկել XtraBackup-ը՝ հետևողական ֆիզիկական պատկեր ստեղծելու համար: Այնուհետև CloudSave-ը անխափան կերպով ընդունում է պահուստային հոսքը, կիրառում է AES-256 գաղտնագրում և հեռացնում կրկնօրինակները (deduplicate)՝ նախքան այն անփոփոխ ամպային պահեստում կրկնօրինակելը:

Այս ճարտարապետությունը երաշխավորում է, որ.
1. Պահպանվում է արտադրական արտադրողականությունը. Պահուստավորումներն աշխատում են պահեստավորման արագությամբ՝ առանց InnoDB բուֆերային լողավազանը աղտոտելու:
2. Ransomware-ից պաշտպանություն. CloudSave-ի ներսում անփոփոխ պահեստավորման քաղաքականությունը կանխում է չարամիտ դերակատարներին ձեր տվյալների բազայի արխիվները ջնջելուց կամ գաղտնագրելուց:
3. Ավտոմատացված պահպանում. Պապ-Հայր-Որդի (GFS) պահպանման քաղաքականությունը կառավարվում է ավտոմատ կերպով՝ ապահովելով տվյալների ինքնիշխանության և աուդիտի պահանջների կատարումը:
4. Կանխատեսելի RTO. Քանի որ CloudSave-ը կառավարում է ֆիզիկական ֆայլերի արխիվները, բազմատերաբայթանոց տվյալների բազայի վերականգնումը նոր օրինակի վրա կարող է արագ կազմակերպվել՝ հասնելով RTO-ի խիստ թիրախներին:

Եզրակացություն

Լայնածավալ տվյալների բազաների համար mysqldump-ի օգտագործումը շարունակելը խաղադրույք է ձեր կազմակերպության աշխատունակության և տվյալների ամբողջականության հետ: Միաթելային բնույթը, բուֆերային լողավազանի աղտոտումը և վերականգնման աղետալի ժամանակները այն հիմնովին անհամապատասխան են դարձնում ժամանակակից, բարձր թողունակություն ունեցող միջավայրերի համար:

Անցնելով ֆիզիկական պահուստավորման՝ օգտագործելով Percona XtraBackup-ի նման գործիքներ և կյանքի ցիկլը, գաղտնագրումը և արտաքին կրկնօրինակումը կազմակերպելով CloudSave-ի նման հզոր հարթակի միջոցով, դուք ձեր տվյալների բազայի պահուստավորման ռազմավարությունը փխրուն պարտավորությունից վերածում եք ճկուն, ձեռնարկատիրական մակարդակի ակտիվի: Գնահատեք ձեր ընթացիկ RTO և RPO ցուցանիշները այսօր. եթե վերականգնումը տևում է ավելի երկար, քան ձեր բիզնեսը կարող է թույլ տալ անցանց լինել, ժամանակն է հրաժարվել mysqldump-ից:

Ինչու՞ է mysqldump-ը ձախողվում ձեր մեծ MySQL տվյալների բազաների դեպքում (և ինչպե՞ս շտկել այն)