Replication (হাই অ্যাভেলেবিলিটি ও স্কেলিং)

ধরুন, আপনার একটি ই-কমার্স সাইট আছে। ব্ল্যাক ফ্রাইডে সেলে প্রচুর ইউজার হিট করল। আপনার ডেটাবেস সার্ভার লোড নিতে না পেরে ক্র্যাশ করল। ফলাফল? বিজনেস বন্ধ। অথবা, আপনার হার্ডডিস্ক নষ্ট হয়ে গেল। ব্যাকআপ রিস্টোর করতে ২ ঘণ্টা লাগল। এই ২ ঘণ্টা সাইট ডাউন।

এই সমস্যাগুলোর সমাধান হলো Replication। অর্থাৎ, ডেটাকে রিয়েল-টাইমে কপি করে একাধিক সার্ভারে রাখা।

১৬.১ Replication কী? (সহজ কথায়)

রেপ্লিকেশন মানে হলো এক সার্ভারের (Master) ডেটা অটোমেটিক্যালি অন্য সার্ভারে (Slave) কপি হওয়া।

✍️ Master (Writer)

এখানে সব INSERT, UPDATE, DELETE অপারেশন হয়।

📖 Slave (Reader)

এটি মাস্টারের হুবহু কপি রাখে। এখান থেকে শুধু SELECT করা হয়।

❓ কেন দরকার?

  • Scale Out (Read Scaling): রিড কুয়েরিগুলো স্লেভে পাঠিয়ে মাস্টারের লোড কমানো যায়
  • High Availability (Failover): মাস্টার ক্র্যাশ করলে স্লেভকে মাস্টার বানিয়ে সার্ভিস চালু রাখা যায়
  • Analytics: ভারী রিপোর্ট জেনারেট করার সময় মেইন সার্ভার স্লো না করে স্লেভ থেকে ডেটা নেওয়া হয়

১৬.২ Master–Slave Architecture (সবচেয়ে জনপ্রিয়)

অধিকাংশ প্রোডাকশন সিস্টেমে এই আর্কিটেকচার ব্যবহার হয়।

┌─────────────────────────────────────────────────────────┐

│ অ্যাপ্লিকেশন │

└─────────────────────────────────────────────────────────┘

│ Write (INSERT/UPDATE/DELETE) │ Read (SELECT)

▼ ▼

┌─────────────┐ ┌─────────────┐

│ Master │ ←───── Replication ─────→ │ Slave │

│ (Writer) │ │ (Reader) │

└─────────────┘ └─────────────┘

  • অ্যাপ্লিকেশন রাইট করে মাস্টারে
  • অ্যাপ্লিকেশন রিড করে স্লেভ (বা রেপ্লিকা) থেকে
  • মাস্টার থেকে ডেটা সিঙ্ক হয়ে স্লেভে যায়

১৬.৩ Replication Internals (ভেতরের খবর)

ইন্টারভিউতে জিজ্ঞেস করবে: "রেপ্লিকেশন আসলে কাজ করে কীভাবে?" এখানে ৩টি প্রধান থ্রেড কাজ করে:

🔵 ১. Master - Binlog Dump Thread

মাস্টার সার্ভারে কোনো চেঞ্জ হলে সেটি Binary Log (Binlog) ফাইলে লেখা হয়। মাস্টার এই লগ স্লেভকে পাঠায়।

🟢 ২. Slave - IO Thread

স্লেভ সার্ভারের এই থ্রেডটি মাস্টারের সাথে কানেক্ট করে Binlog রিসিভ করে এবং নিজের Relay Log ফাইলে সেভ করে।

🟡 ৩. Slave - SQL Thread

এই থ্রেডটি Relay Log পড়ে এবং সেই কুয়েরিগুলো স্লেভ সার্ভারে এক্সিকিউট করে।

Master (Binlog) → [Network] → Slave (Relay Log) → (SQL Thread) → Slave Database

১৬.৪ রেপ্লিকেশন সেটআপ (সংক্ষেপে)

যদিও আজকাল ক্লাউডে (AWS RDS) এক ক্লিকে রেপ্লিকেশন হয়, বেসিক জানা জরুরি।

📝 ১. মাস্টারে কনফিগারেশন (my.cnf):

[mysqld]
server-id = 1
log_bin = mysql-bin

👤 ২. রেপ্লিকেশন ইউজার তৈরি:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

⚙️ ৩. স্লেভে কনফিগারেশন (my.cnf):

[mysqld]
server-id = 2
relay_log = relay-bin

🔗 ৪. কানেকশন দেওয়া (Old Style):

CHANGE MASTER TO 
MASTER_HOST='192.168.1.10', 
MASTER_USER='repl', 
MASTER_PASSWORD='password', 
MASTER_LOG_FILE='mysql-bin.000001', 
MASTER_LOG_POS=154;

START SLAVE;

১৬.৫ Monitoring & Replication Lag

স্লেভ কি ঠিকঠাক চলছে? চেক করার কমান্ড:

SHOW SLAVE STATUS\G;

গুরুত্বপূর্ণ ফিল্ড:

  • Slave_IO_Running: Yes (মাস্টারের সাথে কানেকশন আছে)
  • Slave_SQL_Running: Yes (কুয়েরি এক্সিকিউট হচ্ছে)
  • Seconds_Behind_Master: 0 (সবচেয়ে গুরুত্বপূর্ণ)

⚠️ Replication Lag কী?

যদি Seconds_Behind_Master > 0 হয়, তার মানে স্লেভ মাস্টারের চেয়ে পিছিয়ে আছে। মাস্টার ১ মিনিট আগে ডেটা পেয়েছে, কিন্তু স্লেভে এখনো আসেনি।

Lag কমানোর উপায়:

  • Multi-threaded Slave: slave_parallel_workers = 4 সেট করা (যাতে প্যারালাল প্রসেস করতে পারে)
  • Heavy Query: স্লেভে ভারী কুয়েরি চললে রেপ্লিকেশন আটকে যায়। অপটিমাইজ করুন
  • Network: মাস্টার ও স্লেভের নেটওয়ার্ক ফাস্ট হতে হবে

১৬.৬ Master–Master Replication (Active-Active)

এখানে দুটি সার্ভারই মাস্টার হিসেবে কাজ করে। A তে লিখলে B তে যায়, B তে লিখলে A তে আসে।

✅ সুবিধা:

  • জিরো ডাউনটাইম
  • একটি ক্র্যাশ করলে অন্যটি রেডি থাকে

❌ বড় সমস্যা (Collision):

দুই সার্ভারে একসাথে ইনসার্ট হলে প্রাইমারি কি (ID) কনফ্লিক্ট করতে পারে।

✅ সমাধান (Odd/Even ID):

  • Server A: ১, ৩, ৫, ৭... (বিজোড় আইডি জেনারেট করবে)
  • Server B: ২, ৪, ৬, ৮... (জোড় আইডি জেনারেট করবে)
-- Server A
auto_increment_increment = 2
auto_increment_offset = 1

-- Server B
auto_increment_increment = 2
auto_increment_offset = 2

১৬.৭ GTID (Global Transaction ID) — আধুনিক রেপ্লিকেশন

আগে ফাইল নেম (mysql-bin.001) এবং পজিশন (154) মনে রাখতে হতো। সার্ভার ক্র্যাশ করলে পজিশন বের করা কঠিন ছিল। GTID প্রতিটি ট্রানজেকশনকে একটি ইউনিক আইডি দেয় (যেমন: UUID:TransactionID)।

✅ সুবিধা:

  • পজিশন মনে রাখার দরকার নেই। স্লেভ অটোমেটিক বুঝে নেয় কতটুকু ডেটা মিসিং
  • Failover বা অটোমেটিক রিকভারি খুব সহজ

সেটআপ:

CHANGE MASTER TO 
MASTER_HOST='...', 
MASTER_AUTO_POSITION = 1; -- ফাইল পজিশনের দিন শেষ!

১৬.৮ Failover Strategy (বিপদ সামলানো)

যদি মাস্টার সার্ভার পুড়ে যায়, তখন কী করবেন?

🖐️ Manual Failover

  • স্লেভকে কমান্ড দিয়ে মাস্টার হিসেবে প্রমোট করা (STOP SLAVE; RESET MASTER;)
  • অ্যাপ্লিকেশনের কনফিগে আইপি চেঞ্জ করা
  • (সময়সাপেক্ষ)

🤖 Automatic Failover

  • Orchestrator: বেস্ট ওপেন সোর্স টুল
  • ProxySQL / HAProxy: ট্রাফিক রাউটিং এর জন্য
  • অটোমেটিক ডিটেক্ট করে ট্রাফিক স্লেভে ঘুরিয়ে দেয়

১৬.৯ Semi-Synchronous Replication (ডেটা সেফটি ফার্স্ট)

⚡ Async (Default)

মাস্টার ডেটা রাইট করেই ক্লায়েন্টকে "Success" বলে দেয়, স্লেভে কপি হলো কি না দেখার সময় নেই।

(ফাস্ট, কিন্তু মাস্টার ক্র্যাশ করলে শেষ ১ সেকেন্ডের ডেটা হারাতে পারে)

🛡️ Semi-Sync

মাস্টার অন্তত ১টি স্লেভে ডেটা পৌঁছানো পর্যন্ত অপেক্ষা করে, তারপর ক্লায়েন্টকে "Success" বলে।

(একটু স্লো, কিন্তু ডেটা হারাবে না)

ব্যবহার: ফিনটেক বা ব্যাংকিং অ্যাপে

১৬.১০ Real-World Architecture (Read/Write Splitting)

একজন সিনিয়র ইঞ্জিনিয়ার হিসেবে আপনি অ্যাপ্লিকেশনে কানেকশন এভাবে সেট করবেন: 

// Node.js / Laravel Example
{
  write_host: '192.168.1.10', // Master
  read_hosts: ['192.168.1.11', '192.168.1.12'] // Slaves
}

ফ্রেমওয়ার্ক অটোমেটিক INSERT/UPDATE কুয়েরি মাস্টারে পাঠাবে এবং SELECT কুয়েরি স্লেভে পাঠাবে।

INSERT/UPDATE ──────► Master

SELECT ──────► Slave 1 / Slave 2 (Load Balancer)

❓ Interview Q&A

Q: Replication Lag কেন হয়?

মাস্টার প্যারালাল অনেক রিকোয়েস্ট হ্যান্ডেল করে, কিন্তু স্লেভ ডিফল্টভাবে সিঙ্গেল থ্রেডে (SQL Thread) কাজ করে। তাই রাইট হেভি সিস্টেমে স্লেভ পিছিয়ে পড়ে। সমাধান: Multi-threaded slave কনফিগার করা।

Q: মাস্টার ক্র্যাশ করলে কী করবেন?

যদি অটোমেটিক ফেইলওভার না থাকে, তবে ম্যানুয়ালি সেরা স্লেভটিকে (যেটি মাস্টারের সবচেয়ে কাছে ছিল) নতুন মাস্টার হিসেবে প্রমোট করব এবং বাকি স্লেভগুলোকে নতুন মাস্টারের সাথে সিঙ্ক করব।

🎯 অধ্যায় ১৬ এর সারাংশ (Summary)

এই অধ্যায়ে আমরা শিখলাম:

  • ✓Master-Slave: মাস্টারে লেখা, স্লেভ থেকে পড়া (Read Scaling)
  • ✓Replication Internals: Binlog → IO Thread → Relay Log → SQL Thread
  • ✓GTID: আধুনিক রেপ্লিকেশন - পজিশন মনে রাখার দরকার নেই
  • ✓Failover: Manual বা Automatic (Orchestrator, ProxySQL)
  • ✓Lag Solutions: Multi-threaded slave, Heavy query optimization

✨ এখন আপনি জানেন কীভাবে হাইলি স্কেলেবল এবং ফল্ট টলারেন্ট সিস্টেম ডিজাইন করতে হয়। পরবর্তী অধ্যায়ে আমরা শিখব High Availability & Clustering (Galera/InnoDB Cluster)—যেখানে আমরা শিখব রেপ্লিকেশনের চেয়েও উন্নত ক্লাস্টারিং টেকনোলজি।

প্রস্তুত তো? 🚀

🔒 কপিরাইট সুরক্ষিত কন্টেন্ট 🔒

কপি, স্ক্রিনশট, প্রিন্ট করা সম্পূর্ণ নিষিদ্ধ।