আমার পলিটেকনিকের একটা বাজে ঘটনা শেয়ার করি, তারপর মূল বিষয়ে কথা শুরু করি। পলিটেকনিকে উপবৃত্তি দেয় এটা সবাই হয়তো জানেন। সেটার জন্য স্টুডেন্টদেরকে এক গাদা তথ্য—মোটামুটি ৬-৭টা ডকুমেন্ট সাবমিট করতে হয়। এখন আমি সাবমিট করেছি সেই ১ম সেমিস্টারে। এখন হঠাৎ করে ডিপার্টমেন্ট থেকে নোটিশ দিয়েছে যে আবার এই ডকুমেন্ট সাবমিট করতে হবে। কেন করতে হবে?
স্টুডেন্টদের এই সম্পর্কিত ডকুমেন্টগুলো নাকি সব missing! এখন আপনার মেজাজ কেমন হবে? আমি ঐ সময় আমার মেজাজটা হারিয়েছিলাম। এরকম ঘটনা কিন্তু প্রতিদিনই ঘটছে।
এখন কর্তৃপক্ষ যদি এই ডাটাগুলো ব্যাকআপ করে রাখতো তাহলে কিন্তু এই ঝামেলাগুলো স্টুডেন্টদেরকে পোহাতে হতো না। কিন্তু সরকারি কার্যকলাপ তো, এগুলো হওয়া না হওয়া একই কথা।

এখন মনে করুন, একই ঘটনা আপনার একটা real application-এ ঘটলো। User-দের data হঠাৎ করে গায়েব হয়ে গেলো! কী লেভেলের chaos তৈরি হতে পারে! এই জন্য একটা backup রাখা লাগবে, database-এর একটা replication তৈরি করতে হবে।

Replication কি?

Backup আর replication একই জিনিস মনে হলেও একই জিনিস না। Backup-এর data হলো একটা নির্দিষ্ট সময়ের snapshot। কিন্তু replication হলো main database-এর জ্যান্ত copy। Main database update হলেই, এই replication database eventually update হয়ে যাবে। কিন্তু backup-এর database প্রতিদিন স্বয়ংক্রিয়ভাবে update হবে না। আপনি যখন backup নিবেন তখন ঐ সময়ের backup data locked হয়ে থাকবে। Hopefully replication জিনিসটা কী বুঝতে পেরেছেন।

কেন Replication করা হয়?

Replication বিভিন্ন কারণে হতে পারে, যেমন:-

High Availability - Primary database fail করলে Replica database, main database হিসেবে কাজ করবে।
Read Scaling - Application যদি read-heavy হয়, তখন read replicas use করা হয় write database-এর write traffic কমানোর জন্য।
Geographical Distribution - যদি user-এর density বিভিন্ন দেশে বেশি হয়, তখন region-specific database use করা হয়। যেমন: বাংলাদেশের user-রা বাংলাদেশের কাছের database, ইউরোপের user-রা ইউরোপের কাছের database-এ থাকবে। এই জিনিসটা মূলত latency কমাতে সাহায্য করে।

Asynchronous Replication vs Synchronous Replication

Replication ২ ভাবে হতে পারে—instantly (synchronous) অথবা eventually (asynchronous)। এটা depend করছে আপনার requirement-এর ওপরে, আপনি কীভাবে data replicate করবেন এবং আপনার অ্যাপ্লিকেশনে data consistency কেমন লাগবে।

Synchronous Replication-এ write হওয়ার সাথে সাথেই replication process complete হবে। সবগুলো node-এ same data থাকবে। Stale বা old data থাকার possibility নেই বললেই চলে।

Asynchronous Replication-এ write হওয়ার পর কিছুটা time নিবে replicate হতে, কারণ write হওয়ার পর replication process চালানো হয়। Eventually data consistent হয়ে যায়। এই টেকনিকে stale বা old data থাকার probability সবচেয়ে বেশি, কারণ synchronize হওয়ার আগ পর্যন্ত stale data serve হতে থাকবে।

Replication Technique

Single-Leader Replication (Master to Follower)

সবচেয়ে common replication strategy হলো Single-Leader Replication। এই টেকনিকে একটা database server-কে Leader হিসেবে ধরা হয়, এবং বাকি database server-গুলো Replica বা Follower হিসেবে কাজ করে।

Read করতে পারবে যেকোনো Replica থেকে। Write শুধু Leader-এ করা হবে এবং replica-গুলো main database-এর সাথে synchronize হয়ে যাবে।

Multi-Leader Replication

এই টেকনিক টা বুঝতে একটু অতীতে যাওয়া লাগবে। ধরুন, Modern Civilization এর আগে মানুষ বিভিন্ন গ্রুপ এ বসবাস করত এবং তাদের মধ্যে সব কিছুই নিয়ন্ত্রণ করত একজন ব্যক্তি। সকলেই ওই ব্যক্তিকে follow করত।
এভাবে প্রায় সকল গ্রুপ এর কাজ চলত। মজার ব্যপার হল একটা বড় এরিয়া তে অনেক গুলো গ্রুপ থাকত। প্রত্যেক গ্রুপ এর একজন করে Leader থাকত।

তারা সবাই একটা দেশের রাজার অধীনে থাকত। ঠিক এভাবেই এই টেকনিক টা কাজ করে। একই ধরনের cluster এর মধ্যে অনেক Leader থাকতে পারে। এবং এই leader দের অধীনে এক বা একাধিক follower থাকতে পারে।

এই ধরনের replication technique এ সব থেকে বড় প্রবলেম হচ্ছে Consistency। ধরুন, একজন ব্যবহারকারী দুইটি আলাদা জায়গা থেকে একই সময়ে দুইটি অ্যাকাউন্টে আলাদা আলাদা তথ্য update করল। তখন data conflict হবে এবং তা resolve করা জটিল হবে। এই conflict resolution করার জন্য কিছু পদ্ধতি আছে, যেমন - Last Write Wins, manual merge, CRDT। প্রতিটার trade-off আছে।

Leaderless Replication: Dynamo-style

কোনো Leader নেই। যেকোনো node-এ write করা যায়।

Amazon-এর ২০০৭ সালের বিখ্যাত 'Dynamo Paper' থেকে এই কনসেপ্টের উৎপত্তি, যা বর্তমানে Apache Cassandra বা ScyllaDB-তে ব্যবহৃত হয় (উল্লেখ্য, বর্তমান AWS DynamoDB সার্ভিস কিন্তু internally Paxos লিডার ব্যবহার করে)।

এই Technique টা খুব সুন্দর মনে হতে পারে এখানে প্যারা কম। কিন্তু সত্যি বলতে এই technique টা সব থেকে বেশি complex এবং data loss হওয়ার সম্ভাবনা থাকে। Consistency বজায় রাখা খুব কঠিন হয়ে পড়ে।

Replication-এর সমস্যা কী?

আমি অনেকবার বলেছি একটা simple জিনিসকে যদি আপনি ভেঙে ফেলেন, সেখানে complexity বেড়ে যাবে। এখানে যখন আপনি extra replica database introduce করবেন তখন সবচেয়ে বড় challenge হচ্ছে Data Synchronization & Consistency। এটা maintain করা খুব কঠিন। একটু এদিক-ওদিক হলে data loss হতে পারে বা data inconsistency দেখা যেতে পারে।

Replication Lag

Data write হওয়ার পর replica node-গুলোতে replicate হতে যে সময়টা লাগে, সেটাই হলো Replication Lag। যদি system-এ write heavy traffic থাকে, তখন lag অনেক বেশি হতে পারে। যার ফলে stale data serve হওয়ার সম্ভাবনা থাকে।

Read-Your-Own-Write Consistency

Replication technique implementation করার পর একটা কমন সমস্যা দেখা যায়, সেটা হল Read-Your-Own-Write Consistency। ধরুন, কোনো ইউজার ডাটা write করল, কিন্তু replicas update হলো না। ইউজার যদি তৎক্ষণাৎ আবার ডাটাটা পড়ে, তাহলে ভুল ডাটা বা পুরানো ডাটা দেখতে পারে। এটা fix করতে হলে Consistency Level বাড়াতে হয়, যা পারফরম্যান্স কমিয়ে দেয়।

Leader Election

Single Leader Replication এ, Leader node ডাউন হলে নতুন করে Leader নির্বাচন করা হয়। এই প্রক্রিয়াটি যদি দ্রুত না হয়, তাহলে write operation fail হতে পারে। Leader Election প্রক্রিয়াটি complex এবং এটা implement করাও বেশ tricky।

Split-Brain Scenario

Network partition এর কারণে দুটি node নিজেদেরকে Leader ভাবতে শুরু করলে Split-Brain পরিস্থিতি তৈরি হয়। এক্ষেত্রে দুটি database node সম্পূর্ণ আলাদা হয়ে যায় এবং তারা নিজেদের ডাটাবেসকে Main Database হিসেবে ভাবতে শুরু করে। যখন network back up হয়, তখন merge করতে গিয়ে conflict এবং data loss হতে পারে।

বটম লাইন

Replication মূলত application-এর performance improve করতে এবং system-কে resilient করতে সাহায্য করে। এগুলো main goal হলেও এখানে অনেক complexity add হয়। তাই ভেবেচিন্তে requirement অনুযায়ী বেছে নিন।

আপনার system-এ কোন replication strategy আছে? কমেন্টে শেয়ার করুন! 👇

StackFeed

Day 13 - Data Replication - Single-Leader, Multi-Leader, Leaderless