ডেভঅপস (DevOps) ইঞ্জিনিয়ার এবং সিস্টেম অ্যাডমিনিস্ট্রেটরদের জন্য ভার্চুয়াল মেশিন (VM) স্ন্যাপশট একটি মৌলিক হাতিয়ার। কোনো ঝুঁকিপূর্ণ প্যাচ, বড় ধরনের কনফিগারেশন পরিবর্তন বা অ্যাপ্লিকেশন ডেপ্লয়মেন্টের আগে সার্ভারের বর্তমান অবস্থা সংরক্ষণ করার জন্য এটি একটি দ্রুত এবং সুবিধাজনক উপায়। যদি কোনো সমস্যা হয়, তবে কয়েক সেকেন্ডের মধ্যেই আগের অবস্থায় ফিরে আসা সম্ভব।
তবে, যখন এই একই পদ্ধতি ট্রানজ্যাকশনাল ডাটাবেস—যেমন PostgreSQL, MySQL, Oracle বা Microsoft SQL Server-এর ক্ষেত্রে প্রয়োগ করা হয়, তখন VM স্ন্যাপশটগুলো একটি নিরাপত্তা কবচ থেকে একটি টাইম বোমায় পরিণত হয়।
ডাটাবেস ব্যাকআপের জন্য স্ট্যান্ডার্ড হাইপারভাইজার স্ন্যাপশটের ওপর নির্ভর করা ডাটা করাপশন, টর্ন পেজ (torn pages) এবং পুনরুদ্ধার অযোগ্য প্রোডাকশন বিভ্রাটের অন্যতম প্রধান কারণ। এই নিবন্ধে, আমরা হাইপারভাইজার এবং ডাটাবেস ইঞ্জিনের মধ্যে স্থাপত্যগত দ্বন্দ্ব, স্ন্যাপশটের সময় ডাটা করাপশনের প্রক্রিয়া এবং ভার্চুয়ালাইজড ডাটাবেস নিরাপদে ব্যাকআপ করার জন্য প্রয়োজনীয় ইঞ্জিনিয়ারিং বেস্ট প্র্যাকটিসগুলো নিয়ে আলোচনা করব।
স্থাপত্যগত দ্বন্দ্ব: হাইপারভাইজার বনাম ডাটাবেস ইঞ্জিন
VM স্ন্যাপশট কেন ডাটাবেসের জন্য ঝুঁকিপূর্ণ তা বোঝার জন্য, আমাদের প্রথমে দেখতে হবে যে এই দুটি সিস্টেম কীভাবে স্টেট (state) এবং I/O অপারেশন পরিচালনা করে।
হাইপারভাইজার কীভাবে স্ন্যাপশট কার্যকর করে
যখন একটি হাইপারভাইজার (যেমন VMware ESXi, Microsoft Hyper-V, বা KVM) স্ন্যাপশট নেয়, তখন এটি ডিস্ক কপি করে না। পরিবর্তে, এটি বর্তমান ভার্চুয়াল ডিস্ক ফাইলটিকে (যেমন .vmdk বা .vhdx) রিড-অনলি অবস্থায় ফ্রিজ করে দেয় এবং একটি নতুন ডেল্টা ডিস্ক (ডিফারেন্সিং ডিস্ক) তৈরি করে। পরবর্তী সমস্ত রাইট অপারেশন এই ডেল্টা ডিস্কে নির্দেশিত হয়।
যখন স্ন্যাপশটটি ডিলিট করা হয়, তখন হাইপারভাইজারকে ডেল্টা ডিস্কের ডাটা মূল ডিস্কে কমিট (একীভূত) করতে হয়। স্ট্যান্ডার্ড স্ন্যাপশটগুলো গেস্ট অপারেটিং সিস্টেমের ভেতরে চলমান অ্যাপ্লিকেশন সম্পর্কে সম্পূর্ণ অজ্ঞ থাকে। তারা ঠিক সেই মাইক্রোসেকেন্ডে ডিস্কের অবস্থা যেমন থাকে, ঠিক সেভাবেই তা ক্যাপচার করে।
ট্রানজ্যাকশনাল ডাটাবেস কীভাবে স্টেট পরিচালনা করে
ট্রানজ্যাকশনাল ডাটাবেসগুলো ACID প্রপার্টি (Atomicity, Consistency, Isolation, Durability) মেনে ডিজাইন করা হয়। ACID কমপ্লায়েন্স বজায় রেখে উচ্চ কর্মক্ষমতা অর্জনের জন্য, ডাটাবেস প্রতিটি ট্রানজ্যাকশন সরাসরি ডিস্কের মূল ডাটা ফাইলে লেখে না। পরিবর্তে, তারা একটি জটিল, মাল্টি-টায়ার্ড আর্কিটেকচার ব্যবহার করে:
- বাফার পুল / শেয়ারড বাফারস: ডাটা সিস্টেম মেমরিতে পড়া এবং পরিবর্তন করা হয়।
- রাইট-অহেড লগ (WAL) / রিডু লগস: স্থায়িত্ব নিশ্চিত করার জন্য পরিবর্তনগুলো ডিস্কের একটি অত্যন্ত অপ্টিমাইজ করা লগ ফাইলে ক্রমানুসারে লেখা হয়।
- চেকপয়েন্ট / লেজি রাইটারস: পর্যায়ক্রমে, ডাটাবেস মেমরি থেকে পরিবর্তিত (ডার্টি) পেজগুলো ডিস্কের মূল ডাটা ফাইলে ফ্লাশ করে।
এই আর্কিটেকচারের কারণে, ডিস্কের ফিজিক্যাল ডাটা ফাইলগুলো প্রায় সবসময় ডাটাবেসের প্রকৃত অবস্থার সাথে সিঙ্কে থাকে না। ডাটাবেসের প্রকৃত অবস্থা শুধুমাত্র ডিস্কের ডাটা ফাইল, WAL/রিডু লগ এবং বর্তমানে মেমরিতে থাকা ডাটার সমন্বয়ে গঠিত হয়।
বিপজ্জনক এলাকা: VM স্ন্যাপশটের সময় যা ঘটে
যখন আপনি একটি ডাটাবেস সার্ভারের স্ট্যান্ডার্ড VM স্ন্যাপশট নেন, তখন আপনি একটি ক্র্যাশ-কনসিস্টেন্ট স্টেট ক্যাপচার করছেন।
ক্র্যাশ কনসিস্টেন্সি বনাম অ্যাপ্লিকেশন কনসিস্টেন্সি
একটি ক্র্যাশ-কনসিস্টেন্ট স্ন্যাপশট হলো ফিজিক্যাল সার্ভার থেকে পাওয়ার কর্ড খুলে ফেলার সমতুল্য। ডিস্কের অবস্থা ক্যাপচার করা হয়, কিন্তু মেমরিতে যা ছিল তা হারিয়ে যায় এবং স্টোরেজ কন্ট্রোলারের দিকে যা যাচ্ছিল তা হঠাৎ বন্ধ হয়ে যায়।
যদিও আধুনিক ডাটাবেসগুলো রাইট-অহেড লগ রিপ্লে করার মাধ্যমে অপ্রত্যাশিত পাওয়ার লস থেকে পুনরুদ্ধার করার জন্য ডিজাইন করা হয়েছে, তবুও আপনার প্রাথমিক ব্যাকআপ কৌশল হিসেবে ক্র্যাশ রিকভারির ওপর নির্ভর করা অত্যন্ত বিপজ্জনক। যদি আপনার ডাটাবেস একাধিক ভার্চুয়াল ডিস্ক জুড়ে থাকে (যেমন Drive D:-তে ডাটা ফাইল এবং Drive E:-তে WAL), তবে হাইপারভাইজার হয়তো একই মাইক্রোসেকেন্ডে দুটি ডিস্কের স্ন্যাপশট নিতে পারবে না। যদি WAL ডিস্কের স্ন্যাপশট ডাটা ডিস্কের স্ন্যাপশটের এক সেকেন্ডের ভগ্নাংশ পরেও ক্যাপচার করা হয়, তবে ডাটাবেস পুনরুদ্ধারের সময় সিকোয়েন্স নম্বরগুলো মেলাতে পারবে না, যার ফলে মারাত্মক করাপশন ঘটবে।
উচ্চ-ট্রানজ্যাকশন সিস্টেমে “VM স্টান” (VM Stun) প্রভাব
স্ন্যাপশট তৈরির প্রক্রিয়া—এবং আরও গুরুত্বপূর্ণভাবে, স্ন্যাপশট কনসোলিডেশন প্রক্রিয়া—একটি ঘটনা ঘটায় যা “VM স্টান” নামে পরিচিত।
মূল ডিস্ক থেকে ডেল্টা ডিস্কে I/O নিরাপদে স্থানান্তর করার জন্য, হাইপারভাইজারকে ভার্চুয়াল মেশিনটিকে সংক্ষিপ্ত সময়ের জন্য পজ (স্টান) করতে হয়। হালকা লোডযুক্ত ওয়েব সার্ভারের জন্য, এই স্টান ১০-৫০ মিলিসেকেন্ড স্থায়ী হতে পারে এবং তা লক্ষ্য করা যায় না। তবে, প্রচুর I/O সম্পন্ন ডাটাবেসের ক্ষেত্রে, একটি বড় ডেল্টা ডিস্ক কনসোলিডেট করতে VM-কে কয়েক সেকেন্ডের জন্য স্টান করতে হতে পারে।
VM স্টান চলাকালীন:
* নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হয়ে যায়, যার ফলে অ্যাপ্লিকেশন টাইমআউট ঘটে।
* হাই-অ্যাভেইল্যাবিলিটি ক্লাস্টারগুলো (যেমন SQL Server Always On, PostgreSQL Patroni, বা MySQL Galera) হার্টবিট চেক মিস করে।
* ক্লাস্টারটি মনে করতে পারে যে স্টান হওয়া নোডটি মৃত, যার ফলে একটি অপ্রয়োজনীয় এবং বিঘ্নিত ফেইলওভার (স্প্লিট-ব্রেইন সিনারিও) ঘটে।
টর্ন পেজ এবং I/O মিসঅ্যালাইনমেন্ট
ডাটাবেস ইঞ্জিনগুলো সাধারণত নির্দিষ্ট পেজ সাইজে (যেমন PostgreSQL এবং SQL Server-এর জন্য 8KB, InnoDB-এর জন্য 16KB) ডাটা লেখে। তবে, অপারেটিং সিস্টেম এবং স্টোরেজ অ্যারেগুলো ছোট ব্লকে (যেমন 4KB বা 512 বাইট) I/O প্রসেস করে।
যদি কোনো হাইপারভাইজার ঠিক সেই মুহূর্তে স্ন্যাপশট নেয় যখন ডাটাবেস একটি 8KB পেজ লিখছে, তবে স্ন্যাপশটটি নতুন ডাটার প্রথম 4KB এবং পুরনো ডাটার শেষ 4KB ক্যাপচার করতে পারে। এটি একটি টর্ন পেজ তৈরি করে। যখন আপনি স্ন্যাপশটটি পুনরুদ্ধার করার চেষ্টা করবেন, ডাটাবেস পেজটি পড়বে, চেকসাম ভ্যালিডেশনে ব্যর্থ হবে এবং ডাটাবেসটিকে করাপ্ট হিসেবে চিহ্নিত করবে।
নির্দিষ্ট ডাটাবেস ইঞ্জিনের জন্য বাস্তব জীবনের পরিণতি
বিভিন্ন ডাটাবেস ইঞ্জিন ক্র্যাশ-কনসিস্টেন্ট স্ন্যাপশটের প্রতি ভিন্নভাবে প্রতিক্রিয়া জানায়, কিন্তু প্রোডাকশন এনভায়রনমেন্টে কেউই এটি ভালোভাবে সামলাতে পারে না।
- PostgreSQL: PostgreSQL মূলত
pg_walডিরেক্টরির ওপর নির্ভর করে। যদি কোনো স্ন্যাপশট ডাটা ডিরেক্টরি ($PGDATA) এবং WAL-কে সিঙ্কের বাইরে ক্যাপচার করে, তবে PostgreSQL চালু হতে ব্যর্থ হবে এবংPANIC: could not locate a valid checkpoint recordএরর দেখাবে। - MySQL/InnoDB: InnoDB টর্ন পেজ প্রতিরোধ করার জন্য একটি ডাবলরাইট বাফার ব্যবহার করে, যা ক্র্যাশ-কনসিস্টেন্ট স্টেটের বিরুদ্ধে কিছুটা সুরক্ষা দেয়। তবে, যদি
ibdata1ফাইল এবংib_logfileসিঙ্কের বাইরে ক্যাপচার করা হয়, তবে পুনরুদ্ধারের সময় InnoDB ইঞ্জিন ক্র্যাশ করবে। - Microsoft SQL Server: SQL Server I/O ফ্রিজিংয়ের প্রতি অত্যন্ত সংবেদনশীল। সঠিক VSS (Volume Shadow Copy Service) ইন্টিগ্রেশন ছাড়া, স্ট্যান্ডার্ড VM স্ন্যাপশট থেকে SQL Server পুনরুদ্ধার করলে প্রায়শই ডাটাবেস সাসপেক্ট মোডে চলে যায় এবং লগ চেইন ভেঙে যায়, যা আপনার পয়েন্ট-ইন-টাইম রিকভারি (PITR) সক্ষমতাকে নষ্ট করে দেয়।
ভার্চুয়ালাইজড ডাটাবেস নিরাপদে ব্যাকআপ করার বেস্ট প্র্যাকটিস
ট্রানজ্যাকশনাল ডাটাবেস সুরক্ষিত রাখতে, আপনাকে ক্র্যাশ-কনসিস্টেন্ট ব্যাকআপ থেকে অ্যাপ্লিকেশন-কনসিস্টেন্ট ব্যাকআপে যেতে হবে। এর জন্য ব্যাকআপ মেকানিজমকে ডাটাবেস ইঞ্জিনের সাথে যোগাযোগ করতে হয়, যাতে স্ন্যাপশট নেওয়ার সময় মেমরি থেকে ডিস্কে ডাটা ফ্লাশ করা হয় এবং I/O অপারেশন সাময়িকভাবে পজ করা হয়।
১. অ্যাপ্লিকেশন-অ্যাওয়ার কুইসিং (VSS এবং fsfreeze) ব্যবহার করুন
Windows (SQL Server)-এর জন্য:
সবসময় নিশ্চিত করুন যে আপনার ব্যাকআপ সলিউশন Microsoft Volume Shadow Copy Service (VSS) ব্যবহার করে। যখন একটি VSS-অ্যাওয়ার ব্যাকআপ ট্রিগার হয়, তখন SQL Server VSS রাইটার ডাটাবেস I/O ফ্রিজ করে, পেন্ডিং ট্রানজ্যাকশনগুলো ডিস্কে ফ্লাশ করে এবং নিশ্চিত করে যে স্ন্যাপশটটি পুরোপুরি অ্যাপ্লিকেশন-কনসিস্টেন্ট।
Linux (PostgreSQL / MySQL)-এর জন্য:
Linux-এ VSS-এর কোনো সরাসরি বিকল্প নেই। অ্যাপ্লিকেশন কনসিস্টেন্সি অর্জনের জন্য, আপনাকে হাইপারভাইজারের গেস্ট টুলের (যেমন VMware Tools) সাথে প্রি-ফ্রিজ এবং পোস্ট-থ (post-thaw) স্ক্রিপ্ট ব্যবহার করতে হবে।
নিচে PostgreSQL 15+-এর জন্য একটি VMware pre-freeze-script-এর উদাহরণ দেওয়া হলো যা স্ন্যাপশটের জন্য ডাটাবেসকে নিরাপদে প্রস্তুত করে:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# নিশ্চিত করুন যে এই স্ক্রিপ্টটি এক্সিকিউটেবল (chmod +x)
# ১. PostgreSQL-কে ব্যাকআপের জন্য প্রস্তুত হতে বলুন
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# ২. ফাইল সিস্টেম বাফারগুলো ডিস্কে ফ্লাশ করুন
sync
# ৩. ফাইল সিস্টেম ফ্রিজ করুন (ধরে নেওয়া হচ্ছে ডাটা /var/lib/pgsql-এ আছে)
fsfreeze -f /var/lib/pgsql
এবং অপারেশন পুনরায় শুরু করার জন্য সংশ্লিষ্ট post-thaw-script:
#!/bin/bash
# /usr/sbin/post-thaw-script
# ১. ফাইল সিস্টেম আনফ্রিজ করুন
fsfreeze -u /var/lib/pgsql
# ২. PostgreSQL-কে জানান যে ব্যাকআপ সম্পন্ন হয়েছে
su - postgres -c "psql -c "SELECT pg_backup_stop();""
২. নেটিভ ডাটাবেস ব্যাকআপ ইউটিলিটি ব্যবহার করুন
যদিও অ্যাপ্লিকেশন-কনসিস্টেন্ট স্ন্যাপশট স্ট্যান্ডার্ড স্ন্যাপশটের চেয়ে ভালো, তবুও এতে VM স্টানের ঝুঁকি থেকে যায়। ডাটাবেস ব্যাকআপের জন্য সবচেয়ে নিরাপদ পদ্ধতি হলো নেটিভ, স্ট্রিমিং ব্যাকআপ ইউটিলিটি ব্যবহার করা যা হাইপারভাইজার থেকে স্বাধীনভাবে কাজ করে।
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
এই টুলগুলো ডাটা ফাইল কপি করে এবং একই সাথে রিডু লগের পরিবর্তনগুলো ট্র্যাক করে হট, নন-ব্লকিং ব্যাকআপ নেয়।
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
৩. লগ আর্কাইভিংয়ের মাধ্যমে পয়েন্ট-ইন-টাইম রিকভারি (PITR) বাস্তবায়ন করুন
একটি দৈনিক স্ন্যাপশট বা ফুল ব্যাকআপ শুধুমাত্র স্ন্যাপশট নেওয়ার সময় পর্যন্তই আপনাকে সুরক্ষা দেয়। যদি আপনার ডাটাবেস বিকেল ৪:০০ টায় ক্র্যাশ করে এবং আপনার শেষ স্ন্যাপশটটি ভোর ২:০০ টায় নেওয়া হয়, তবে আপনি ১৪ ঘণ্টার ট্রানজ্যাকশনাল ডাটা হারাবেন।
প্রকৃত এন্টারপ্রাইজ রেজিলিয়েন্স অর্জনের জন্য, আপনাকে ফুল অ্যাপ্লিকেশন-কনসিস্টেন্ট ব্যাকআপের সাথে কন্টিনিউয়াস লগ আর্কাইভিং (প্রতি কয়েক মিনিট অন্তর WAL, রিডু লগ বা ট্রানজ্যাকশন লগ ব্যাকআপ করা) যুক্ত করতে হবে। এটি DBA-দের কোনো দুর্যোগের আগে ডাটাবেসকে একটি নির্দিষ্ট মিনিটে বা এমনকি একটি নির্দিষ্ট ট্রানজ্যাকশন আইডিতে পুনরুদ্ধার করার সুযোগ দেয়।
CloudSave-এর সাথে এন্টারপ্রাইজ ব্যাকআপ কৌশল
কাস্টম প্রি-ফ্রিজ স্ক্রিপ্ট, নেটিভ ডাম্পের জন্য ক্রন জব এবং ডজন ডজন ডাটাবেস সার্ভার জুড়ে লগ শিপিং পরিচালনা করা ডেভঅপস টিমের জন্য একটি দুঃস্বপ্ন। এখানেই CloudSave-এর মতো এন্টারপ্রাইজ-গ্রেড প্ল্যাটফর্ম অপরিহার্য হয়ে ওঠে।
CloudSave ভার্চুয়ালাইজেশন এবং ডাটাবেস আর্কিটেকচারের মধ্যে সেতুবন্ধন তৈরি করে। অন্ধ হাইপারভাইজার স্ন্যাপশটের ওপর নির্ভর না করে, CloudSave অ্যাপ্লিকেশন-অ্যাওয়ার এজেন্ট ব্যবহার করে যা SQL Server, PostgreSQL, MySQL এবং Oracle-এর সাথে নেটিভভাবে ইন্টিগ্রেট হয়।
যখন CloudSave ব্যাকআপ শুরু করে:
১. এটি নেটিভ API-এর মাধ্যমে (যেমন Windows-এর জন্য VSS বা Linux-এর জন্য নেটিভ WAL স্ট্রিমিং) সরাসরি ডাটাবেস ইঞ্জিনের সাথে যোগাযোগ করে।
২. এটি বিঘ্নিত VM স্টান তৈরি না করেই মেমরি বাফারগুলো ডিস্কে ফ্লাশ করার প্রক্রিয়া পরিচালনা করে।
৩. এটি নিরাপদে ডাটা ফাইলগুলো ক্যাপচার করে এবং স্বয়ংক্রিয়ভাবে ট্রানজ্যাকশন লগ ট্রাঙ্কেশন পরিচালনা করে।
৪. এটি ক্রমাগত ট্রানজ্যাকশন লগ ব্যাকআপ করে, যা কয়েক ক্লিকেই গ্র্যানুলার পয়েন্ট-ইন-টাইম রিকভারি (PITR) সক্ষম করে।
অ্যাপ্লিকেশন কনসিস্টেন্সির জটিলতা CloudSave-এর ওপর ছেড়ে দিয়ে, DBA এবং সিস্টেম অ্যাডমিনিস্ট্রেটররা তাদের প্রোডাকশন ক্লাস্টারের কর্মক্ষমতা বা প্রাপ্যতা বিসর্জন না দিয়েই ডাটার অখণ্ডতা নিশ্চিত করতে পারেন।
উপসংহার
ভার্চুয়াল মেশিন স্ন্যাপশট ইনফ্রাস্ট্রাকচার ম্যানেজমেন্টের জন্য একটি অবিশ্বাস্য টুল, কিন্তু এগুলো ট্রানজ্যাকশনাল ডাটাবেসের ACID প্রয়োজনীয়তার সাথে মৌলিকভাবে অসামঞ্জস্যপূর্ণ। ক্র্যাশ-কনসিস্টেন্ট হাইপারভাইজার স্ন্যাপশটের ওপর নির্ভর করা আপনার প্রতিষ্ঠানকে টর্ন পেজ, ভেঙে যাওয়া রেপ্লিকেশন চেইন এবং বিপর্যয়কর ডাটা হারানোর ঝুঁকির মুখে ফেলে।
আপনার মিশন-ক্রিটিক্যাল ডাটা সুরক্ষিত রাখতে, আপনাকে অবশ্যই অ্যাপ্লিকেশন-অ্যাওয়ার কুইসিং বাস্তবায়ন করতে হবে, নেটিভ ডাটাবেস ব্যাকআপ পদ্ধতি ব্যবহার করতে হবে এবং কন্টিনিউয়াস ট্রানজ্যাকশন লগ আর্কাইভ বজায় রাখতে হবে। উদ্দেশ্যমূলক এন্টারপ্রাইজ ব্যাকআপ সলিউশন গ্রহণ করার মাধ্যমে, আপনি নিশ্চিত করতে পারেন যে আপনার ডাটাবেসগুলো সর্বদা সচল, পুরোপুরি পুনরুদ্ধারযোগ্য এবং সম্পূর্ণ নিরাপদ থাকবে।
