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.

Олон арван жилийн турш mysqldump нь MySQL мэдээллийн сангийн нөөцлөлтөд зориулсан маргаангүй “Швейцарийн хутга” байсаар ирсэн. Энэ нь хаа сайгүй ашиглагддаг, энгийн бөгөөд MySQL болон MariaDB-ийн бүх хувилбарт урьдчилан суулгагдсан байдаг. Жижиг болон дунд хэмжээний мэдээллийн сангуудын хувьд энэ нь маш сайн ажилладаг.

Гэсэн хэдий ч байгууллагууд өргөжин тэлж, өгөгдлийн хэмжээ 100GB, 500GB эсвэл олон терабайтын босгыг давах үед mysqldump-д найдах нь шилдэг туршлага байхаа больж, архитектурын ноцтой эмзэг байдал болон хувирдаг. Хэрэв та том хэмжээний үйлдвэрлэлийн мэдээллийн сангуудыг удирддаг DBA эсвэл DevOps инженер бол логик нөөцлөлтүүдтэй холбоотой чимээгүй алдаанууд, бүтээмжийн бууралт, хүлээн зөвшөөрөгдөхгүй Сэргээх Хугацааны Зорилтууд (RTO)-ыг аль хэдийн мэдэрсэн байх магадлалтай.

Энэ нийтлэлд бид mysqldump-ийн архитектурын хязгаарлалтуудыг задлан шинжилж, яагаад энэ нь өргөтгөх боломжгүй (scale) болохыг судалж, таны бизнесийн чухал өгөгдлийг хамгаалахын тулд аж ахуйн нэгжийн түвшний физик нөөцлөлтийн стратегийг хэрхэн хэрэгжүүлэх талаар дэлгэрэнгүй авч үзэх болно.

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-ийг бүх хүснэгтийг санах ойд хадгалахын оронд мөр мөрөөр нь татаж авахад хүргэдэг бөгөөд энэ нь клиент талд Out of Memory (OOM) алдаа гарахаас сэргийлдэг. Гэсэн хэдий ч нэг урсгалттай шинж чанар нь 500GB мэдээллийн санг нөөцлөхөд 10-15 цаг зарцуулж, таны Сэргээх Цэгийн Зорилт (RPO)-д ноцтой нөлөөлж болзошгүй гэсэн үг юм.

2. InnoDB Buffer Pool-ийн бохирдол

mysqldump нь хүснэгт бүрийн мөр бүрийг унших үед MySQL хөдөлгүүрийг тухайн өгөгдлийг дискнээс InnoDB buffer pool руу ачаалахыг албаддаг. Үйлдвэрлэлийн орчинд таны buffer pool нь таны “халуун” буюу байнга ашиглагддаг өгөгдлүүдээр нарийн дүүргэгдсэн байдаг.

Асар том логик нөөцлөлт нь buffer pool-ийг бүхэлд нь цэвэрлэж, байнга ханддаг индексүүд болон өгөгдлийн хуудсуудыг гаргаж, нөөцлөгдөж буй “хүйтэн” өгөгдөлд зай гаргадаг. Энэ нь дискний I/O-ийн гэнэтийн, асар их өсөлтийг үүсгэж, үйлдвэрлэлийн асуулгууд дискнээс уншихад хүргэж, улмаар програмын ажиллагааг удаашруулдаг.

3. Мета өгөгдлийн түгжээ ба DDL зөрчил

Тогтвортой байдлыг хангахын тулд DBA-ууд --single-transaction туг дээр тулгуурладаг бөгөөд энэ нь гүйлгээний тусгаарлалтын түвшинг REPEATABLE READ болгож, өгөгдлийг нөөцлөхөөс өмнө гүйлгээг эхлүүлдэг.

Хэдийгээр энэ нь хүснэгтийн түвшний унших түгжээг (FLUSH TABLES WITH READ LOCK) үүсгэхээс зайлсхийдэг ч, Өгөгдлийн Тодорхойлолтын Хэл (DDL)-ийн өөрчлөлтүүдээс хамгаалдаггүй. Хэрэв mysqldump ажиллаж байх үед ALTER TABLE, DROP TABLE, эсвэл TRUNCATE TABLE команд гүйцэтгэгдвэл нөөцлөлт нь table definition has changed, please retry transaction гэсэн алдаатайгаар зогсдог. Схем шилжүүлэлт байнга хийгддэг CI/CD орчинд энэ нь нөөцлөлтийн тасралтгүй алдааг үүсгэдэг.

4. RTO-ийн хар дарсан зүүд: Сэргээх хугацаа

mysqldump-ийн хамгийн сүйрлийн алдаа нь нөөцлөлтийн үед биш, харин сэргээх үед илэрдэг.

Логик нөөцлөлтийг сэргээхэд MySQL хөдөлгүүр нь сая сая INSERT мэдэгдлийг задлан шинжилж, гүйцэтгэх шаардлагатай болдог. Оруулсан мөр бүрийн хувьд MySQL дараах зүйлийг хийх ёстой:
* Хязгаарлалтуудыг шалгах (Гадаад түлхүүрүүд, Өвөрмөц түлхүүрүүд).
* Хоёрдогч индексүүдийг дахин бүтээх.
* InnoDB redo log руу бичих.
* Binlog руу урсгах (хэрэв идэвхжүүлсэн бол).

1TB хэмжээтэй мэдээллийн санг логик нөөцлөлтөөс сэргээхэд хэдэн өдөр зарцуулагдаж болно. Хэрэв танай бизнесийн RTO нь 4 цаг бол mysqldump нь таны Үйлчилгээний Түвшний Гэрээ (SLA)-г зөрчих баталгаа болно.

Аж ахуйн нэгжийн түвшний хувилбарууд: Физик нөөцлөлт рүү шилжих

Том хэмжээний өгөгдлийн багцыг хурдан нөөцлөх, сэргээхийн тулд та логик нөөцлөлтийг орхиж, физик нөөцлөлт рүү шилжих ёстой.

Физик нөөцлөлт нь MySQL SQL гүйцэтгэх хөдөлгүүрийг бүрэн тойрч гардаг. Үүний оронд тэд үндсэн хоёртын өгөгдлийн файлуудыг (.ibd файлууд, redo logs, undo logs) файлын системээс шууд хуулдаг. Тэд зөвхөн файл хуулж байгаа тул таны хадгалах төхөөрөмжийн хамгийн их дараалсан унших/бичих хурдаар ажиллах боломжтой бөгөөд маш сайн зэрэгцээ горимд ажиллуулж болно.

Percona XtraBackup: Салбарын стандарт

InnoDB болон XtraDB хөдөлгүүрүүдийн хувьд Percona XtraBackup нь нээлттэй эх сурвалжтай физик нөөцлөлтийн шилдэг хэрэгсэл юм. Энэ нь MySQL мэдээллийн сангийн “халуун”, түгжээгүй нөөцлөлтийг гүйцэтгэдэг.

XtraBackup хэрхэн ажилладаг вэ?

  1. Өгөгдөл хуулах: XtraBackup нь InnoDB өгөгдлийн файлуудыг (.ibd) хуулж эхэлдэг.
  2. Бүртгэл хөтлөх: Мэдээллийн сан идэвхтэй ажиллаж байгаа тул файлуудыг хуулж байх үед өгөгдөл өөрчлөгдөнө. XtraBackup нь нөөцлөлтийн явцад үүсэх бүх гүйлгээний InnoDB redo log (ib_logfile0 гэх мэт)-ийг хянаж, хуулдаг арын урсгалыг үүсгэдэг.
  3. Бэлтгэл (Сүйрлээс сэргээх): Нөөцлөлтийн дараа хуулсан өгөгдлийн файлууд нь зөрчилтэй төлөвт байдаг. 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

# Ажиллаж буй өгөгдлийг аль болох ихээр багтаахын тулд buffer pool-ийг нэмэгдүүл
innodb_buffer_pool_size = <Нийт RAM-ийн 70% болгож тохируул>

# Түрэмгий шалгалтаас сэргийлэхийн тулд лог файлын хэмжээг нэмэгдүүл
innodb_log_file_size = 2G

# Doublewrite buffer-ийг идэвхгүй болго (үйлдвэрлэлийн хувьд эрсдэлтэй, анхны ачааллын хувьд аюулгүй)
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 шифрлэлтийг хэрэглэж, өгөгдлийг давхардалгүй болгосны дараа үл өөрчлөгдөх үүлэн хадгалах сан руу хуулбарладаг.

Энэхүү архитектур нь дараах зүйлийг баталгаажуулдаг:
1. Үйлдвэрлэлийн гүйцэтгэлийг хадгалах: Нөөцлөлтүүд нь InnoDB buffer pool-ийг бохирдуулахгүйгээр хадгалах хурдаар ажилладаг.
2. Ransomware-аас хамгаалах: CloudSave доторх үл өөрчлөгдөх хадгалах бодлого нь хортой этгээдүүдээс таны мэдээллийн сангийн архивыг устгах эсвэл шифрлэхээс сэргийлдэг.
3. Автомат хадгалалт: Grandfather-Father-Son (GFS) хадгалах бодлогыг автоматаар зохицуулж, өгөгдлийн бүрэн эрхт байдал болон аудитын шаардлагыг хангадаг.
4. Урьдчилан таамаглах боломжтой RTO: CloudSave нь физик файлын архивыг удирддаг тул олон терабайтын мэдээллийн санг шинэ жишээ рүү сэргээх ажлыг хурдан зохион байгуулж, RTO-ийн хатуу зорилтуудыг биелүүлдэг.

Дүгнэлт

Том хэмжээний мэдээллийн сангуудад mysqldump-ийг үргэлжлүүлэн ашиглах нь танай байгууллагын ажиллах хугацаа болон өгөгдлийн бүрэн бүтэн байдлыг эрсдэлд оруулж буй хэрэг юм. Нэг урсгалттай шинж чанар, buffer pool-ийн бохирдол, сэргээх хугацааны сүйрлийн урт нь үүнийг орчин үеийн, өндөр ачаалалтай орчинд үндсэндээ тохиромжгүй болгодог.

Percona XtraBackup гэх мэт хэрэгслүүдийг ашиглан физик нөөцлөлт рүү шилжиж, CloudSave гэх мэт хүчирхэг платформ ашиглан амьдралын мөчлөг, шифрлэлт, гадны хуулбарлалтыг зохион байгуулснаар та мэдээллийн сангийн нөөцлөлтийн стратегиа эмзэг сул тал биш, харин тэсвэртэй, аж ахуйн нэгжийн түвшний хөрөнгө болгон хувиргах болно. Өнөөдөр өөрийн RTO болон RPO хэмжүүрүүдээ үнэлээрэй—хэрэв сэргээлт нь танай бизнесийн офлайн байж болох хугацаанаас илүү удаан үргэлжилж байвал mysqldump-ийг орхих цаг нь болжээ.

Ангилал