Categories
Database Backup

> Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.

DevOps инженерүүд болон системийн администраторуудын хувьд виртуал машин (VM) агшин зуурын зураг (snapshot) нь үндсэн хэрэгсэл юм. Эдгээр нь эрсдэлтэй засвар (patch), тохиргооны томоохон өөрчлөлт эсвэл аппликейшн байршуулахын өмнө серверийн төлөвийг хадгалах хурдан бөгөөд тохиромжтой аргыг өгдөг. Хэрэв ямар нэг зүйл буруугаар эргэвэл, өмнөх төлөв рүү буцаахад хэдхэн секунд л хангалттай.

Гэсэн хэдий ч, энэ аргачлалыг PostgreSQL, MySQL, Oracle эсвэл Microsoft SQL Server зэрэг гүйлгээний мэдээллийн сангуудад (transactional databases) ашиглах үед VM snapshot нь аюулгүй байдлын баталгаа байхаа больж, тэсрэх бөмбөг мэт аюултай зүйл болж хувирдаг.

Мэдээллийн сангийн нөөцлөлтөд гипервизорын стандарт snapshot-д найдах нь өгөгдлийн эвдрэл, хуудасны гэмтэл (torn pages) болон сэргээх боломжгүй үйлдвэрлэлийн тасалдлын хамгийн түгээмэл шалтгаануудын нэг юм. Энэ нийтлэлд бид гипервизор болон мэдээллийн сангийн хөдөлгүүрүүдийн хоорондох архитектурын зөрчил, snapshot хийх явцад өгөгдөл эвдрэх механизм, мөн виртуалчлагдсан мэдээллийн санг аюулгүй нөөцлөхөд шаардлагатай инженерийн шилдэг туршлагуудыг судлах болно.

Архитектурын зөрчил: Гипервизор vs Мэдээллийн сангийн хөдөлгүүрүүд

VM snapshot яагаад мэдээллийн санд аюул учруулдгийг ойлгохын тулд эхлээд хоёр систем төлөв болон I/O үйлдлүүдийг хэрхэн удирддагийг авч үзэх хэрэгтэй.

Гипервизорууд хэрхэн Snapshot хийдэг вэ?

Гипервизор (VMware ESXi, Microsoft Hyper-V эсвэл KVM гэх мэт) snapshot авахдаа дискийг бүхэлд нь хуулдаггүй. Үүний оронд одоогийн виртуал дискний файлыг (жишээ нь, .vmdk эсвэл .vhdx) зөвхөн унших горимд шилжүүлж, шинэ дельта диск (ялгаатай диск) үүсгэдэг. Үүний дараах бүх бичилтийн үйлдлүүд энэ дельта диск рүү чиглэгддэг.

Snapshot-ыг устгах үед гипервизор нь дельта дискэн дээрх өгөгдлийг үндсэн диск рүү нэгтгэх (commit/consolidate) ёстой. Стандарт snapshot-ууд нь зочин үйлдлийн систем дотор ажиллаж байгаа аппликейшнуудын талаар ямар ч ойлголтгүй байдаг. Тэд дискний төлөвийг тухайн микросекундэд яг ямар байсан тэр чигээр нь л авдаг.

Гүйлгээний мэдээллийн сангууд төлөвийг хэрхэн удирддаг вэ?

Гүйлгээний мэдээллийн сангууд нь ACID (Atomicity, Consistency, Isolation, Durability) шинж чанаруудад тулгуурлан бүтээгдсэн байдаг. ACID-ийн шаардлагыг хангахын зэрэгцээ өндөр гүйцэтгэлтэй байхын тулд мэдээллийн сангууд бүх гүйлгээг дискэн дээрх үндсэн өгөгдлийн файлууд руу шууд бичдэггүй. Үүний оронд тэд нарийн төвөгтэй, олон шатлалт архитектурыг ашигладаг:

  1. Buffer Pool / Shared Buffers: Өгөгдлийг системийн санах ойд уншиж, өөрчилдөг.
  2. Write-Ahead Log (WAL) / Redo Logs: Өөрчлөлтүүдийг дискэн дээрх өндөр оновчлогдсон лог файл руу дарааллаар нь бичиж, бат бөх байдлыг хангадаг.
  3. Checkpoints / Lazy Writers: Үе үе мэдээллийн сан нь санах ойд өөрчлөгдсөн (бохирдсон) хуудсуудыг дискэн дээрх бодит өгөгдлийн файлууд руу шилжүүлдэг.

Энэхүү архитектураас шалтгаалан дискэн дээрх физик өгөгдлийн файлууд нь мэдээллийн сангийн бодит төлөвтэй бараг үргэлж зөрүүтэй байдаг. Мэдээллийн сангийн жинхэнэ төлөв нь зөвхөн дискэн дээрх өгөгдлийн файлууд, WAL/Redo логууд болон санах ойд байгаа өгөгдлүүдийн нэгдэл юм.

Аюултай бүс: VM Snapshot хийх үед юу болдог вэ?

Та мэдээллийн сангийн серверт стандарт VM snapshot хийхдээ crash-consistent (систем гэнэт унтрахад үүсэх төлөв) төлөвийг авч байна гэсэн үг.

Crash Consistency vs Application Consistency

Crash-consistent snapshot нь физик серверийн цахилгааны утсыг гэнэт сугалахтай ижил юм. Дискний төлөв хадгалагдах боловч санах ойд байсан бүх зүйл алдагдаж, хадгалах төхөөрөмж рүү илгээгдэж байсан өгөгдлүүд гэнэт тасалдана.

Орчин үеийн мэдээллийн сангууд гэнэтийн цахилгаан тасралтаас сэргэхэд зориулагдсан (Write-Ahead Log-ийг дахин тоглуулах замаар) боловч, нөөцлөлтийн үндсэн стратеги болгон үүнд найдах нь маш аюултай. Хэрэв танай мэдээллийн сан олон виртуал диск дээр тархсан бол (жишээ нь, өгөгдлийн файлууд D: диск дээр, WAL нь E: диск дээр), гипервизор хоёр дискийг яг нэг микросекундэд snapshot хийхгүй байж болно. Хэрэв WAL дискний snapshot нь өгөгдлийн дискний snapshot-оос хэдхэн секундын дараа хийгдвэл, сэргээх үед мэдээллийн сан дарааллын дугаарыг тааруулж чадахгүй бөгөөд энэ нь ноцтой эвдрэлд хүргэнэ.

Өндөр ачаалалтай системүүд дээрх “VM Stun” эффект

Snapshot үүсгэх үйл явц, түүнээс ч илүүтэйгээр snapshot-ыг нэгтгэх үйл явц нь “VM Stun” гэгддэг үзэгдлийг үүсгэдэг.

I/O-г үндсэн дискнээс дельта диск рүү аюулгүй шилжүүлэхийн тулд гипервизор нь виртуал машиныг түр зуур зогсоох (stun) ёстой. Ачаалал багатай вэб сервер дээр энэ зогсолт 10-50 миллисекунд үргэлжилж, анзаарагдахгүй өнгөрч болно. Гэвч их хэмжээний I/O-той мэдээллийн сангийн хувьд том дельта дискийг нэгтгэх нь VM-ийг хэдэн секундээр зогсоож болзошгүй.

VM stun-ийн үед:
* Сүлжээний холболтууд тасарч, аппликейшн хугацаа хэтрэх (timeout) алдаа өгнө.
* Өндөр бэлэн байдлын кластерууд (SQL Server Always On, PostgreSQL Patroni эсвэл MySQL Galera гэх мэт) зүрхний цохилтын шалгалтыг (heartbeat checks) алдана.
* Кластер нь зогссон зангилааг үхсэн гэж үзэж, шаардлагагүй бөгөөд хортой failover-ийг (split-brain хувилбар) өдөөж болзошгүй.

Хуудасны гэмтэл (Torn Pages) ба I/O-ийн нийцгүй байдал

Мэдээллийн сангийн хөдөлгүүрүүд нь өгөгдлийг ихэвчлэн тодорхой хэмжээтэй хуудсаар (жишээ нь, PostgreSQL болон SQL Server-т 8KB, InnoDB-д 16KB) бичдэг. Гэвч үйлдлийн систем болон хадгалах төхөөрөмжүүд нь I/O-г илүү жижиг блокоор (жишээ нь, 4KB эсвэл 512 байт) боловсруулдаг.

Хэрэв гипервизор мэдээллийн сан 8KB хуудсыг бичиж байх яг тэр агшинд snapshot авбал, snapshot нь шинэ өгөгдлийн эхний 4KB-ыг болон хуучин өгөгдлийн сүүлийн 4KB-ыг авч болзошгүй. Энэ нь torn page буюу гэмтсэн хуудсыг үүсгэдэг. Та snapshot-ыг сэргээхийг оролдох үед мэдээллийн сан хуудсыг уншиж, checksum баталгаажуулалт дээр алдаа гарган, мэдээллийн санг эвдэрсэн гэж тэмдэглэнэ.

Мэдээллийн сангийн тодорхой хөдөлгүүрүүдэд үзүүлэх бодит үр дагавар

Мэдээллийн сангийн өөр өөр хөдөлгүүрүүд crash-consistent snapshot-д өөр өөрөөр хариу үйлдэл үзүүлдэг боловч үйлдвэрлэлийн орчинд аль нь ч үүнийг зөв зохицуулдаггүй.

  • PostgreSQL: PostgreSQL нь pg_wal лавлахаас ихээхэн хамааралтай. Хэрэв snapshot нь өгөгдлийн лавлах ($PGDATA) болон WAL-ыг зөрүүтэй авбал, PostgreSQL ажиллаж чадахгүй бөгөөд PANIC: could not locate a valid checkpoint record гэсэн алдааг өгнө.
  • MySQL/InnoDB: InnoDB нь torn page-ээс сэргийлэхийн тулд doublewrite buffer ашигладаг бөгөөд энэ нь crash-consistent төлөвөөс тодорхой хэмжээгээр хамгаалдаг. Гэсэн хэдий ч, хэрэв ibdata1 файл болон ib_logfile нь зөрүүтэй авагдвал InnoDB хөдөлгүүр сэргээх үед унах болно.
  • Microsoft SQL Server: SQL Server нь I/O-г царцаах (freezing) ажиллагаанд маш мэдрэмтгий. VSS (Volume Shadow Copy Service)-ийн зохих интеграцчлалгүйгээр SQL Server-ийг стандарт VM snapshot-оос сэргээх нь ихэвчлэн мэдээллийн санг “сэжигтэй” (suspect) төлөвт оруулж, лог гинжийг тасалж, таны Point-in-Time Recovery (PITR) чадамжийг устгадаг.

Виртуалчлагдсан мэдээллийн санг аюулгүй нөөцлөх шилдэг туршлагууд

Гүйлгээний мэдээллийн санг хамгаалахын тулд та crash-consistent нөөцлөлтөөс application-consistent (аппликейшнд нийцтэй) нөөцлөлт рүү шилжих ёстой. Энэ нь нөөцлөх механизм нь мэдээллийн сангийн хөдөлгүүртэй харилцаж, snapshot авах үед санах ойг диск рүү бичихийг албадаж, I/O үйлдлүүдийг түр зуур зогсоохыг шаарддаг.

1. Application-Aware Quiescing (VSS болон fsfreeze) ашиглах

Windows (SQL Server)-ийн хувьд:
Таны нөөцлөлтийн шийдэл Microsoft Volume Shadow Copy Service (VSS)-ийг ашиглаж байгаа эсэхийг үргэлж шалгаарай. VSS-ийг дэмждэг нөөцлөлт эхлэхэд SQL Server VSS Writer нь мэдээллийн сангийн I/O-г царцааж, хүлээгдэж буй гүйлгээнүүдийг диск рүү бичиж, snapshot-ыг бүрэн application-consistent байхыг баталгаажуулдаг.

Linux (PostgreSQL / MySQL)-ийн хувьд:
Linux-д VSS-тэй дүйцэхүйц нэгдсэн систем байхгүй. Application consistency-д хүрэхийн тулд та гипервизорын зочин хэрэгслүүдтэй (жишээ нь, VMware Tools) хамт pre-freeze болон post-thaw скриптүүдийг ашиглах ёстой.

Энд PostgreSQL 15+ хувилбарт зориулсан VMware pre-freeze-script-ийн жишээ байна:

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Энэ скриптийг ажиллах боломжтой эсэхийг шалгана уу (chmod +x)

# 1. PostgreSQL-д нөөцлөлтөд бэлтгэхийг тушаана
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Файлын системийн буферуудыг диск рүү бичнэ
sync

# 3. Файлын системийг царцаана (өгөгдөл /var/lib/pgsql дээр байна гэж үзвэл)
fsfreeze -f /var/lib/pgsql

Мөн үйл ажиллагааг үргэлжлүүлэхэд зориулсан post-thaw-script:

#!/bin/bash
# /usr/sbin/post-thaw-script

# 1. Файлын системийг царцалтаас гаргана
fsfreeze -u /var/lib/pgsql

# 2. PostgreSQL-д нөөцлөлт дууссаныг мэдэгдэнэ
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Мэдээллийн сангийн уугуул нөөцлөлтийн хэрэгслүүдийг ашиглах

Application-consistent snapshot нь стандарт snapshot-оос дээр боловч VM stun-ийн эрсдэлийг агуулсан хэвээр байна. Мэдээллийн сангийн нөөцлөлтийн хамгийн аюулгүй арга бол гипервизороос хамааралгүй ажилладаг уугуул, стриминг нөөцлөлтийн хэрэгслүүдийг ашиглах явдал юм.

PostgreSQL (pg_basebackup):

pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P

MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Эдгээр хэрэгслүүд нь өгөгдлийн файлуудыг хуулж, redo log-ийн өөрчлөлтийг зэрэг хянах замаар ажилладаг.

mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass

SQL Server (T-SQL):

BACKUP DATABASE [ProductionDB] 
TO DISK = N'Z:BackupsProductionDB.bak' 
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO

3. Лог архивлах замаар Point-in-Time Recovery (PITR) хэрэгжүүлэх

Өдөр тутмын snapshot эсвэл бүрэн нөөцлөлт нь зөвхөн тухайн агшин хүртэлх өгөгдлийг л хамгаална. Хэрэв танай мэдээллийн сан 16:00 цагт унаж, хамгийн сүүлийн snapshot 02:00 цагт хийгдсэн бол та 14 цагийн гүйлгээний өгөгдлийг алдана.

Жинхэнэ байгууллагын түвшний тэсвэрлэх чадварт хүрэхийн тулд та бүрэн application-consistent нөөцлөлтийг тасралтгүй лог архивлахтай (WAL, Redo Logs эсвэл Transaction Logs-ийг хэдэн минут тутамд нөөцлөх) хослуулах ёстой. Энэ нь DBA-уудад мэдээллийн санг гамшгийн өмнөх тодорхой минут эсвэл бүр тодорхой гүйлгээний ID хүртэл сэргээх боломжийг олгодог.

CloudSave-тэй байгууллагын нөөцлөлтийн стратеги

Олон арван мэдээллийн сангийн серверүүд дээр тусгай pre-freeze скриптүүд, cron ажлууд болон лог дамжуулалтыг удирдах нь DevOps багуудын хувьд жинхэнэ хар дарсан зүүд юм. Энд л CloudSave шиг байгууллагын түвшний платформ чухал болдог.

CloudSave нь виртуалчлал болон мэдээллийн сангийн архитектурын хоорондох зайг нөхдөг. Гипервизорын сохор snapshot-д найдахын оронд CloudSave нь SQL Server, PostgreSQL, MySQL болон Oracle-тай уугуул байдлаар нэгддэг application-aware агентуудыг ашигладаг.

CloudSave нөөцлөлтийг эхлүүлэх үед:
1. Энэ нь уугуул API-уудаар (Windows-д зориулсан VSS эсвэл Linux-д зориулсан WAL стриминг) дамжуулан мэдээллийн сангийн хөдөлгүүртэй шууд харилцдаг.
2. Энэ нь VM-ийг зогсоохгүйгээр санах ойн буферуудыг диск рүү бичихийг зохион байгуулдаг.
3. Энэ нь өгөгдлийн файлуудыг аюулгүйгээр авч, гүйлгээний лог-ийн тайралтыг автоматаар удирддаг.
4. Энэ нь гүйлгээний логуудыг тасралтгүй нөөцөлж, хэдхэн товшилтоор Point-in-Time Recovery (PITR) хийх боломжийг олгодог.

Application consistency-ийн нарийн төвөгтэй байдлыг CloudSave-д шилжүүлснээр DBA болон системийн администраторууд үйлдвэрлэлийн кластеруудын гүйцэтгэл эсвэл бэлэн байдлыг алдагдуулахгүйгээр өгөгдлийн бүрэн бүтэн байдлыг баталгаажуулах боломжтой.

Дүгнэлт

Виртуал машин snapshot нь дэд бүтцийн удирдлагад зориулсан гайхалтай хэрэгсэл боловч тэдгээр нь гүйлгээний мэдээллийн сангийн ACID шаардлагатай үндсэндээ нийцдэггүй. Crash-consistent гипервизор snapshot-д найдах нь танай байгууллагыг torn page, тасарсан репликацийн гинж болон өгөгдлийн гамшигт алдагдалд өртөх эрсдэлд оруулдаг.

Өөрийн чухал өгөгдлийг хамгаалахын тулд та application-aware quiescing-ийг хэрэгжүүлж, мэдээллийн сангийн уугуул нөөцлөлтийн аргачлалыг ашиглаж, гүйлгээний лог-ийн тасралтгүй архивыг хадгалах ёстой. Зорилтот байгууллагын нөөцлөлтийн шийдлүүдийг нэвтрүүлснээр та мэдээллийн сангаа өндөр бэлэн байдалтай, бүрэн сэргээгдэх боломжтой, найдвартай байлгах боломжтой.

Ангилал