High Availability (HA) & Clustering

আগের অধ্যায়ে আমরা Replication দেখেছি, যেখানে মাস্টার ডাউন হলে ম্যানুয়ালি বা অটোমেটিক স্লেভকে প্রমোট করতে ১-২ মিনিট সময় লাগতে পারে। কিন্তু High Availability (HA) এর লক্ষ্য হলো: "সার্ভার মরবে, কিন্তু সার্ভিস থামবে না।"

এই অধ্যায়ে আমরা শিখব কীভাবে Cluster তৈরি করে জিরো ডাউনটাইম এবং জিরো ডেটা লস নিশ্চিত করা যায়।

১৭.১ High Availability (HA) ও SPOF কী?

✅ High Availability (HA)

এমন একটি সিস্টেম ডিজাইন, যেখানে হার্ডওয়্যার ফেইল, সার্ভার ক্র্যাশ বা নেটওয়ার্ক ডাউন হলেও ডেটাবেস সার্ভিস চালু থাকে।

লক্ষ্য: ৯৯.৯৯৯% আপটাইম (বছরে মাত্র ৫ মিনিট ডাউনটাইম)

⚠️ Single Point of Failure (SPOF)

আপনার আর্কিটেকচার যদি এমন হয়: API → MySQL (Single Server)

তবে এখানে MySQL হলো SPOF। এই সার্ভারটি নষ্ট হওয়া মানে পুরো কোম্পানি বন্ধ।

💡 Replication SPOF কমায় (স্লেভ থাকে), কিন্তু পুরোপুরি দূর করতে Cluster লাগে।

১৭.২ Synchronous vs Asynchronous (Core Difference)

ক্লাস্টারিং বোঝার আগে এই তফাৎটা বোঝা জরুরি।

বৈশিষ্ট্যAsynchronous (Master-Slave)Synchronous (Cluster/Galera)
পদ্ধতিমাস্টার রাইট করে সাকসেস দেয়, পরে স্লেভে কপি হয়সব নোডে ডেটা রাইট হলে তবেই সাকসেস দেয়
Data Lossসম্ভব (মাস্টার ক্র্যাশ করলে শেষ ১-২ সেকেন্ডের ডেটা হারায়)Zero Data Loss (গ্যারান্টিড)
Performanceফাস্ট রাইট (Write)একটু স্লো (নেটওয়ার্ক ল্যাটেন্সির কারণে)
ব্যবহারসাধারণ ওয়েব অ্যাপ, ব্লগব্যাংকিং, ফিনটেক, ক্রিটিক্যাল সিস্টেম

১৭.৩ MySQL Cluster (NDB Cluster) — দ্য বিস্ট

এটি MySQL-এর অফিশিয়াল ক্লাস্টারিং ইঞ্জিন, কিন্তু এটি সাধারণ InnoDB ইঞ্জিনের মতো নয়। এটি মূলত Distributed, In-Memory, Real-Time সিস্টেম।

আর্কিটেকচার (৩ ধরণের নোড লাগে):

  • Management Nodes (MGM): ক্লাস্টার কনফিগারেশন ম্যানেজ করে। ট্রাফিক পুলিশ।
  • Data Nodes (NDB): আসল ডেটা এখানে থাকে। ডেটা অটোমেটিক্যালি শার্ডিং হয়ে বিভিন্ন ডেটা নোডে ছড়িয়ে থাকে।
  • SQL Nodes: অ্যাপ্লিকেশন এর সাথে কথা বলে এবং ডেটা নোড থেকে ডেটা এনে দেয়।

✅ সুবিধা: অটোমেটিক শার্ডিং, ৯৯.৯৯৯% আপটাইম

❌ অসুবিধা: সেটআপ অত্যন্ত জটিল। সাধারণ JOIN কুয়েরি স্লো। স্পেশাল স্কিমা ডিজাইন লাগে।

📌 ব্যবহার: টেলিকম ইন্ডাস্ট্রি, রিয়েল-টাইম গেমিং (সাধারণত ওয়েব অ্যাপে ব্যবহার হয় না)

১৭.৪ Percona XtraDB Cluster (PXC) / Galera Cluster

ওয়েব অ্যাপ্লিকেশনের (SaaS, E-commerce) জন্য এটিই Best Solution। এটি Galera Library ব্যবহার করে সিনক্রোনাস রেপ্লিকেশন দেয়।

আর্কিটেকচার:

  • মিনিমাম ৩টি নোড লাগে।
  • সব নোডই Active-Active (সবগুলোতেই Read এবং Write করা যায়)
  • একটি নোড মরলে বাকিরা কাজ চালায়

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

│ Node 1 │◄───►│ Node 2 │◄───►│ Node 3 │

│ (Active) │ │ (Active) │ │ (Active) │

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

Synchronous Replication (Galera)

১৭.৫ PXC / Galera কীভাবে কাজ করে? (Certification Based Replication)

এটি ইন্টারভিউয়ের জন্য ডিপ টপিক।

১.

Write Request: আপনি Node 1-এ ডেটা রাইট করলেন।

২.

Certification Check: Node 1 বাকি সব নোডকে (Node 2, Node 3) জিজ্ঞেস করে, "এই ডেটা রাইট করলে কোনো কনফ্লিক্ট হবে কি?"

৩.

Synchronous Commit: সবাই যদি "OK" বলে, তবেই ডেটা পার্মানেন্টলি সেভ (Commit) হয়।

৪.

Result: ক্লায়েন্ট কনফার্মেশন পায়।

✅ সুবিধা:

  • Zero Data Loss: সব নোডে একই ডেটা
  • Automatic Failover: ম্যানুয়ালি কিছু করতে হয় না
  • Read Scalability: যেকোনো নোড থেকে পড়া যায়

❌ অসুবিধা:

  • Write Latency: সব নোড থেকে "OK" আসতে একটু সময় লাগে
  • Network Sensitive: Ping টাইম বেশি হলে ক্লাস্টার স্লো হয়ে যায়

১৭.৬ Quorum & Split-Brain (বিজোড় সংখ্যার রহস্য)

কেন ক্লাস্টারে সবসময় ৩, ৫ বা ৭টি (বিজোড়) নোড লাগে?

⚠️ Split-Brain সমস্যা:

ধরুন ২টা নোড আছে (A এবং B)। মাঝখানের তার ছিঁড়ে গেল।

  • A ভাববে B মরে গেছে, তাই A একাই কাজ করবে
  • B ভাববে A মরে গেছে, তাই B একাই কাজ করবে
  • ফলাফল: ডেটা কনফ্লিক্ট (Split Brain)

✅ Quorum (ভোটিং সিস্টেম):

সিদ্ধান্ত নেওয়ার জন্য Majority Vote লাগে।

  • ৩টি নোড থাকলে মেজরিটি = ২
  • যদি ১টি নোড আলাদা হয়ে যায়, বাকি ২ জন মিলে মেজরিটি গঠন করে কাজ চালায়
  • আলাদা হওয়া নোডটি নিজেকে লক করে ফেলে

[Node A] + [Node B] + [Node C] → Majority (2+) → Work!

[Node A alone] → No Quorum → Read-Only Mode

১৭.৭ Load Balancer (ProxySQL vs HAProxy)

ক্লাস্টারের ৩টি নোড থাকলেও অ্যাপ সরাসরি কানেক্ট করে না। মাঝখানে লোড ব্যালেন্সার থাকে।

⚡ HAProxy (TCP Level)

  • এটি শুধু ট্রাফিক পাস করে। কুয়েরি বোঝে না
  • ফাস্ট, কিন্তু কম বুদ্ধিমান

🚀 ProxySQL (SQL Level - Best Choice)

  • এটি কুয়েরি পড়তে পারে
  • Read/Write Split: INSERT → Writer Node, SELECT → Reader Node
  • Query Caching: বারবার একই কুয়েরি এলে ক্যাশ থেকে উত্তর দেয়
  • Failover: কোনো নোড ক্র্যাশ করলে ট্রাফিক অন্য নোডে ঘুরিয়ে দেয়

১৭.৮ Auto-Failover Mechanism

1️⃣

Monitor: ক্লাস্টার প্রতিনিয়ত নোডগুলোর হেলথ চেক করে

2️⃣

Crash: Node 1 ক্র্যাশ করল

3️⃣

Detect: বাকি নোডগুলো বুঝল Node 1 নেই। তারা কোরাম মিটিং করে Node 1-কে গ্রুপ থেকে বের করে দেয়

4️⃣

Route: ProxySQL ট্রাফিক অটোমেটিক Node 2 এবং Node 3-তে পাঠিয়ে দেয়

5️⃣

Rejoin: Node 1 ঠিক হলে সে আবার জয়েন করে এবং মিসিং ডেটা অটোমেটিক সিঙ্ক করে নেয় (State Transfer)

১৭.৯ Enterprise Architecture (Real World)

সিনিয়র আর্কিটেক্ট হিসেবে আপনি নিচের ডিজাইনগুলো ফলো করবেন:

🛒 Scenario A: E-commerce / SaaS (Hybrid Approach)

API → ProxySQL → [PXC Node 1, PXC Node 2, PXC Node 3] → Async Slave (Backup/Analytics)

  • Core: ৩টি PXC নোড মেইন ট্রানজেকশন হ্যান্ডেল করে (High Availability)
  • Extras: ১টি আলাদা Async Slave রাখা হয় ভারী রিপোর্টিং বা ব্যাকআপের জন্য

🏦 Scenario B: Banking / FinTech (Pure Consistency)

ProxySQL → Galera Node 1 ↔ Galera Node 2 ↔ Galera Node 3

এখানে কোনো Async Slave নেই, কারণ ডেটা কনসিস্টেন্সি এখানে পারফরম্যান্সের চেয়ে বেশি জরুরি।

১৭.১০ Senior-Level Best Practices

  • ✓Minimum 3 Nodes: কখনোই ২ নোড দিয়ে ক্লাস্টার বানাবেন না
  • ✓Same Specs: ক্লাস্টারের সব সার্ভারের CPU/RAM সমান হতে হবে। কারণ সবচেয়ে দুর্বল নোডের গতিতেই পুরো ক্লাস্টার চলবে
  • ✓Low Latency: সব নোড একই রিজিয়নে (যেমন: Singapore) রাখুন। ভিন্ন দেশে রাখলে নেটওয়ার্ক ল্যাটেন্সির কারণে রাইট স্লো হবে
  • ✓Avoid Huge Transactions: ক্লাস্টারে বিশাল বড় DELETE বা UPDATE চালালে সব নোড লক হয়ে যেতে পারে। ব্যাচ প্রসেস করুন
  • ✓Encrypt Communication: নোডগুলোর নিজেদের মধ্যে কথা বলা (Traffic) অবশ্যই এনক্রিপ্ট করবেন

❓ Interview Q&A

Q: Galera Cluster এ কি Replication Lag হয়?

টেকনিক্যালি না, কারণ এটি Synchronous। তবে "Flow Control" এর কারণে যদি কোনো নোড রাইট করতে দেরি করে, তবে পুরো ক্লাস্টার সেই স্লো নোডের জন্য অপেক্ষা করে।

Q: Split-Brain হলে ডেটা লস হয়?

না। কারণ Quorum মেকানিজম থাকায় মাইনরিটি (আলাদা হয়ে যাওয়া) অংশটি রাইট নেওয়া বন্ধ করে দেয়। ফলে ডেটা ইনকনসিস্টেন্ট হয় না।

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

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

  • ✓HA vs SPOF: Single Point of Failure এড়ানোই HA-র মূল লক্ষ্য
  • ✓Synchronous vs Asynchronous: Cluster = Zero Data Loss, Replication = সামান্য ডেটা লস হতে পারে
  • ✓Galera/PXC: ওয়েব অ্যাপ্লিকেশনের জন্য সেরা সলিউশন - Active-Active Cluster
  • ✓Quorum: বিজোড় সংখ্যার নোড দরকার। Majority vote ছাড়া কেউ রাইট করতে পারে না
  • ✓ProxySQL: স্মার্ট লোড ব্যালেন্সার যা কুয়েরি বুঝে রাউট করে

✨ এই নলেজ দিয়ে আপনি এখন Mission Critical System ডিজাইন করতে পারবেন যা কখনো ডাউন হবে না। পরবর্তী অধ্যায়ে আমরা শিখব Handling Large Data—যেখানে আমরা শিখব বিলিয়ন বিলিয়ন ডেটার টেবিলে পেজিনেশন এবং আর্কাইভিং কীভাবে করতে হয়।

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

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

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