গত সপ্তাহে আমি আমার উৎপাদন ডাটাবেস মুছে ফেলেছি। আমার কাজের [নিওটোমা](https://neotoma.io) উদাহরণ একটি কমান্ডে 6,174টি পর্যবেক্ষণ এবং 3,862টি সত্তা থেকে 84টি পর্যবেক্ষণ এবং 67টি সত্তায় গেছে৷ কয়েক মাসের পরিচিতি, কাজ, কথোপকথন, প্রতিক্রিয়া নোট, লেনদেন এবং স্থায়ী নিয়ম: চলে গেছে।

আমি এটা ফিরে পেয়েছিলাম. চূড়ান্ত ডাটাবেসে 6,296টি পর্যবেক্ষণ এবং 3,951টি সত্তা রয়েছে যা পাঁচ সপ্তাহের কার্যকলাপে বিস্তৃত। পুনরুদ্ধারের জন্য প্রায় এক ঘন্টা সময় লেগেছে। এই পোস্টটি এটি কীভাবে ঘটেছে, কেন পুনরুদ্ধার সম্ভব হয়েছিল এবং আপনি আসলে বিশ্বাস করতে পারেন এমন একটি মেমরি সিস্টেম তৈরি করার অভিজ্ঞতা কী প্রকাশ করেছে সে সম্পর্কে।

## কি হয়েছে

আমি নিওটোমা সিএলআই-তে কাজ করছিলাম, একটি উন্নয়ন কর্মপ্রবাহ পরীক্ষা করছিলাম। আমি কমান্ডের একটি ক্রম চালিয়েছি যা ডাটাবেস অবস্থা পুনরায় সেট করে এবং এটি পুনরায় চালু করে। উদ্দেশ্য ছিল একটি dev পরিবেশ থেকে পরীক্ষার ডেটা সাফ করা। লক্ষ্য ছিল উৎপাদন ডাটাবেস।

ভুলটা ছিল জাগতিক। আমি `নিওটোমা রিসেট` চালিয়েছিলাম যখন `NEOTOMA_ENV` উৎপাদনে সেট করা হয়েছিল। আমি ভেবেছিলাম আমি দেবকে টার্গেট করছি। যখন আমি লক্ষ্য করেছি, সক্রিয় ডাটাবেসটিতে পুনরায় শুরু করার প্রক্রিয়া থেকে 84টি নতুন পর্যবেক্ষণ ছিল এবং অন্য কিছুই ছিল না।

## ব্যাকআপ খোঁজা হচ্ছে

প্রথম জিনিসটি আমি আমার মেশিনে প্রতিটি Neotoma SQLite ফাইলের জন্য অনুসন্ধান করেছি। আমি মার্চের শুরুতে আগের বন্ধ কল থেকে ব্যাকআপ ডিরেক্টরি, ডেটা ফোল্ডার এবং টাইমস্ট্যাম্পযুক্ত পুনরুদ্ধার শিল্পকর্ম জুড়ে ছড়িয়ে ছিটিয়ে থাকা দশটি কপি পেয়েছি।

| সোর্স ফাইল | পর্যবেক্ষণ | সত্তা | সর্বশেষ কার্যকলাপ |
|---|---|---|---|
| `neotoma.prod.db.db` | 6,174 | 3,862 | 9 মার্চ |
| `neotoma.prod 2.db` | 4,406 | 3,073 | মার্চ 10 |
| লাইভ লক্ষ্য (পোস্ট-ওয়াইপ) | 84 | 67 | 11 মার্চ |
| `neotoma.prod.db.recovered-*` | 4,381 | 3,059 | 3 মার্চ |
| `ডেটা-ব্যাকআপ/ডেটা কপি/` | 4,158 | 2,955 | 2 মার্চ |
| বিভিন্ন পুরানো কপি | 3,100 থেকে 3,931 | 2,558 থেকে 2,806 | ফেব্রুয়ারী 17 থেকে ফেব্রুয়ারী 27 |

ব্যাকআপ কপিগুলি বিদ্যমান ছিল কারণ আমি অনিয়মিত বিরতিতে ডাটাবেস ফাইলটি ম্যানুয়ালি কপি করছিলাম। একটি আনুষ্ঠানিক ব্যাকআপ সিস্টেম নয়, আমি মনে পড়লে বা নার্ভাস বোধ করলে মাঝে মাঝে 'cp' কমান্ড দেয়। সেই কপিগুলির মধ্যে একটি, `neotoma.prod.db.db`, ​​9 মার্চ পর্যন্ত প্রায় সবকিছুই ধরে রেখেছিল। একটি দ্বিতীয় কপি, `neotoma.prod 2.db`-তে 10 মার্চ পর্যন্ত ডেটা ছিল যা প্রথম কপিটি মিস হয়েছে।

এই দুটি ফাইল এবং লাইভ ডাটাবেসে বেঁচে থাকা 84 টি পর্যবেক্ষণের মধ্যে, আমার কাছে সম্পূর্ণ টাইমলাইন পুনর্গঠনের জন্য যথেষ্ট উপাদান ছিল।

## কিভাবে মার্জ কাজ করে

SQLite ডাটাবেস একত্রিত করার জন্য Neotoma-এর একটি অন্তর্নির্মিত `merge-db` কমান্ড রয়েছে। প্রক্রিয়া:

1. একটি টাইমস্ট্যাম্পড ডিরেক্টরিতে জড়িত প্রতিটি ফাইল (উৎস এবং লক্ষ্য উভয়) ব্যাক আপ করুন। কোন পুনরুদ্ধারের প্রচেষ্টা মূল ঝুঁকি করা উচিত নয়.
2. সমসাময়িক লেখাগুলি প্রতিরোধ করতে চলমান নিওটোমা সার্ভার বন্ধ করুন।
3. কোন দ্বন্দ্ব বিদ্যমান তা দেখতে মার্জটি ড্রাই-রান করুন৷
4. `--মোড কিপ-টার্গেট`-এর সাথে একীভূত করুন, যা লক্ষ্য অনুপস্থিত উৎস থেকে সারি সন্নিবেশিত করে এবং উভয় ডাটাবেস ভাগ করে নেওয়া যেকোনো সারির লক্ষ্যের সংস্করণ সংরক্ষণ করে।
5. দ্বিতীয় উৎসের জন্য পুনরাবৃত্তি করুন।
6. পর্যবেক্ষণ এবং সত্তা গণনা যাচাই করুন।
7. সার্ভার রিস্টার্ট করুন।

প্রাথমিক একত্রীকরণ বৃহত্তম ব্যাকআপ থেকে 6,174 টি পর্যবেক্ষণ এনেছে। সেকেন্ডারি মার্জ 10 মার্চ উইন্ডো থেকে মোটামুটি আরও 100 যোগ করেছে। চূড়ান্ত গণনা: 6,296টি পর্যবেক্ষণ, 3,951টি সত্তা, 9 ফেব্রুয়ারী থেকে 11 মার্চ পর্যন্ত বিস্তৃত কার্যকলাপ।

পুনঃসূচনা করার পরে, সবকিছু অ্যাক্সেসযোগ্য ছিল তা নিশ্চিত করতে আমি Neotoma MCP এর মাধ্যমে সত্তার নমুনা নিয়েছি। পরিচিতি, কাজ, কথোপকথন, প্রতিক্রিয়া রেকর্ড: সমস্ত উপস্থিত এবং সঠিকভাবে কাঠামোগত।

## কেন এই পুনরুদ্ধার সম্ভব হয়েছিল

নিওটোমার স্থাপত্যের তিনটি বৈশিষ্ট্যের কারণে পুনরুদ্ধার কাজ করেছিল।

**পর্যবেক্ষণ হল সত্যের উৎস।** কিছু পরিবর্তন হলে নিওটোমা একটি সারি ওভাররাইট করে সত্তা সংরক্ষণ করে না। প্রতিটি ঘটনা একটি অপরিবর্তনীয় পর্যবেক্ষণ হিসাবে সিস্টেমে প্রবেশ করে: "অ্যালিসের ইমেল হল alice@example.com, 3 মার্চ Gmail থেকে পর্যবেক্ষণ করা হয়েছে।" সত্তা অবস্থা সম্পূর্ণ পর্যবেক্ষণের সেট থেকে গণনা করা হয়। পর্যবেক্ষণ লগ শুধুমাত্র যোগ করা হয়.

এর মানে হল একটি ডাটাবেস ব্যাকআপ হল প্রতিটি ঘটনা যা সিস্টেমটি দেখেছে তার সম্পূর্ণ স্ন্যাপশট, শুধু সর্বশেষ অবস্থা নয়। যখন আমি লাইভ ডাটাবেসে ব্যাকআপ মার্জ করি, তখন আমি "প্রতিটি সত্তার সর্বশেষ পরিচিত অবস্থা" পুনরুদ্ধার করছি না। আমি পুরো ইতিহাস রিপ্লে করছিলাম।

**সত্তার স্ন্যাপশটগুলি নেওয়া হয়েছে, প্রাথমিক নয়।** পর্যবেক্ষণগুলি একত্রিত করার পরে, নিওটোমা পর্যবেক্ষণ লগ থেকে সত্তার স্ন্যাপশটগুলি পুনরায় গণনা করে৷ প্রতিটি সত্তার জন্য স্ন্যাপশট নির্ধারণমূলক: একই পর্যবেক্ষণ দেওয়া হলে, আপনি সর্বদা একই সত্তা অবস্থা পাবেন। এই কারণেই মার্জ কমান্ডে একটি স্ন্যাপশট পুনর্গণনা পদক্ষেপ অন্তর্ভুক্ত রয়েছে। একবার পর্যবেক্ষণগুলি ঠিক হয়ে গেলে, সংস্থাগুলি নিজেদেরকে সঠিকভাবে পুনর্নির্মাণ করে।

**বিরোধ সনাক্তকরণের সাথে প্রাথমিক-কী একত্রীকরণ।** `merge-db` কমান্ড প্রতিটি টেবিলে চলে, সারিগুলি সন্নিবেশ করায় যা উৎসে বিদ্যমান কিন্তু লক্ষ্য নয়, এবং প্রাথমিক কী দ্বারা বিরোধগুলি পরিচালনা করে। `কিপ-টার্গেট` মোডে, যে কোনো সংঘর্ষে টার্গেটের সংস্করণ জয়ী হয়। ড্রাই-রান মোড প্রিভিউ করে ঠিক কী ঢোকানো হবে এবং আপনার প্রতিশ্রুতি দেওয়ার আগে কী দ্বন্দ্ব হবে। আমি উভয় মার্জের জন্য ড্রাই-রান চালিয়েছি এবং কার্যকর করার আগে দ্বন্দ্ব প্রতিবেদন পর্যালোচনা করেছি।

এই তিনটি বৈশিষ্ট্য একসাথে ডাটাবেসকে এমনভাবে স্ব-নিরাময় করে তোলে যা ঐতিহ্যগত সারি-স্তরের ব্যাকআপগুলি নয়। কোন ব্যাকআপে একটি সত্তার "সঠিক সংস্করণ" আছে তা নিয়ে আপনার চিন্তা করার দরকার নেই৷ আপনি পর্যবেক্ষণ মার্জ, পুনরায় গণনা, এবং সঠিক রাষ্ট্র পড়ে আউট.

## যা শিখেছি

অভিজ্ঞতা কয়েকটি জিনিসকে শক্তিশালী করেছে।

**অনানুষ্ঠানিক ব্যাকআপ ব্যাকআপ না থাকার চেয়ে ভালো।** আমার মাঝে মাঝে ডাটাবেস ফাইল কপি করার অভ্যাস কয়েক মাস কাজ করে। কিন্তু মাঝে মাঝে ম্যানুয়াল কপি একটি সিস্টেম নয়। তারা ফাঁক রেখে যায়। আমি যদি 11 মার্চের পরিবর্তে 7 মার্চ ডাটাবেসটি মুছে ফেলতাম, তবে আমি 28 ফেব্রুয়ারি থেকে 7 মার্চ পর্যন্ত ডেটা হারিয়ে ফেলতাম কারণ কোনও কপি সেই উইন্ডোটিকে সম্পূর্ণরূপে কভার করেনি। আমি এখন আমার ম্যাকে টাইম মেশিন দিয়ে স্বয়ংক্রিয় দৈনিক ব্যাকআপ সেট আপ করছি।

**এনভি পতাকা ভুল একটি ক্লাসিক।** প্রতিটি সিস্টেম যা dev এবং prod পরিবেশে কাজ করে এই ঝুঁকি বহন করে। প্রশমন হল ধ্বংসাত্মক ক্রিয়াকলাপের জন্য নিশ্চিতকরণ প্রম্পট, রঙ-কোডেড টার্মিনাল প্রম্পট, বা পরিবেশ প্রতি পৃথক শংসাপত্র। এই ঘটনার পর আমি 'নিওটোমা রিসেট'-এ একটি বাধ্যতামূলক নিশ্চিতকরণ যোগ করি যখনই এটি একটি উত্পাদন পরিবেশ সনাক্ত করে। পণ্যের জন্য `-y` পতাকা উপেক্ষা করা হয়েছে। আপনি "নিওটোমা রিসেট (উৎপাদন)" এবং কিছু ঘটার আগে একটি সতর্কতা দেখতে পাচ্ছেন।

**ইভেন্ট-সোর্সড আর্কিটেকচার পুনরুদ্ধারে অর্থ প্রদান করে।** যদি নিওটোমা জায়গায় সারিগুলি ওভাররাইট করে সত্তা সঞ্চয় করে, তবে একটি ডাটাবেস মুছা একটি ডেটা ক্ষতির ঘটনা হবে যেখানে কোনও পরিষ্কার পুনরুদ্ধারের পথ নেই। যেহেতু পর্যবেক্ষণগুলি অপরিবর্তনীয় এবং সত্তা অবস্থা উদ্ভূত হয়, পুনরুদ্ধার একটি মার্জ-এবং-পুনঃগণনা অপারেশন। পর্যবেক্ষন লগই স্থল সত্য। এটি থেকে অন্য সবকিছু পুনর্নির্মাণ করা যেতে পারে।

**আমি যে সরঞ্জামগুলি তৈরি করছিলাম তা পরীক্ষা করে দেখেছি৷** আমি একটি ভিন্ন ব্যবহারের ক্ষেত্রে কয়েক মাস আগে `merge-db` কমান্ড লিখেছিলাম: একাধিক নিওটোমা দৃষ্টান্ত চালিত ব্যবহারকারীদের থেকে ডেটা একত্রিত করে৷ আমি আমার নিজের উত্পাদন ডেটাতে এটি ব্যবহার করার আশা করিনি। কিন্তু যেহেতু টুলটি বিদ্যমান ছিল এবং বিরোধের সমাধান এবং স্ন্যাপশট পুনর্গণনা পরিচালনা করেছে, পুনরুদ্ধারটি চাপের পরিবর্তে যান্ত্রিক ছিল।

## আপনার ডেটা আপনার ভুল থেকে বাঁচতে হবে

এই ঘটনাটি সেই ফাঁকগুলিকে উন্মোচিত করেছে যা Neotoma বন্ধ করা উচিত তাই ব্যবহারকারীদেরকে আমি নিজে যা করেছি তা কখনই করতে হবে না।

**স্বয়ংক্রিয় স্ন্যাপশট।** নিওটোমা একটি সময়সূচীতে এবং কোনো ধ্বংসাত্মক অপারেশনের আগে ডাটাবেসের স্ন্যাপশট করা উচিত। টাইমস্ট্যাম্পড কপিগুলির একটি ঘূর্ণায়মান সেট, 30 দিনের জন্য রাখা হয়। আপনি যদি ভুলবশত প্রোড-এ রিসেট চালান, প্রি-রিসেট স্ন্যাপশট ঠিক সেখানেই রয়েছে। আপনি সেই সপ্তাহে `cp` চালানোর কথা মনে রেখেছিলেন কিনা তার উপর পুনরুদ্ধার নির্ভর করবে না।

**অ্যানোমালি ডিটেকশন।** হাজার হাজার পর্যবেক্ষণ থেকে হঠাৎ করে শূন্যের কাছাকাছি নেমে আসা স্বাভাবিক নয়। নিওটোমা এই প্যাটার্নটি সনাক্ত করতে পারে এবং প্রতিশ্রুতি দেওয়ার আগে নিশ্চিত করতে পারে। একটি সাধারণ হিউরিস্টিক, "এই অপারেশনটি 90% এর বেশি পর্যবেক্ষণগুলি সরিয়ে দেবে, নিশ্চিত করুন?" সম্পূর্ণরূপে আমার নিশ্চিহ্ন প্রতিরোধ করা হবে.

**এজেন্ট-চালিত পুনরুদ্ধার।** যেহেতু এজেন্টরা নিওটোমার প্রাথমিক UX, তাই এজেন্টদের মাধ্যমেও পুনরুদ্ধারের কাজ করা উচিত। আপনি আপনার এজেন্টকে বলুন "আমার ডাটাবেস ভুল দেখাচ্ছে, আমি মনে করি আমি ডেটা হারিয়েছি।" এজেন্ট পর্যবেক্ষণ গণনা পরীক্ষা করে, উপলব্ধ স্ন্যাপশটগুলি খুঁজে পায়, তারিখের সীমার তুলনা করে এবং MCP এর মাধ্যমে একত্রিত হওয়ার মাধ্যমে আপনাকে নিয়ে যায়। কোন CLI স্পেলঙ্কিং এর প্রয়োজন নেই।

**রিমোট সিঙ্ক।** স্থানীয় ব্যাকআপ দুর্ঘটনাজনিত ওভাররাইট থেকে রক্ষা করে কিন্তু ডিস্ক ব্যর্থতা নয়। নিওটোমা একটি দূরবর্তী অবস্থানে পর্যবেক্ষণ লগ সিঙ্ক করা সমর্থন করবে: একটি ক্লাউড বালতি, একটি দ্বিতীয় মেশিন, বা একটি স্ব-হোস্টেড সার্ভার৷ যেহেতু পর্যবেক্ষণগুলি শুধুমাত্র যোগ করা হয়, তাই সিঙ্ক মডেলটি সহজ। রিমোটে নতুন পর্যবেক্ষণ পাঠান। উভয় প্রান্তে সত্তা রাষ্ট্র পুনর্গঠন.

একই আর্কিটেকচার যা এই পুনরুদ্ধারকে সম্ভব করেছে এই বৈশিষ্ট্যগুলিকে সহজভাবে তৈরি করে। শুধুমাত্র-সংযোজন-পর্যবেক্ষন, প্রাপ্ত অবস্থা, এবং নির্ধারক পুনঃগণনা শুধুমাত্র পুনরুদ্ধারের বৈশিষ্ট্য নয়। তারা প্রথম শ্রেণীর গ্যারান্টি হিসাবে ব্যাকআপ, সিঙ্ক এবং স্ব-নিরাময়ের ভিত্তি।

## সংখ্যা

| মেট্রিক | মোছার আগে | মোছার পর | পুনরুদ্ধারের পর |
|---|---|---|---|
| পর্যবেক্ষণ | 6,174 | 84 | 6,296 |
| সত্তা | 3,862 | 67 | 3,951 |
| তারিখ পরিসীমা | ফেব্রুয়ারী 9 থেকে 9 মার্চ | 10 মার্চ থেকে 11 মার্চ | ফেব্রুয়ারী 9 থেকে মার্চ 11 |

চূড়ান্ত গণনা প্রাক-মুছার গণনার চেয়ে বেশি কারণ তিনটি উত্স থেকে একত্রিত পর্যবেক্ষণগুলি একত্রিত করে: দুটি ব্যাকআপ ফাইল এবং টিকে থাকা পোস্ট-ওয়াইপ ডেটা। কিছু পর্যবেক্ষণ যা শুধুমাত্র 10 মার্চ ব্যাকআপে বা শুধুমাত্র লাইভ ডাটাবেসে বিদ্যমান ছিল সেগুলি মূল বৃহত্তম ব্যাকআপে ছিল না।

যদি আপনার মেমরি সিস্টেম পরিবর্তনযোগ্য অবস্থা ব্যবহার করে, একটি মুছা স্থায়ী হয়। যদি এটি প্রাপ্ত সত্তা অবস্থার সাথে একটি শুধুমাত্র-সংযোজন-পর্যবেক্ষণ লগ ব্যবহার করে, তাহলে একটি মুছা সম্পূর্ণ পুনরুদ্ধার থেকে একত্রিত হওয়া। এই পার্থক্যটি গুরুত্বপূর্ণ যখন ডেটা আপনার পরিচিতি, আপনার প্রতিশ্রুতি, শত শত সেশন জুড়ে এজেন্টদের সাথে আপনার ইতিহাস।

নিওটোমা হল [GitHub-এর ওপেন সোর্স](https://github.com/neotoma-app/neotoma)। আপনি যদি একটি মেমরি স্তর চান যেখানে আপনার ডেটা আপনার সবচেয়ে খারাপ ভুল থেকে বাঁচতে পারে, [এটি চেষ্টা করুন](https://neotoma.io/install)।