প্রথমে ঠিক করুন কোন তথ্য সক্রিয় সিস্টেম থেকে সরানো যাবে এবং পরে তা কীভাবে উদ্ধার করা হবে। এর ওপরই নির্ভর করে কী নিরাপদে মুছতে পারবেন।
আর্কাইভিং ব্যবহারযোগ্য ঐতিহাসিক কপি রাখে। পার্জিং সক্রিয় কপি সরায়। এগুলো আলাদা সিদ্ধান্ত: এক্সপোর্ট সফল হলেই মুছে ফেলা নিরাপদ, এমন নয়।
ধরুন অর্ডার সিস্টেম গত বারো মাসের সম্পন্ন অর্ডার সরাসরি ব্যবহারের জন্য রাখে। এটি উদাহরণস্বরূপ নীতি। পুরোনো কোনো অর্ডারের বিরোধ নিষ্পত্তি না হলে সেটি সক্রিয় রাখার প্রয়োজন হতে পারে।
সময়সীমা, টাইম জোন, ব্যতিক্রম ও পুরোনো তথ্য খোঁজার চাহিদা ঠিক করুন। ব্যবসার পুরোনো ইনভয়েস উদ্ধার করতে হলে আর্কাইভে প্রয়োজনীয় পরিচয় ও সম্পর্ক সংরক্ষণ করতে হবে।
Partitioning একটি যৌক্তিক টেবিলকে একাধিক বাস্তব অংশে ভাগ করে, যেমন প্রতি মাসের জন্য একটি অংশ। মাসিক partition তখনই সরানো যুক্তিসংগত যখন তার সব রেকর্ড উপযুক্ত। নইলে ব্যতিক্রমগুলো নিরাপদে সরান বা আরও নির্দিষ্টভাবে মুছে ফেলার পদ্ধতি নিন।
ধরুন একটি অর্ডার কপি করার পর মূলটি মোছার আগে তার মূল্য সংশোধন করা হলো। এক্সপোর্ট করা কপিতে এখন ভুল মূল্য আছে।
এই ফাঁক বন্ধ করার পদ্ধতি বেছে নিন:
দেরিতে আসা রেকর্ড ও পরবর্তী সংশোধন কোথায় যাবে তা ঠিক করুন। শুধু পুরোনো timestamp বাছাই করলে অন্য process সেই সারি বদলাতে পারবে না, এমন নিশ্চয়তা আসে না।
[Eligible range] -> [Consistent export] -> [Archive + manifest]
|
[Restore and verify]
Manifest-এ কী এক্সপোর্ট হয়েছে তার বিবরণ থাকে: পরিসর, schema সংস্করণ, সংখ্যা ও ফাইলের checksum। এতে আর্কাইভ শনাক্ত এবং অসম্পূর্ণ বা ক্ষতিগ্রস্ত ফাইল ধরতে সুবিধা হয়।
শুধু ফাইল আছে কি না দেখার চেয়ে বেশি যাচাই করুন:
উৎসের কোন সময়সীমা যাচাই হয়েছে এবং কে করেছেন তা লিখে রাখুন। আর্কাইভে প্রবেশ সুরক্ষিত করুন এবং তার সংরক্ষণকালও ঠিক করুন। প্রয়োজনীয় উদ্ধারপথ বাস্তবে প্রমাণের পরেই মূল তথ্য সরানো যাবে।
| পরিস্থিতি | পদ্ধতি | কী যাচাই করবেন |
|---|---|---|
| পুরো partition উপযুক্ত | পরিকল্পিত maintenance-এর মাধ্যমে detach বা drop করুন | আর্কাইভ যাচাই, lock ও নির্ভরশীল object। |
| উপযুক্ত সারি সক্রিয় সারির সঙ্গে মিশে আছে | ছোট, পুনরায় চালানো যায় এমন batch-এ delete করুন | স্থির নির্বাচন, transaction-এর আকার ও replica lag। |
PostgreSQL-এ partition detach করলে সেটি স্বতন্ত্র টেবিল হিসেবে থাকে, যা drop করার আগে আর্কাইভ ও পরীক্ষা করা যায়। যাচাই চলাকালে ঐতিহাসিক অনুসন্ধান সেই টেবিলে পাঠানো হলে এই ক্রম কাজে আসতে পারে।
Partition সরালে আলাদা আলাদা সারি মুছতে হয় না, কিন্তু lock এখনও লাগে। Concurrent detach-এর সীমাবদ্ধতা আছে, তাই ব্যবহৃত সংস্করণ ও নির্ভরতা দেখুন। Batch deletion-এ transaction log এবং cleanup কাজও পর্যবেক্ষণ করুন। PostgreSQL partition maintenance।
অগ্রগতি সংরক্ষণ করুন: exported, verified, deletion-এর জন্য ready এবং purged। পুনরায় চালু হলে job যেন বড় সময়সীমা নতুন করে হিসাব না করে সঠিক যাচাইকৃত পরিসর জানে।
মোছার আগে আবার নিশ্চিত করুন যে ওই পরিসরে আর্কাইভ না হওয়া পরিবর্তন ঢোকেনি। পরে সক্রিয় query চলছে এবং আর্কাইভের রেকর্ড উদ্ধার করা যাচ্ছে কি না দেখুন।
মনে রাখুন: যোগ্যতা নির্ধারণ → পরিবর্তন নিয়ন্ত্রণ → restore প্রমাণ → deletion পদ্ধতি নির্বাচন → ফল যাচাই। লক্ষ্য হলো সক্রিয় তথ্য কমানো এবং নির্ভরযোগ্য ঐতিহাসিক অনুসন্ধান বজায় রাখা।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন