Database সরল, পুরোনো Client সরেনি — NovaCommerce ৩

5 October 2026 রাত 22:59-এ database window শেষ হয়। 26 মিনিট পর site সচল। 23:24-এ ধরা পড়ে, একটি legacy admin panel এখনও পুরোনো database-এ লিখছে। Application সরেছে, কিন্তু সব writer সরেনি।

NovaCommerce একটি course ও exam platform-এর গোপনীয়তা রক্ষার নাম। তৃতীয় পর্বে September–October-এর বিদ্যমান record রেখে তার চারপাশের technical guidance সংশোধন করা হয়েছে। পুরোনো সংখ্যাগুলো নতুন production audit বা StoreConsole benchmark নয়।

ছোট দুটি node ভিন্ন ঝুঁকির উত্তর দিয়েছে

পুরোনো managed MySQL ছিল 8 vCPU/32 GB-এর একটি node, standby ছিল না। নতুন ঐতিহাসিক setup: MySQL 8.4 Standard, প্রতি node 4 vCPU/16 GB, primary ও standby; data প্রায় 11 GB। এতে single-node failure সামলানোর পথ পাওয়া যায়, zero data loss, instant failover বা regional recovery প্রমাণ হয় না।

Pair-এর প্রায় $389/month পুরোনো budget, বর্তমান offer নয়। DigitalOcean-এর বর্তমান নথিতে 15 October 2026 থেকে নতুনভাবে প্রযোজ্য account এবং 30 November থেকে সব account-এর Standard Edition restriction আছে। একই setup নেওয়ার আগে account, plan ও standby eligibility দেখুন। ভুল delete-ও standby-তে যায়; standby backup নয়।

কিছু validation সফল, একটি writer বাদ

Record-এ 22:33 maintenance routing, queue drain, scheduler বন্ধ, 30 seconds write না দেখা, প্রায় দশ মিনিট copy, validation ও নতুন app image দিয়ে 22:59-এ ফেরার কথা আছে। কিছুক্ষণ চুপ থাকা write fence নয়; ভুলে যাওয়া client পরে লিখতে পারে। Web, worker, scheduler, callback, import ও বাইরের panel-এর তালিকা করে consistent copy-এর আগে পুরোনো write বন্ধ করুন।

Case-এ table/row count match, পরে content check এবং বড় results table বিস্তারিত মিলানোর কথা আছে। কোন snapshot ও পদ্ধতিতে কী মেলানো হয়েছে তার evidence রাখুন। Count সমান মানেই content সমান নয়; cutover-এর পর comparison-এ reconciliation boundary লাগবে। Role, schema, ব্যবহৃত routine/event, charset এবং আসল answer-save/read flow দেখুন। Standard mysqldump parallel dump engine নয়; অজানা multi-stream wrapper-কে reproducible consistency recipe বলবেন না।

পুরোনো observation	Recorded value	যা প্রমাণ হয় না
Copy total	341 table; 18,727,244 row	সমান count ≠ সমান business state
বড় results comparison	প্রায় 2.76 million row	পদ্ধতি ও scope রাখতে হবে
খোলার পর প্রথম চার মিনিট	প্রায় 2,900 request; 0 5xx	পরের সব flow বা writer নয়
Legacy late write	48 =44 merged +4 retained	সর্বজনীন merge policy নয়
শুধু web connection estimate	10 ×80 =800	Read/write, worker ও overlap বাদ

শেষের 48 row rollback-এর অর্থ বদলেছে

Legacy panel পুরোনো দিকে 48 row লেখে। পুরোনো incident repair-এ 44 merge এবং destination-এর নতুন চারটি version রাখা হয়; panel সরিয়ে old credential বদলানো হয়। 44+4=48 এই incident-এর হিসাব, সর্বজনীন latest timestamp wins policy নয়। Clock, delete, dependent row ও concurrent edit business rule মেনে audit trail-সহ reconcile করতে হয়।

বাদ পড়া writer বন্ধ করে existing connection terminate বা fence করুন; শুধু password বদলালে আগে authenticated session বন্ধ নাও হতে পারে। Old write সত্যিই denied কি না দেখুন। পুরোনো cluster 48 ঘণ্টা frozen রাখা হয়েছিল। নতুন দিকে write শুরু হলে এটি recovery material, current rollback destination নয়। নতুন answer না মিলিয়ে ফিরলে accepted work হারাতে পারে। Retention recovery test ও obligation অনুযায়ী হবে; 48 ঘণ্টা universal rule নয়।

Read replica-এর সঙ্গে freshness contract চাই

Case-এ standby ও primary read host, write শুধু primary, worker-এর read-ও primary ছিল। Supported standby-read endpoint paid capacity ব্যবহার করতে পারে; কিন্তু recovery resource-ও share করে। Provider support, lag ও failure behaviour যাচাই করুন। Dedicated reader সব সময় অপচয় নয়।

Laravel sticky=true একই request-এ write-এর পরের read primary-তে রাখে। একা এটি পরের request বা পুরো session রক্ষা করে না। Cross-request freshness-এর tested mechanism বা authoritative answer-এর জন্য primary read দরকার। একাধিক read host থাকলেই সব query-এর two-second failover বা safe replay নিশ্চিত হয় না। Connection failure এবং execute হয়ে যাওয়া query আলাদা করে test করুন।

পুরোনো 10 node ×80 PHP-FPM child=800 হিসাব child-পিছু একটি connection ধরে। Read ও write মিলিয়ে দুটি হলে 1,600—worker, admin বা rolling overlap-এর আগেই; ঐতিহাসিক limit 1,601। প্রতিটি connection source ও পুরোনো-নতুন node একসঙ্গে থাকার budget ধরুন। Connection ceiling throughput guarantee নয়।

Vector workload আলাদা, সব coupling শেষ নয়

AI embedding আলাদা PostgreSQL 17/pgvector instance-এ ছিল, ঐতিহাসিক size 2 vCPU/4 GB। 1 vCPU/2 GB trial workload-এর জন্য ফিরিয়ে নেওয়া হয়। আলাদা instance CPU/memory budget দেয়; shared app pool, network বা provider failure এখনও প্রভাব ফেলতে পারে। এটি workload choice; সব MySQL offering-এ vector capability নেই—এমন দাবি নয়।

7 October exam record-এ MySQL max CPU 24.5%, average 13.4%, সর্বোচ্চ পাঁচ running query ও zero observed lock wait ছিল। ওই window-তে ওই signal saturated হয়নি—এতটুকু বলা যায়। এখান থেকে 450 requests/s ceiling বা ছয়গুণ capacity প্রমাণ হয় না; query mix, write contention, I/O ও failover ফল বদলায়।

App-এর least-privilege credential migration rights থেকে আলাদা রাখুন, database access সীমিত করুন এবং application check-সহ backup restore মেপে দেখুন। Configured standby, successful copy ও successful restore আলাদা তিন প্রমাণ। পরের পর্বে queue ও worker-এর গল্প।

সিরিজ

• পর্ব 1
• পর্ব 2
• পর্ব 3
• পর্ব 4
• পর্ব 5

মূল তথ্যসূত্র

• DigitalOcean: MySQL standby nodes and reads
• DigitalOcean: current MySQL plan limits
• Laravel: read/write connections and sticky reads
• MySQL 8.4: mysqldump
• DigitalOcean: restore MySQL backups
• pgvector: supported search and filtering

পর্যালোচনা: ৬ নভেম্বর ২০২৬। Anichur Rahaman, StoreConsole প্রতিষ্ঠাতা। Case-এর সংখ্যা ও price ঐতিহাসিক; বর্তমান মূল সূত্র technical qualification সমর্থন করে।