Downtime ছাড়া নিরাপদ database migration

অসাবধান migration একটি table lock করে সাইট নামিয়ে দিতে পারে। Expand ও contract pattern এবং schema বদল একঘেয়ে করার যাচাইগুলো শিখুন।

ছোট নিরাপদ ধাপে বদলানো একটি schema

Migration database-এর গঠন বদলায় (column যোগ, index, table-এর নাম বদল)। চালু সিস্টেমে অসাবধান migration বড় table মিনিটের পর মিনিট lock করতে, চলমান কোড ভাঙতে বা data হারাতে পারে।

মূল সমস্যা

Deploy-এর সময় পুরোনো কোড ও নতুন কোড একসাথে চলে, আর database দুটোর জন্যই কাজ করতে হবে। তাই প্রতিটি schema বদল এখন চালু কোডের সাথে backward compatible হতে হবে।

Expand ও contract pattern

ঝুঁকিপূর্ণ বদলকে কয়েকটি নিরাপদ ধাপে ভাঙুন, প্রতিটি আলাদা deploy করে।

উদাহরণ: users.name-কে users.full_name নাম দেওয়া।

  1. Expand: নতুন column full_name যোগ করুন (nullable)। পুরোনো কোড চলতে থাকে।
  2. দুটোতেই লিখুন: এমন কোড deploy করুন যা দুই column-এ লেখে এবং পুরোনোটি পড়ে।
  3. Backfill: পুরোনো data নতুন column-এ কপি করুন, ছোট batch-এ।
  4. Read বদলান: কোড deploy করুন যা full_name পড়ে।
  5. পুরোনো column-এ লেখা বন্ধ করুন।
  6. Contract: কিছুই এটি ব্যবহার করছে না নিশ্চিত হয়ে পরের migration-এ name মুছুন।

একটি RENAME-এর চেয়ে ধীর, কিন্তু চলমান কোড ভাঙার কোনো মুহূর্ত থাকে না।

যে কাজ ক্ষতি করতে পারে

  • Index যোগ কিছু database-এ write lock করে। PostgreSQL-এ CREATE INDEX CONCURRENTLY ব্যবহার করুন। MySQL-এ online DDL বিকল্প।
  • Default-সহ column যোগ পুরোনো PostgreSQL সংস্করণে পুরো table নতুন করে লিখত; নতুন সংস্করণ সাধারণ ক্ষেত্র নতুন করে না লিখেই সামলায়। আপনার সংস্করণ দেখুন।
  • NOT NULL বা foreign key constraint যোগ table স্ক্যান করে। সমর্থিত হলে আগে unvalidated যোগ করে আলাদা validate করুন।
  • Column-এর ধরন বদল প্রায়ই table নতুন করে লেখে।
  • Column মোছা বা নাম বদল যে কোড এখনও ব্যবহার করে তা ভাঙে।

Backfill

এক transaction-এ এক কোটি row আপডেট করবেন না। Batch-এ (কয়েক হাজার row) প্রক্রিয়া করুন, মাঝে commit করুন, অল্প বিরতি দিন, এবং কাজটি আবার চালু করার যোগ্য রাখুন। ব্যস্ত সময়ের বাইরে চালান।

নিজেকে রক্ষা করুন

  • শুরুর আগে backup নিন এবং restore জানুন।
  • lock_timeout দিন, যাতে migration দীর্ঘ transaction-এর পেছনে অপেক্ষা করে সবাইকে আটকে না রেখে দ্রুত ব্যর্থ হয়।
  • প্রোডাকশন-আকারের data-সহ কপির ওপর পরীক্ষা করুন।
  • Migration ছোট, পর্যালোচিত ও version control-এ রাখুন, এবং হাতে নয়, টুল দিয়ে চালান।
  • Rollback পরিকল্পনা রাখুন। অনেক data বদল সত্যিই ফেরানো যায় না, তাই সামনের দিকের সংশোধনই আসল rollback হতে পারে।
  • একাধিক server-এর deploy-এ migration অ্যাপ চালুর থেকে আলাদা চালান, যাতে দুবার না চলে।

SQLite সংক্রান্ত

SQLite কম ALTER TABLE অপারেশন সমর্থন করে। বড় বদল নতুন table বানিয়ে, data কপি করে, বদলিয়ে করা হয়। আগে ফাইলের কপি নিন।

মূল কথা: প্রতিটি বদল backward compatible রাখুন, ঝুঁকিপূর্ণ বদল expand ও contract ধাপে ভাঙুন, backfill batch-এ করুন, এবং সবসময় backup ও lock timeout রাখুন।


Backend ও Database সিরিজ, পর্ব ২ (performance ও operations): 5 নম্বর (মোট 6)। আগের লেখা: PostgreSQL বনাম MySQL বনাম SQLite: কোনটি বাছবেন.

আরও পড়ুন

Recursion ও backtracking সহজ উদাহরণে

Recursion সমস্যার ছোট কপি সমাধান করে সমাধান করে। অনেক interview সমস্যায় ব্যবহৃত চিন্তার ধাপ ও backtracking টেমপ্লেট শিখুন।

Interview ও DSA•৩ মিনিটে পড়া