Disaster Recovery: regional failover ও failback
Disaster Recovery and Multi-Region Trade-offs
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Backup restore, pilot light ও warm standby তুলনা
- Regional failover-এর data authority নির্ধারণ
- Failback এবং dependency readiness পরীক্ষা
সমস্যা দিয়ে শুরু
মূল region unavailable। Team অন্য region-এ web server চালালেন, কিন্তু DNS update ধীর, encryption key region-bound এবং payment webhook পুরোনো endpoint-এ যাচ্ছে। Disaster Recovery শুধু database replica নয়; user journey চালানোর সব dependency উদ্ধার করতে হয়। Incident-এ দুটি region writer হয়ে গেলে order conflict ও double charge-এর ঝুঁকি বাড়ে।
সহজ করে বুঝি
DR বড় failure-এর পরে business operation ফেরানোর পরিকল্পনা। Backup-restore কম standby cost কিন্তু বেশি recovery কাজ। Pilot light minimum core রাখে; warm standby reduced-capacity running environment রাখে। Active-active একাধিক region-এ কাজ করে, তবে conflict resolution ও global correctness জটিল। Strategy-এর নাম নয়, achieved RTO/RPO, data ownership ও tested automation দিয়ে বিচার করুন।
পরিচিত একটি উপমা
প্রধান দোকান বন্ধ হলে অন্য শাখা চালানো DR-এর মতো। শুধু খালি ঘর ভাড়া থাকলে চলবে না; stock, cashier permission, supplier contact এবং customer-কে নতুন ঠিকানা জানানোও দরকার। দুই শাখা একই শেষ জিনিস বিক্রি করতে পারে কি না আগেই ঠিক করতে হবে।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD P[Primary region] --> R[Replicated recovery data] R --> S[Standby region] I[Incident decision] --> F[Fence old writer] F --> U[Promote recovery writer] U --> D[Route traffic] D --> V[Validate and reconcile]
Replication recovery region প্রস্তুত রাখে, কিন্তু failover decision আলাদা control path। পুরোনো writer fence বা নিষ্ক্রিয় করে authoritative নতুন writer promote করতে হয়। Routing switch-এর পরে real journey validate করুন। Recent uncertain payment outcome provider-এর সঙ্গে reconcile করুন। Primary ফিরে এলে তা সরাসরি writer করবেন না; failback data convergence এবং authority handover চায়।
PHP ও Laravel-এ প্রয়োগ
Laravel authenticated internal diagnostic route fragment। region config/app.php-তে server-owned metadata। এই response failover execute করে না এবং database authority certify করে না। Production runbook-এ secrets, queue, object storage, DNS ও provider callback readiness আলাদা checklist থাকবে।
use Illuminate\Support\Facades\Route;
Route::get('/internal/recovery-context', function () {
return response()->json([
'region' => config('app.region'),
'release' => config('app.release'),
]);
})->middleware('auth');সুবিধা, সীমাবদ্ধতা ও trade-off
Warm standby recovery time কমাতে পারে কিন্তু ongoing compute ও synchronization cost আছে। Cross-region synchronous writes latency ও partition-time availability বদলায়। Async replication data-loss window রাখে। Active-active read সহজ মনে হলেও multi-writer inventory ও payment correctness কঠিন। Business-এর tolerate করা interruption ও loss দিয়ে complexity budget ঠিক করুন।
সাধারণ ভুল
- DNS switch হলেই সব client তৎক্ষণাৎ নতুন region পাবে ধরা।
- পুরোনো writer বন্ধ না করেই নতুন writer চালানো।
- Standby-তে secrets এবং external integrations পরীক্ষা না করা।
আরও একটু গভীরে
Runbook-এ who declares disaster, who can promote এবং who communicates লিখুন। DNS caching, network access, TLS certificates ও cloud quotas actual recovery time বদলায়। IaC থাকলেও failed region-এর control plane থেকে artifact আনতে হলে dependency cycle হয়। Failback rehearsal-এ recovery region-এর নতুন writes কীভাবে primary-তে ফিরবে এবং duplicate queued work কীভাবে আটকাবে নির্ধারণ করুন।
মনে রাখুন
DR হলো data authority, পূর্ণ dependency readiness এবং measured regional recovery; traffic switch তার মাত্র একটি ধাপ।
নিজে চেষ্টা করুন
একটি দোকানের DR checklist বানান। Database ছাড়া দশটি dependency লিখুন। Primary region আংশিক ফিরে এলে split brain ঠেকানোর rule এবং payment reconciliation-এর owner নির্ধারণ করুন।
নিজের বোঝা যাচাই করুন
1. DR ও high availability এক?
দুটি সম্পর্কিত, তবে DR বড় failure-এর পরে recovery পরিকল্পনায় কেন্দ্রীভূত। Local redundancy সব disaster সামলায় না।
2. Warm standby কি full capacity?
প্রায়ই reduced capacity থাকে। Promotion-এর আগে scaling, quota ও data freshness পরীক্ষা দরকার।
3. Async replica-তে loss হতে পারে?
হ্যাঁ। Unreplicated acknowledged data হারানোর window থাকতে পারে; replication contract ও RPO স্পষ্ট করুন।
4. Fencing কেন?
পুরোনো primary জীবিত থাকলে দুই writer conflict করতে পারে। একক authority বজায় রাখতে তা আটকানো দরকার।
5. Failback সহজ restart?
না। Recovery region-এ নতুন data হয়েছে। Convergence, routing এবং writer handover controlled করতে হয়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।