Database Replication
- ●Replication মানে একই data একাধিক সার্ভারে রাখা—যাতে availability, read scaling আর durability বাড়ে।
- ●Leader-follower-এ leader write নেয় আর follower-রা copy করে read সামলায়; lag হলো follower-এর পিছিয়ে থাকা।
- ●Sync replication নিরাপদ কিন্তু slow, async দ্রুত কিন্তু data হারানোর ঝুঁকি; failover দিয়ে leader fail সামলানো হয়।
সমস্যাটা কী?
তোমার e-commerce site-এর পুরো database একটামাত্র সার্ভারে আছে। এক বিকেলে সেই সার্ভারের hard disk নষ্ট হয়ে গেল। ফলাফল—site পুরো বন্ধ, এবং সম্ভবত data-ও হারিয়ে গেল। আবার ভাবো, ঈদের সেল চলছে, লাখ লাখ মানুষ একসাথে product দেখছে (read)। একটা সার্ভার এত read সামলাতে পারছে না, সব slow হয়ে যাচ্ছে।
দুটো সমস্যারই মূল কারণ এক—সব ডিম এক ঝুড়িতে। সমাধান হলো একই data একাধিক সার্ভারে কপি করে রাখা, যাকে বলে Replication। একটা গেলে অন্যটা থাকবে (availability), আর read-গুলো ভাগ করে দেওয়া যাবে (scaling)।
মূল ধারণা
Database replication হলো একই data-র একাধিক copy বিভিন্ন সার্ভারে (replica) রাখার প্রক্রিয়া, যাতে এক সার্ভার fail করলেও সিস্টেম চালু থাকে, পড়ার কাজ একাধিক সার্ভারে ভাগ করা যায় এবং data হারানোর ঝুঁকি কমে।
Replication কেন করি, তিনটি বড় কারণ:
- Availability: একটা node fail করলে অন্য copy থেকে সেবা চলতে থাকে।
- Read scaling: read traffic একাধিক replica-তে ভাগ করে দেওয়া যায়।
- Durability: data একাধিক জায়গায় থাকায় হঠাৎ একটা disk/datacenter গেলেও data বেঁচে যায়। (পাশাপাশি ভৌগোলিকভাবে কাছের replica থেকে data দিলে latency-ও কমে।)
কীভাবে কাজ করে
মূল ধারণা: এক জায়গায় write হলে সেই পরিবর্তন বাকি copy-গুলোতে পৌঁছে দিতে হবে।
Leader-Follower (Master-Slave)
সবচেয়ে প্রচলিত মডেল। একটা সার্ভার হয় leader (master), বাকিরা follower (replica/slave)।
- সব write শুধু leader-এ যায়।
- Leader তার data পরিবর্তনগুলো একটা replication log/stream আকারে follower-দের পাঠায়।
- Follower-রা সেই পরিবর্তন নিজেদের copy-তে প্রয়োগ করে।
- Read request follower-দের মধ্যে ভাগ করে দেওয়া হয় (কখনো leader থেকেও)।
| ভূমিকা | Write নেয়? | Read দেয়? | উদ্দেশ্য |
|---|---|---|---|
| Leader | হ্যাঁ | হ্যাঁ (ঐচ্ছিক) | সব পরিবর্তনের উৎস |
| Follower | না | হ্যাঁ | Read scaling, backup |
Sync vs Async Replication
Leader কখন client-কে "write হয়ে গেছে" বলবে?
| ধরন | Leader কখন OK বলে | সুবিধা | অসুবিধা |
|---|---|---|---|
| Synchronous | অন্তত একটা follower confirm করার পর | Follower-এ data নিশ্চিত, leader গেলেও data নিরাপদ | Write ধীর; follower slow হলে leader আটকে যায় |
| Asynchronous | নিজে লেখার সাথে সাথেই | দ্রুত write, follower slow হলেও সমস্যা নেই | Leader হঠাৎ crash করলে কিছু সাম্প্রতিক write হারাতে পারে |
বাস্তবে অনেকে semi-synchronous ব্যবহার করে—একটা follower sync, বাকিরা async—যাতে speed ও safety দুটোরই ভারসাম্য থাকে।
Replication Lag
Async-এ follower leader-এর থেকে কিছুটা পিছিয়ে থাকে—এই দেরিকে Replication Lag বলে। সাধারণত মিলিসেকেন্ড, কিন্তু load বা network সমস্যায় কয়েক সেকেন্ড পর্যন্ত হতে পারে।
ভাবো একজন প্রধান শিক্ষক (leader) ক্লাসের রেজাল্ট মূল খাতায় লেখেন। তিন জন সহকারী (follower) সেই খাতা দেখে নিজেদের কপি বানায়, যাতে অভিভাবকরা যেকোনো সহকারীর কাছ থেকে রেজাল্ট জানতে পারেন (read scaling)। কিন্তু সহকারীরা একটু পরে কপি করে—তাই এইমাত্র যোগ হওয়া নম্বর কোনো সহকারীর কাছে এখনো নেই (replication lag)। প্রধান শিক্ষক অসুস্থ হলে (leader fail) একজন সহকারীকে দায়িত্ব দেওয়া হয় (failover)।
প্রকারভেদ ও সম্পর্কিত সমস্যা
Multi-Leader Replication
একাধিক leader একসাথে write নেয়—সাধারণত যখন একাধিক datacenter বা offline-capable app থাকে। সুবিধা: প্রতিটি অঞ্চলে কাছের leader-এ লেখা যায়, latency কম। অসুবিধা: দুই leader একই data একসাথে বদলালে write conflict হয়, যা resolve করা কঠিন।
Read-after-write Consistency
ধরো user নিজের profile update করল (write leader-এ গেল) কিন্তু সাথে সাথে page refresh-এ পুরোনো data-ওয়ালা follower থেকে read এলো—সে নিজের পরিবর্তনই দেখল না! এই বিভ্রান্তি ঠেকাতে Read-after-write কৌশল লাগে: একই user-এর সাম্প্রতিক write-এর পরের কিছু read leader থেকে (বা যথেষ্ট-আপডেটেড replica থেকে) দেওয়া হয়, যাতে সে নিজের পরিবর্তন অন্তত দেখতে পায়।
Failover
Leader fail করলে একটা follower-কে নতুন leader বানানো হয়—এটাই Failover। ধাপগুলো: (১) leader মারা গেছে শনাক্ত করা, (২) সবচেয়ে আপডেটেড follower বেছে নেওয়া, (৩) তাকে leader ঘোষণা করে বাকিদের তার দিকে পাঠানো।
কখন ব্যবহার করবে / করবে না
Read-heavy application (যেমন news, e-commerce browsing) আর high-availability দরকার এমন প্রায় সব production system-এ replication থাকা উচিত। কিন্তু এটা write scaling-এর সমাধান নয়—write তো এখনো এক leader-এই যাচ্ছে। Write প্রচুর হলে দরকার sharding/partitioning, replication নয়।
Async failover-এ একটা বিপজ্জনক ফাঁদ আছে। Leader crash করার ঠিক আগে যে write-গুলো এখনো follower-এ পৌঁছায়নি, failover-এর পর সেগুলো চিরতরে হারিয়ে যেতে পারে। আবার পুরোনো leader ফিরে এসে যদি নিজেকেই leader ভাবে, তখন দুই leader তৈরি হয়ে split-brain ঘটতে পারে। তাই automatic failover সাবধানে ডিজাইন করতে হয় এবং প্রায়ই consensus (যেমন Raft) দিয়ে leader নির্বাচন করা হয়।
বাস্তব উদাহরণ
- MySQL / PostgreSQL: দুটোতেই built-in leader-follower replication আছে; অসংখ্য কোম্পানি একটা primary-তে লেখে আর কয়েকটা read replica-তে পড়ার কাজ ভাগ করে।
- GitHub: তাদের MySQL infrastructure-এ একটা বিখ্যাত ঘটনা ঘটেছিল যেখানে replication lag ও failover ভুল হ্যান্ডেল হওয়ায় কয়েক ঘণ্টা সমস্যা হয়—এটা failover কতটা সংবেদনশীল তার বড় উদাহরণ।
- MongoDB Replica Set: ৩টি node নিয়ে চলে—একটা primary (leader), দুটো secondary (follower)—এবং primary fail করলে স্বয়ংক্রিয়ভাবে নতুন primary নির্বাচন (election) করে failover সম্পন্ন করে।
Interview-তে "database কীভাবে scale করবে?" জিজ্ঞেস করলে প্রথমেই read replica-র কথা বলো (read scaling), তারপর স্পষ্ট করো—"write scaling-এর জন্য sharding লাগবে, কারণ replication write-কে scale করে না।" আর consistency-র প্রশ্ন উঠলে replication lag ও read-after-write সমস্যাটা তুলে ধরলে interviewer বুঝবে তুমি বাস্তব trade-off জানো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Leader-follower replication-এ write কে গ্রহণ করে?
2. Replication lag বলতে কী বোঝায়?
3. Synchronous replication-এর প্রধান অসুবিধা কী?