Database Replication: read replica, lag ও failover
Replication, Read Replicas, and Failover
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Primary, replica ও lag
- Read-after-write routing
- Failover, fencing ও backup-এর পার্থক্য
সমস্যা দিয়ে শুরু
Customer order তৈরি করে সঙ্গে সঙ্গে detail page-এ গেলেন, কিন্তু 404 পেলেন। Write primary-তে commit হয়েছে, read গেছে পিছিয়ে থাকা replica-তে। Database replication read capacity ও recovery options দেয়, কিন্তু user-visible consistency contract বদলাতে পারে। Read replica যোগ করার আগে কোন read কতটা fresh হতে হবে তা জানতে হয়।
সহজ করে বুঝি
Primary write history replica-তে পাঠায়। Async replication-এ acknowledgement replica apply-এর আগে আসতে পারে। Sync mode অতিরিক্ত replica acknowledgement চাইতে পারে, তবে exact durable/apply boundary product configuration অনুযায়ী। Replica stale read দিতে পারে; primary failover-এ recent write loss সম্ভাবনা replication mode-এর সঙ্গে বিচার করুন। Read replication write capacity-এর universal solution নয়। Replication accidental delete-ও copy করে; তাই backup-এর বিকল্প নয়।
পরিচিত একটি উপমা
দোকানের মূল খাতার copy অন্য branch-এ যায়। Copy দিয়ে inquiry দ্রুত হয়, কিন্তু নতুন sale এখনো লেখা না থাকলে customer receipt খুঁজে পাবেন না। ভুল করে মূল খাতা থেকে entry মুছলে copy-তেও সেই ভুল যায়; আলাদা dated backup দরকার।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD W[Order write] --> P[(Primary)] P -->|Asynchronous log replay| R[(Read Replica)] F[Freshness sensitive read] --> P A[Stale tolerant catalog read] --> R P --> B[(Independent tested backups)]
Order write primary-তে যায়। Fresh order detail primary read করলে replica lag-এর 404 এড়ানো যায়। Stale-tolerant catalog replica থেকে আসতে পারে। Backup arrow independent retention বোঝায়; continuous replication নিজে historical restore point নয়। Failover হলে old primary আবার write নিতে না পারে তা control plane ও fencing দিয়ে নিশ্চিত করতে হয়।
PHP ও Laravel-এ প্রয়োগ
Laravel read/write connections config আছে ধরে service fragment। useWritePdo query-কে write connection-এ পাঠায়। User-scoped query authorization বজায় রাখে। sticky configuration একই request-এর write-এর পর read routing সাহায্য করতে পারে, কিন্তু next browser request বা অন্য service-এর causal session নিজে নিশ্চিত করে না।
use App\Models\Order;
$order = Order::query()
->useWritePdo()
->where('user_id', $userId)
->findOrFail($orderId);
return response()->json([
'id' => $order->id,
'status' => $order->status,
]);সুবিধা, সীমাবদ্ধতা ও trade-off
Replica read-heavy workload distribute করে এবং failover candidate দেয়। Lag, monitoring ও routing complexity বাড়ে। সব read primary-তে দিলে simple consistency মেলে, scaling benefit কমে। Sync replication write latency ও availability trade-off আনে। Geographic replicas দূরের read দ্রুত করতে পারে, তবে cross-region write acknowledgement ও failure recovery requirement ব্যয়বহুল হতে পারে।
সাধারণ ভুল
- Read replica-কে zero-lag data source ধরে নেওয়া।
- Replication আছে বলে backups বাদ দেওয়া।
- Old primary fence না করেই new primary promote করা।
আরও একটু গভীরে
Lag শুধু seconds নয়: byte backlog, apply delay ও user-level freshness symptom দেখুন। Long query replica replay conflict বা lag বাড়াতে পারে, engineভেদে। Failover runbook-এ detection, promotion, routing update, stale connection reset এবং validation রাখুন। Read-after-write client token বা commit position-based wait দিয়ে করা যায়, কিন্তু product-specific support ও timeout policy লাগে। Critical balance/stock decision stale replica থেকে করবেন না।
মনে রাখুন
Replication copy distribution; consistency routing design-এর অংশ। Freshness-sensitive read primary বা verified caught-up path নিক। Backup, failover ও fencing আলাদা পরীক্ষা করুন।
নিজে চেষ্টা করুন
Staging-এ replica apply delay দিয়ে order create ও detail read চালান। Default read এবং useWritePdo behavior তুলনা করুন। Primary হারালে RPO/RTO assumptions, promotion authority এবং old-primary isolation-এর checklist লিখুন।
নিজের বোঝা যাচাই করুন
1. Replica কেন 404 দেয়?
Order commit replica-তে replay না হলে query row পায় না। Write success আর সব replica-তে visibility একই সময়ে হয় না।
2. Sticky next request-এ থাকে?
Laravel sticky option সাধারণত বর্তমান request-এর write/read routing-এর জন্য। Cross-request guarantee আলাদা design চাইতে পারে।
3. Replica backup?
না। Delete/corruption replicate হতে পারে। Independent retained backups ও restore tests দরকার।
4. Sync replication loss শূন্য?
Exact acknowledgement boundary ও failure model পড়তে হবে। Configuration না দেখে universal no-loss দাবি করা যাবে না।
5. Split brain কেন বিপজ্জনক?
দুই primary আলাদা writes নিলে history diverge ও invariant ভাঙতে পারে। Promotion authority ও fencing old writer বন্ধ রাখতে সাহায্য করে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।