Bagi jurutera DevOps dan pentadbir sistem, syot kilat (snapshot) mesin maya (VM) merupakan alat asas. Ia menyediakan cara yang pantas dan mudah untuk menangkap keadaan pelayan sebelum melakukan tampalan berisiko, perubahan konfigurasi utama, atau penggunaan aplikasi. Jika berlaku masalah, proses pemulihan hanya mengambil masa beberapa saat.
Walau bagaimanapun, apabila metodologi yang sama digunakan pada pangkalan data transaksional—seperti PostgreSQL, MySQL, Oracle, atau Microsoft SQL Server—syot kilat VM berubah daripada langkah keselamatan kepada bom jangka.
Bergantung pada syot kilat hipervisor standard untuk sandaran pangkalan data adalah salah satu punca paling biasa bagi kerosakan data, halaman terkoyak (torn pages), dan gangguan pengeluaran yang tidak dapat dipulihkan. Dalam artikel ini, kita akan meneroka pertembungan seni bina antara hipervisor dan enjin pangkalan data, mekanik kerosakan data semasa syot kilat, serta amalan kejuruteraan terbaik yang diperlukan untuk menyandarkan pangkalan data tervirtualisasi dengan selamat.
Pertembungan Seni Bina: Hipervisor lwn. Enjin Pangkalan Data
Untuk memahami mengapa syot kilat VM membahayakan pangkalan data, kita mesti terlebih dahulu meneliti bagaimana kedua-dua sistem menguruskan keadaan dan operasi I/O.
Bagaimana Hipervisor Melaksanakan Syot Kilat
Apabila hipervisor (seperti VMware ESXi, Microsoft Hyper-V, atau KVM) mengambil syot kilat, ia tidak menyalin cakera. Sebaliknya, ia membekukan fail cakera maya semasa (contohnya, .vmdk atau .vhdx) kepada keadaan baca sahaja dan mencipta cakera delta (cakera perbezaan) baharu. Semua penulisan seterusnya diarahkan ke cakera delta ini.
Apabila syot kilat dipadamkan, hipervisor mesti melakukan komit (penyatuan) data daripada cakera delta kembali ke cakera asas. Syot kilat standard sama sekali tidak menyedari aplikasi yang berjalan di dalam sistem pengendalian tetamu. Ia menangkap keadaan cakera tepat seperti yang wujud pada mikrosaat tersebut.
Bagaimana Pangkalan Data Transaksional Menguruskan Keadaan
Pangkalan data transaksional direka berdasarkan sifat ACID (Atomicity, Consistency, Isolation, Durability). Untuk mencapai prestasi tinggi sambil mengekalkan pematuhan ACID, pangkalan data tidak menulis setiap transaksi terus ke fail data utama pada cakera dengan serta-merta. Sebaliknya, ia menggunakan seni bina berbilang peringkat yang kompleks:
- Buffer Pool / Shared Buffers: Data dibaca ke dalam dan diubah suai dalam memori sistem.
- Write-Ahead Log (WAL) / Redo Logs: Perubahan ditulis secara berurutan ke fail log yang sangat dioptimumkan pada cakera untuk memastikan ketahanan.
- Checkpoints / Lazy Writers: Secara berkala, pangkalan data membuang halaman yang diubah suai (kotor) dari memori ke fail data sebenar pada cakera.
Disebabkan seni bina ini, fail data fizikal pada cakera hampir sentiasa tidak selari dengan keadaan sebenar pangkalan data. Keadaan sebenar pangkalan data hanya wujud sebagai gabungan fail data pada cakera, log WAL/Redo, dan data yang sedang berada dalam memori.
Zon Bahaya: Apa yang Berlaku Semasa Syot Kilat VM
Apabila anda mengambil syot kilat VM standard bagi pelayan pangkalan data, anda menangkap keadaan yang konsisten dengan ranap (crash-consistent).
Konsistensi Ranap lwn. Konsistensi Aplikasi
Syot kilat yang konsisten dengan ranap adalah setara dengan mencabut kord kuasa daripada pelayan fizikal. Keadaan cakera ditangkap, tetapi apa sahaja yang berada dalam memori akan hilang, dan apa sahaja yang sedang dalam proses ke pengawal storan akan terputus secara tiba-tiba.
Walaupun pangkalan data moden direka untuk pulih daripada kehilangan kuasa yang tidak dijangka dengan memainkan semula Write-Ahead Log, bergantung pada pemulihan ranap sebagai strategi sandaran utama anda adalah sangat berbahaya. Jika pangkalan data anda merangkumi berbilang cakera maya (contohnya, fail data pada Drive D: dan WAL pada Drive E:), hipervisor mungkin tidak mengambil syot kilat kedua-dua cakera pada mikrosaat yang sama tepat. Jika syot kilat cakera WAL ditangkap walaupun sesaat selepas syot kilat cakera data, pangkalan data tidak dapat menyelaraskan nombor urutan semasa pemulihan, yang mengakibatkan kerosakan maut.
Kesan “VM Stun” pada Sistem Transaksi Tinggi
Proses penciptaan syot kilat—dan yang lebih penting, proses penyatuan syot kilat—menyebabkan fenomena yang dikenali sebagai “VM Stun.”
Untuk menukar I/O dengan selamat daripada cakera asas kepada cakera delta, hipervisor mesti menjeda (stun) mesin maya secara ringkas. Bagi pelayan web yang dimuatkan dengan ringan, stun ini mungkin berlangsung selama 10-50 milisaat dan tidak disedari. Walau bagaimanapun, bagi pangkalan data dengan daya pemprosesan tinggi dan I/O yang besar, menyatukan cakera delta yang besar boleh menyebabkan VM terhenti (stun) selama beberapa saat.
Semasa VM stun:
* Sambungan rangkaian terputus, menyebabkan tamat masa aplikasi.
* Kluster ketersediaan tinggi (seperti SQL Server Always On, PostgreSQL Patroni, atau MySQL Galera) terlepas semakan degupan jantung (heartbeat).
* Kluster mungkin menganggap nod yang terhenti itu telah mati, mencetuskan kegagalan (failover) yang tidak perlu dan mengganggu (senario split-brain).
Halaman Terkoyak dan Penjajaran I/O yang Salah
Enjin pangkalan data biasanya menulis data dalam saiz halaman tertentu (contohnya, 8KB untuk PostgreSQL dan SQL Server, 16KB untuk InnoDB). Walau bagaimanapun, sistem pengendalian dan tatasusunan storan asas memproses I/O dalam blok yang lebih kecil (contohnya, 4KB atau 512 bait).
Jika hipervisor mengambil syot kilat tepat semasa pangkalan data sedang menulis halaman 8KB, syot kilat mungkin menangkap 4KB pertama data baharu dan 4KB terakhir data lama. Ini mencipta halaman terkoyak (torn page). Apabila anda cuba memulihkan syot kilat, pangkalan data akan membaca halaman tersebut, gagal dalam pengesahan checksum, dan menandakan pangkalan data sebagai rosak.
Akibat Dunia Sebenar untuk Enjin Pangkalan Data Tertentu
Enjin pangkalan data yang berbeza bertindak balas terhadap syot kilat yang konsisten dengan ranap dalam pelbagai cara, tetapi tiada satu pun daripadanya mengendalikannya dengan lancar dalam persekitaran pengeluaran.
- PostgreSQL: PostgreSQL sangat bergantung pada direktori
pg_wal. Jika syot kilat menangkap direktori data ($PGDATA) dan WAL yang tidak selari, PostgreSQL akan gagal bermula, mengeluarkan ralatPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB menggunakan penimbal tulis ganda (doublewrite buffer) untuk mengelakkan halaman terkoyak, yang menawarkan sedikit perlindungan terhadap keadaan konsisten dengan ranap. Walau bagaimanapun, jika fail
ibdata1danib_logfileditangkap secara tidak selari, enjin InnoDB akan ranap semasa pemulihan. - Microsoft SQL Server: SQL Server sangat sensitif terhadap pembekuan I/O. Tanpa integrasi VSS (Volume Shadow Copy Service) yang betul, memulihkan SQL Server daripada syot kilat VM standard akan sering mengakibatkan pangkalan data dalam keadaan syak (suspect) dan rantaian log yang rosak, memusnahkan keupayaan Pemulihan Titik-Masa (PITR) anda.
Amalan Terbaik untuk Menyandarkan Pangkalan Data Tervirtualisasi dengan Selamat
Untuk melindungi pangkalan data transaksional, anda mesti beralih daripada sandaran konsisten-ranap kepada sandaran konsisten-aplikasi. Ini memerlukan mekanisme sandaran untuk berkomunikasi dengan enjin pangkalan data, memaksanya untuk membuang memori ke cakera dan menjeda operasi I/O seketika semasa syot kilat diambil.
1. Manfaatkan Pengkuiesan Sedar Aplikasi (VSS dan fsfreeze)
Untuk Windows (SQL Server):
Sentiasa pastikan penyelesaian sandaran anda menggunakan Microsoft Volume Shadow Copy Service (VSS). Apabila sandaran yang sedar VSS dicetuskan, SQL Server VSS Writer membekukan I/O pangkalan data, membuang transaksi yang belum selesai ke cakera, dan memastikan syot kilat adalah konsisten-aplikasi sepenuhnya.
Untuk Linux (PostgreSQL / MySQL):
Linux tidak mempunyai setara asli dengan VSS. Untuk mencapai konsistensi aplikasi, anda mesti menggunakan skrip pra-beku (pre-freeze) dan pasca-cair (post-thaw) bersama-sama dengan alatan tetamu hipervisor (contohnya, VMware Tools).
Berikut adalah contoh pre-freeze-script VMware untuk PostgreSQL 15+ yang menyediakan pangkalan data dengan selamat untuk syot kilat:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Pastikan skrip ini boleh laksana (chmod +x)
# 1. Beritahu PostgreSQL untuk bersedia bagi sandaran
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Buang penimbal sistem fail ke cakera
sync
# 3. Bekukan sistem fail (andaikan data berada pada /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
Dan post-thaw-script yang sepadan untuk menyambung semula operasi:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Cairkan sistem fail
fsfreeze -u /var/lib/pgsql
# 2. Beritahu PostgreSQL sandaran telah selesai
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Gunakan Utiliti Sandaran Pangkalan Data Asli
Walaupun syot kilat konsisten-aplikasi lebih baik daripada syot kilat standard, ia masih membawa risiko VM stun. Pendekatan paling selamat untuk sandaran pangkalan data adalah menggunakan utiliti sandaran penstriman asli yang beroperasi secara bebas daripada hipervisor.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Alatan ini mengambil sandaran panas dan tidak menyekat dengan menyalin fail data dan pada masa yang sama menjejaki perubahan dalam log redo.
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. Laksanakan Pemulihan Titik-Masa (PITR) melalui Pengarkiban Log
Syot kilat harian atau sandaran penuh hanya melindungi anda sehingga minit ia diambil. Jika pangkalan data anda ranap pada jam 4:00 petang dan syot kilat terakhir anda adalah pada jam 2:00 pagi, anda kehilangan 14 jam data transaksional.
Untuk mencapai daya tahan perusahaan yang sebenar, anda mesti menggabungkan sandaran penuh konsisten-aplikasi dengan pengarkiban log berterusan (menyandarkan WAL, Redo Logs, atau Transaction Logs setiap beberapa minit). Ini membolehkan DBA memulihkan pangkalan data ke minit tertentu atau bahkan ID transaksi tertentu sebelum bencana berlaku.
Strategi Sandaran Perusahaan dengan CloudSave
Menguruskan skrip pra-beku tersuai, kerja cron untuk dump asli, dan penghantaran log merentasi berpuluh-puluh pelayan pangkalan data adalah mimpi ngeri operasi bagi pasukan DevOps. Di sinilah platform gred perusahaan seperti CloudSave menjadi kritikal.
CloudSave merapatkan jurang antara virtualisasi dan seni bina pangkalan data. Daripada bergantung pada syot kilat hipervisor yang buta, CloudSave menggunakan ejen sedar aplikasi yang berintegrasi secara asli dengan SQL Server, PostgreSQL, MySQL, dan Oracle.
Apabila CloudSave memulakan sandaran:
1. Ia berkomunikasi terus dengan enjin pangkalan data melalui API asli (seperti VSS untuk Windows atau penstriman WAL asli untuk Linux).
2. Ia menyelaraskan pembuangan penimbal memori ke cakera tanpa menyebabkan VM stun yang mengganggu.
3. Ia menangkap fail data dengan selamat dan menguruskan pemotongan log transaksi secara automatik.
4. Ia menyandarkan log transaksi secara berterusan, membolehkan Pemulihan Titik-Masa (PITR) yang terperinci dengan beberapa klik.
Dengan memindahkan kerumitan konsistensi aplikasi kepada CloudSave, DBA dan pentadbir sistem boleh menjamin integriti data tanpa mengorbankan prestasi atau ketersediaan kluster pengeluaran mereka.
Kesimpulan
Syot kilat mesin maya adalah alat yang luar biasa untuk pengurusan infrastruktur, tetapi ia pada dasarnya tidak serasi dengan keperluan ACID pangkalan data transaksional. Bergantung pada syot kilat hipervisor yang konsisten-ranap mendedahkan organisasi anda kepada halaman terkoyak, rantaian replikasi yang rosak, dan kehilangan data yang dahsyat.
Untuk melindungi data kritikal misi anda, anda mesti melaksanakan pengkuiesan sedar aplikasi, menggunakan metodologi sandaran pangkalan data asli, dan mengekalkan arkib log transaksi yang berterusan. Dengan menggunakan penyelesaian sandaran perusahaan yang dibina khusus, anda boleh memastikan pangkalan data anda kekal tersedia tinggi, boleh dipulihkan sepenuhnya, dan selamat sepenuhnya.
