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.<\/p>\n
Walau bagaimanapun, apabila metodologi yang sama digunakan pada pangkalan data transaksional\u2014seperti PostgreSQL, MySQL, Oracle, atau Microsoft SQL Server\u2014syot kilat VM berubah daripada langkah keselamatan kepada bom jangka.<\/p>\n
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.<\/p>\n
Untuk memahami mengapa syot kilat VM membahayakan pangkalan data, kita mesti terlebih dahulu meneliti bagaimana kedua-dua sistem menguruskan keadaan dan operasi I\/O.<\/p>\n
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, 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.<\/p>\n 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:<\/p>\n 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.<\/p>\n Apabila anda mengambil syot kilat VM standard bagi pelayan pangkalan data, anda menangkap keadaan yang konsisten dengan ranap (crash-consistent)<\/strong>.<\/p>\n 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.<\/p>\n 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 Proses penciptaan syot kilat\u2014dan yang lebih penting, proses penyatuan syot kilat\u2014menyebabkan fenomena yang dikenali sebagai “VM Stun.”<\/p>\n 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.<\/p>\n Semasa VM stun: 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).<\/p>\n 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)<\/strong>. Apabila anda cuba memulihkan syot kilat, pangkalan data akan membaca halaman tersebut, gagal dalam pengesahan checksum, dan menandakan pangkalan data sebagai rosak.<\/p>\n 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.<\/p>\n Untuk melindungi pangkalan data transaksional, anda mesti beralih daripada sandaran konsisten-ranap kepada sandaran konsisten-aplikasi<\/strong>. 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.<\/p>\n Untuk Windows (SQL Server):<\/strong> Untuk Linux (PostgreSQL \/ MySQL):<\/strong> Berikut adalah contoh Dan 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.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Apabila CloudSave memulakan sandaran: Dengan memindahkan kerumitan konsistensi aplikasi kepada CloudSave, DBA dan pentadbir sistem boleh menjamin integriti data tanpa mengorbankan prestasi atau ketersediaan kluster pengeluaran mereka.<\/p>\n 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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" > 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Why VM Snapshots Are Unsafe for Transactional Databases","rank_math_description":"> 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.","rank_math_focus_keyword":"VM snapshots transactional databases","footnotes":""},"categories":[559],"tags":[3412,3740,3741,3742,3743,3744,3745],"class_list":["post-5496","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-data-integrity","tag-database-corruption","tag-database-recovery","tag-dba-guide","tag-hypervisor-snapshots","tag-transactional-databases","tag-vm-snapshots"],"yoast_head":"\n.vmdk<\/code> atau .vhdx<\/code>) kepada keadaan baca sahaja dan mencipta cakera delta (cakera perbezaan) baharu. Semua penulisan seterusnya diarahkan ke cakera delta ini.<\/p>\nBagaimana Pangkalan Data Transaksional Menguruskan Keadaan<\/h3>\n
\n
Zon Bahaya: Apa yang Berlaku Semasa Syot Kilat VM<\/h2>\n
Konsistensi Ranap lwn. Konsistensi Aplikasi<\/h3>\n
Drive D:<\/code> dan WAL pada Drive E:<\/code>), 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.<\/p>\nKesan “VM Stun” pada Sistem Transaksi Tinggi<\/h3>\n
\n* Sambungan rangkaian terputus, menyebabkan tamat masa aplikasi.
\n* Kluster ketersediaan tinggi (seperti SQL Server Always On, PostgreSQL Patroni, atau MySQL Galera) terlepas semakan degupan jantung (heartbeat).
\n* Kluster mungkin menganggap nod yang terhenti itu telah mati, mencetuskan kegagalan (failover) yang tidak perlu dan mengganggu (senario split-brain).<\/p>\nHalaman Terkoyak dan Penjajaran I\/O yang Salah<\/h3>\n
Akibat Dunia Sebenar untuk Enjin Pangkalan Data Tertentu<\/h2>\n
\n
pg_wal<\/code>. Jika syot kilat menangkap direktori data ($PGDATA<\/code>) dan WAL yang tidak selari, PostgreSQL akan gagal bermula, mengeluarkan ralat PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> dan ib_logfile<\/code> ditangkap secara tidak selari, enjin InnoDB akan ranap semasa pemulihan.<\/li>\nAmalan Terbaik untuk Menyandarkan Pangkalan Data Tervirtualisasi dengan Selamat<\/h2>\n
1. Manfaatkan Pengkuiesan Sedar Aplikasi (VSS dan fsfreeze)<\/h3>\n
\nSentiasa 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.<\/p>\n
\nLinux 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).<\/p>\npre-freeze-script<\/code> VMware untuk PostgreSQL 15+ yang menyediakan pangkalan data dengan selamat untuk syot kilat:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Pastikan skrip ini boleh laksana (chmod +x)\n\n# 1. Beritahu PostgreSQL untuk bersedia bagi sandaran\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Buang penimbal sistem fail ke cakera\nsync\n\n# 3. Bekukan sistem fail (andaikan data berada pada \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> yang sepadan untuk menyambung semula operasi:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Cairkan sistem fail\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Beritahu PostgreSQL sandaran telah selesai\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Gunakan Utiliti Sandaran Pangkalan Data Asli<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nAlatan ini mengambil sandaran panas dan tidak menyekat dengan menyalin fail data dan pada masa yang sama menjejaki perubahan dalam log redo.<\/p>\nmariabackup --backup --target-dir=\/mnt\/backups\/mysql_backup --user=root --password=SecurePass\n<\/code><\/pre>\nBACKUP DATABASE [ProductionDB] \nTO DISK = N'Z:BackupsProductionDB.bak' \nWITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', \nSKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\n3. Laksanakan Pemulihan Titik-Masa (PITR) melalui Pengarkiban Log<\/h3>\n
Strategi Sandaran Perusahaan dengan CloudSave<\/h2>\n
\n1. Ia berkomunikasi terus dengan enjin pangkalan data melalui API asli (seperti VSS untuk Windows atau penstriman WAL asli untuk Linux).
\n2. Ia menyelaraskan pembuangan penimbal memori ke cakera tanpa menyebabkan VM stun yang mengganggu.
\n3. Ia menangkap fail data dengan selamat dan menguruskan pemotongan log transaksi secara automatik.
\n4. Ia menyandarkan log transaksi secara berterusan, membolehkan Pemulihan Titik-Masa (PITR) yang terperinci dengan beberapa klik.<\/p>\nKesimpulan<\/h2>\n