Replication — leader-follower, multi-leader, leaderless আর replication lag

১ · কেন একই ডেটার কয়েকটি কপি — চার কারণ, তিন নকশা

একটি কাল্পনিক অনলাইন মুদি-বাজার সেবার পুরো database একটি সার্ভারে। এক দিন power supply নষ্ট — কেউ অর্ডার দিতে পারেন না। ঈদের আগের সন্ধ্যায় পড়ার চাপেই সার্ভার হাঁপিয়ে ওঠে। প্রবাসী ক্রেতারা দেখেন প্রতিটি পাতা ধীর। আর এক রাতে ডিস্কটিই নষ্ট। চার সমস্যারই সাধারণ উত্তর: একই ডেটার কপি অন্য যন্ত্রে রাখা আর হালনাগাদ রাখা — replication; প্রতিটি কপি একটি replica.

ডেটা না বদলালে replication হতো একবার কপির কাজ। কঠিনতা পরিবর্তনে: লেখা কোথায় নেওয়া হবে, কীভাবে বাকি কপিতে যাবে, কপিগুলো কখন কতটা মিলবে। তিনটি বড় পরিবার — নিচের ছবিতে পাশাপাশি:

একটি হিসাব — replication পড়া বাড়ায়, লেখা নয়

নতুনদের সাধারণ ভুল: “database ধীর? আরও replica দিন।” ধরা যাক: প্রতিটি সার্ভার সেকেন্ডে ১০,০০০টি কাজ (একটি পড়া বা লেখা) সামলায়; follower-এ একটি replicate হওয়া লেখা প্রয়োগও একটি কাজ; সেকেন্ডে ৩৬,০০০ পড়া আর ৪,০০০ লেখা। প্রতিটি সার্ভারকে (leader আর প্রতিটি follower) সব ৪,০০০ লেখা সামলাতে হয়, তাই পড়ার জন্য থাকে ৬,০০০। Leader ৬,০০০ পড়া নিলে বাকি ৩০,০০০ ÷ ৬,০০০ = ৫টি follower — মোট ৬টি সার্ভার। লেখা দ্বিগুণ (৮,০০০) হলে পড়ার জায়গা নামে ২,০০০-এ: (৩৬,০০০ − ২,০০০) ÷ ২,০০০ = ১৭টি follower, মোট ১৮টি — তিন গুণ! লেখা ১০,০০০ ছুঁলে কোনো সংখ্যক follower-ই সাহায্য করে না। লেখার চাপ ভাগের উপায় ডেটাকেই ভাগ করা — পর্ব ২৩. বাস্তবে সার্ভার পুরো ভরানো হয় না (পর্ব ৩-এর headroom), তাই আরও বেশি লাগে।

২ · Single-leader replication — লেখা এক জায়গায়, log সবার কাছে

Single-leader replication (leader-follower, primary-replica; পুরোনো লেখায় master-slave) সবচেয়ে প্রচলিত নকশা। নিয়ম তিনটি: সব লেখা যায় leader-এ; leader লেখাটি আগে নিজের write-ahead log-এ রাখে (WAL, পর্ব ১৯), তারপর পরিবর্তনটি replication log হিসেবে প্রতিটি follower-কে পাঠায়; প্রতিটি follower সেই log একই ক্রমে প্রয়োগ করে। পড়া চলে leader বা যেকোনো follower-এ। PostgreSQL, MySQL, MongoDB-র replica set, Redis, এমনকি Kafka-র প্রতিটি partition — নিজ নিয়মে সবাই এই ধাঁচ মানে।

ক্রম কেন জরুরি? Leader-এ পরপর “balance = ৫০০”, তারপর “balance = ৭০০”। উল্টো ক্রমে প্রয়োগ করা follower-এর শেষ মান ৫০০ — কপিটি নিঃশব্দে ভুল। তাই log-এর প্রতিটি রেকর্ডের একটি ক্রমিক অবস্থান থাকে: log sequence number, সংক্ষেপে LSN (MySQL-এ binlog-অবস্থান বা GTID দিয়ে একই কাজ হয়)। Follower কতটা পিছিয়ে, থেমে গেলে কোথা থেকে আবার শুরু করবে — সবই এই নম্বরে।

Log-এ কী পাঠানো হবে — তিনটি উপায়

একই পরিবর্তন তিনভাবে লেখা যায়। নিচের উদাহরণে একটি অর্ডার “shipped” হলো — দেখুন তিন রূপে log-এ কী যায়:

-- (1) Statement-based: the exact command the leader ran
UPDATE orders SET status = 'shipped', shipped_at = NOW() WHERE id = 1006;

-- (2) WAL / physical: which bytes changed on which page of which file
lsn=0/3A00F2B8 rel=orders block=412 offset=96 len=24 data=73 68 69 70 ...

-- (3) Logical / row-based: which row, which columns, final values
{"lsn": 1042, "table": "orders", "op": "update", "key": {"id": 1006},
 "new": {"status": "shipped", "shipped_at": "2026-10-28T10:00:00.120Z"}}

(১) Statement-based: follower হুবহু সেই কমান্ডটিই আবার চালায়। Log সবচেয়ে ছোট — এক লাখ সারির UPDATE-ও এক লাইন। কিন্তু উপরের কমান্ডেই ফাঁদ: NOW() follower-এ চলবে পরে, তাই shipped_at দুই কপিতে আলাদা। RAND(), UUID(), ORDER BY ছাড়া LIMIT, transaction-এর ক্রমে নির্ভরশীল auto-increment বা trigger — সবই কপিগুলোকে আলাদা করে দিতে পারে।

(২) WAL shipping (physical): storage engine-এর WAL-এ এমনিতেই প্রতিটি বাইট-বদল আছে; সেটিই পাঠানো হয়। Follower হয় বাইট ধরে হুবহু কপি — সব টেবিল, index আর schema বদলসহ। সরল ও দ্রুত; PostgreSQL-এর streaming replication এই পথে। দাম: log বাঁধা storage-এর format-এর সাথে, তাই সাধারণত একই major সংস্করণ লাগে — শূন্য-বিরতিতে upgrade কঠিন; টেবিল বাছাই করেও পাঠানো যায় না।

(৩) Logical (row-based): সারির স্তরের পরিবর্তন — কোন সারি ঢুকল, মুছল বা কোন column কী মানে বদলাল। NOW()-এর আসল মানটিই log-এ, তাই অনির্ধারণ নেই। Storage format থেকে আলাদা বলে ভিন্ন সংস্করণে, বাছাই করা টেবিলে, এমনকি অন্য সিস্টেমেও পাঠানো যায় — এর নাম change data capture (CDC): প্রতিটি পরিবর্তন event হয়ে যায় search index-এ (পর্ব ২৭), cache মোছায় বা একটি log stream-এ (পর্ব ৩৩)। দাম: এক লাখ সারির UPDATE মানে এক লাখ রেকর্ড, আর schema বদল (DDL) প্রায়ই আলাদা সামলাতে হয় — PostgreSQL-এর built-in logical replication লেখার সময়ে DDL পাঠায় না। MySQL-এর binlog-এর row format এই ধাঁচের, ৫.৭.৭ সংস্করণ থেকে default.

PostgreSQL আর MySQL-এ এসব চালু করা আর lag মাপা — DBMS কোর্সের Backup, replication আর high availability পর্বে live SQL সহ আছে; এখানে আমরা নকশার প্রশ্নে থাকব।

৩ · Synchronous, asynchronous আর semi-synchronous — “OK” কখন বলবেন

সবচেয়ে বড় সিদ্ধান্ত: leader client-কে “commit সফল” কখন বলবে? Asynchronous-এ নিজের ডিস্কে লিখেই, log পরে যায়। Synchronous-এ follower “পেয়েছি” (ack) বলার পর। Semi-synchronous-এ অন্তত একটি follower-এর ack পেলেই, বাকিরা async. ধরা যাক: leader-এর fsync ১ ms; F1 একই ডেটা সেন্টারে, এক দিকে ০.৫ ms; F2 অন্য region-এ, এক দিকে ৩০ ms; follower-এর fsync ১ ms; leader নিজের fsync শেষে log পাঠায়।

তাই “সব follower synchronous” প্রায় কেউ চালায় না। প্রচলিত বিন্যাস: একই region-এর একটি follower semi-sync (বাড়তি কয়েক ms), দূরের DR follower async. Async-এর ঝুঁকি মাপা যায়: leader হঠাৎ মরলে হারানো সফল-বলা লেখা ≈ লেখার হার × lag. সেকেন্ডে ২,০০০ লেখা আর ২০০ ms lag-এ প্রায় ৪০০টি; ভারী batch কাজে lag ৩০ সেকেন্ড হলে প্রায় ৬০,০০০। কতটা হারানো চলবে, সেই লক্ষ্য RPO (পর্ব ৫১)।

৪ · Replication lag — ব্যবহারকারী যা দেখেন, আর তিনটি নিশ্চয়তা

Async follower সবসময় একটু পিছিয়ে — replication lag. স্বাভাবিক দিনে কয়েক ms; follower ব্যস্ত হলে, নেটওয়ার্ক ধীর হলে বা বড় batch লেখায় সেকেন্ড, এমনকি মিনিট। লেখা থামলে শেষ পর্যন্ত সব কপি মিলবে — এটুকুই eventual consistency; “শেষ পর্যন্ত”-র কোনো সীমা নেই। উল্টো প্রান্তে strong consistency, যেন ডেটার একটিই কপি (কঠোর রূপ linearizability, পর্ব ৪০)। মাঝখানে কয়েকটি ছোট নিশ্চয়তা ব্যবহারকারীর চোখের তিনটি bug সারায়।

কতবার এমন ঘটে? নিচের সিমুলেটরে F1-এর lag ২ ms + গড়ে ৩০ ms-এর এলোমেলো অংশ, F2-এর (অন্য region, বেশি ব্যস্ত) ৪০ ms + গড়ে ১৬০ ms. ব্যবহারকারী লিখে gap ms পরে পড়েন; তিন নিয়মে কত ভাগ পড়া পুরোনো আর কত ভাগ leader-এ যায়, গুনে দেখুন। Seed নির্দিষ্ট, তাই প্রতিবার একই ফল।

// A user writes, then reads `gap` ms later. Leader + 2 async followers.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = seed + 0x6D2B79F5 | 0;
    let t = Math.imul(seed ^ seed >>> 15, 1 | seed);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rand = rng(22);
const exp = mean => -mean * Math.log(1 - rand());      // random delay, average = mean
const F = [{ d: 2, m: 30 }, { d: 40, m: 160 }];        // follower lag = d + exp(m) ms
const N = 20000, pct = x => (100 * x / N).toFixed(1) + "%";
console.log("gap   random   1s-window      LSN check");
console.log("ms    stale    stale leader   stale leader");
for (const gap of [20, 100, 500, 2000]) {
  let rnd = 0, winStale = 0, winLeader = 0, lsnStale = 0, lsnLeader = 0;
  for (let i = 0; i < N; i++) {
    const lag = F.map(f => f.d + exp(f.m));            // when F1, F2 apply this write
    const pick = rand() < 0.5 ? 0 : 1;                 // load balancer picks a follower
    const fresh = lag.map(l => l <= gap);              // has follower applied it by read time?
    if (!fresh[pick]) rnd++;                           // (a) plain random follower
    if (gap < 1000) winLeader++;                       // (b) own reads -> leader for 1 s
    else if (!fresh[pick]) winStale++;
    const to = fresh[pick] ? pick : fresh[1 - pick] ? 1 - pick : -1; // (c) position check
    if (to < 0) lsnLeader++;                           // no follower caught up -> leader
    else if (!fresh[to]) lsnStale++;                   // never happens: checked first
  }
  console.log(String(gap).padEnd(6) + pct(rnd).padEnd(9) + pct(winStale).padEnd(6) +
    pct(winLeader).padEnd(9) + pct(lsnStale).padEnd(6) + pct(lsnLeader));
}

gap   random   1s-window      LSN check
ms    stale    stale leader   stale leader
20    77.4%    0.0%  100.0%   0.0%  54.9%
100   36.2%    0.0%  100.0%   0.0%  2.7%
500   2.9%     0.0%  100.0%   0.0%  0.0%
2000  0.0%     0.0%  0.0%     0.0%  0.0%

তৃতীয় anomaly — উত্তর আগে, প্রশ্ন পরে

একটি কাল্পনিক group chat-এ Rumana জিজ্ঞেস করলেন, “কাল সভা কয়টায়?” Tanvir উত্তর দিলেন, “সকাল ১০টায়।” বার্তা দুটি আলাদা partition-এ গেছে (পর্ব ২৩), যারা আলাদা গতিতে replicate হয়। Rafi আগে দেখলেন উত্তর, কয়েক সেকেন্ড পরে প্রশ্ন। Consistent prefix reads বলে: লেখাগুলো যে ক্রমে ঘটেছে, পাঠক সেই ক্রমের একটি শুরুর অংশই দেখবেন — মাঝখান বাদ পড়ে পরেরটা আসবে না। একটি log-এ ক্রম আপনিই রক্ষা হয়; সমস্যা আসে ডেটা কয়েকটি স্বাধীন log-এ ভাগ হলে। প্রতিকার: কারণ-ফলে বাঁধা লেখা একই partition-এ (একটি chat-এর সব বার্তা এক জায়গায়), অথবা প্রতিটি লেখার সাথে “কোনটি দেখে লিখেছি” তথ্য — vector clock, পর্ব ৩৯-এ।

৫ · নতুন follower, বিকল follower আর leader-এর মৃত্যু — failover-এর ভেতরে

সেবা না থামিয়ে নতুন follower যোগ

চলন্ত database-এর ফাইল সরাসরি কপি করলে কপির মাঝেই ডেটা বদলায়; পুরো database lock করলে সেবা থামে। প্রচলিত পথ: leader-এর একটি consistent snapshot নেওয়া (lock ছাড়া, backup tool দিয়ে) আর সেই মুহূর্তের log-অবস্থান লিখে রাখা; snapshot নতুন যন্ত্রে বসানো; তারপর নতুন follower leader-এর কাছে ওই অবস্থানের পরের সব পরিবর্তন চেয়ে নিয়ে প্রয়োগ করে, অর্থাৎ catch up করে; lag স্বাভাবিক হলে পড়ার pool-এ যোগ। লুকানো শর্ত: snapshot-এর অবস্থান থেকে সব log leader-কে ধরে রাখতে হবে, নইলে আবার snapshot. উল্টো বিপদও আছে — মরা follower-এর জন্য log ধরে রাখতে গিয়ে leader-এর ডিস্ক ভরে যেতে পারে (PostgreSQL-এর replication slot-এর পরিচিত ফাঁদ)। Follower বিকল হলে কাজ সহজ: সে জানে কোন LSN পর্যন্ত প্রয়োগ করেছিল, ফিরে এসে সেখান থেকে বাকিটা চায়।

Leader বিকল — failover-এর তিন কাজ

পর্ব ৫-এ failover-এর সময়রেখা (detect, fence, promote, redirect) আর split-brain দেখেছেন; এখানে দেখব replication-এর চোখে কী হারায়। কাজ তিনটি: (১) মৃত্যু টের পাওয়া — নির্দিষ্ট সময় heartbeat না এলে timeout-এ মৃত ঘোষণা (পর্ব ৪৪); (২) নতুন leader বাছা — সাধারণত যার log সবচেয়ে এগিয়ে; নিরাপদ সিদ্ধান্তে লাগে leader election বা একটি controller (পর্ব ৪২); (৩) নতুন করে সাজানো — client আর follower-রা নতুন leader-এর দিকে, আর পুরোনো leader ফিরে যেন নিজেকে leader না ভাবে।

Async আর semi-sync-এ ঠিক কোন লেখা ঝুঁকিতে, বের করা যায়। নিচের সিমুলেটরে leader প্রতি ১০ ms-এ একটি লেখা নেয় (w1…w12) আর t = ১১৫ ms-এ মরে। F1 কাছে: এক দিকে ০.৫ ms আর গড়ে ৮ ms এলোমেলো দেরি; F2 দূরে: ৩০ ms আর গড়ে ২০ ms. প্রতিটি follower log প্রয়োগ করে ক্রম মেনে, আর semi-sync-এ “OK” আসে প্রথম ack-এর পরে:

// One write every 10 ms; the leader crashes at t = 115 ms. Which "OK"ed writes are lost?
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = seed + 0x6D2B79F5 | 0;
    let t = Math.imul(seed ^ seed >>> 15, 1 | seed);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rand = rng(5), exp = m => -m * Math.log(1 - rand());
const CRASH = 115;
const F = [{ name: "F1", net: 0.5, m: 8 }, { name: "F2", net: 30, m: 20 }]; // one-way ms
const last = [0, 0], W = [];                           // each follower applies IN ORDER
for (let k = 1; k <= 12; k++) {
  const t = (k - 1) * 10, w = { k, t, local: t + 1, at: [] };   // 1 ms local fsync
  F.forEach((f, i) => { last[i] = Math.max(last[i], t + f.net + exp(f.m)); w.at[i] = last[i]; });
  w.semi = Math.max(w.local, Math.min(...F.map((f, i) => w.at[i] + f.net))); // 1st follower ack
  W.push(w);
}
console.log("write  sent  F1 has it  F2 has it  semi-sync OK");
for (const w of W) console.log(("w" + w.k).padEnd(7) + String(w.t).padEnd(6) +
  w.at.map(a => (a.toFixed(1) + (a > CRASH ? " x" : "")).padEnd(11)).join("") + w.semi.toFixed(1));
const pos = F.map((f, i) => W.filter(w => w.at[i] <= CRASH).length);  // log position at crash
console.log("crash at " + CRASH + " ms: F1 has w1..w" + pos[0] + ", F2 has w1..w" + pos[1]);
for (const mode of ["async", "semi-sync"]) {
  const ok = W.filter(w => (mode === "async" ? w.local : w.semi) < CRASH);
  const avg = ok.reduce((s, w) => s + (mode === "async" ? w.local : w.semi) - w.t, 0) / ok.length;
  const lost = p => ok.filter(w => w.k > p).map(w => "w" + w.k).join(" ") || "none";
  console.log(mode.padEnd(10) + ": OK for " + ok.length + "/12 writes, avg wait " + avg.toFixed(1) + " ms");
  console.log("            promote F1 -> lost " + lost(pos[0]) + " | promote F2 -> lost " + lost(pos[1]));
}

write  sent  F1 has it  F2 has it  semi-sync OK
w1     0     9.9        59.6       10.4
w2     10    12.5       59.6       13.0
w3     20    21.2       67.9       21.7
w4     30    40.7       72.3       41.2
w5     40    59.4       75.2       59.9
w6     50    62.6       107.0      63.1
w7     60    69.1       107.0      69.6
w8     70    75.5       107.1      76.0
w9     80    98.6       116.8 x    99.1
w10    90    101.8      145.7 x    102.3
w11    100   102.8      145.7 x    103.3
w12    110   123.1 x    145.7 x    123.6
crash at 115 ms: F1 has w1..w11, F2 has w1..w8
async     : OK for 12/12 writes, avg wait 1.0 ms
            promote F1 -> lost w12 | promote F2 -> lost w9 w10 w11 w12
semi-sync : OK for 11/12 writes, avg wait 10.0 ms
            promote F1 -> lost none | promote F2 -> lost w9 w10 w11

স্বয়ংক্রিয় না হাতে?

স্বয়ংক্রিয় failover রাত ৩টায় সেকেন্ডে কাজ সারে; হাতে failover-এ মানুষ বুঝে সিদ্ধান্ত নেন, কিন্তু মিনিট যায়। স্বয়ংক্রিয় ব্যবস্থার বিপদ চারটি: ক্ষণিকের network partition-কে মৃত্যু ভাবা; পিছিয়ে থাকা follower promote করে লেখা হারানো; পুরোনো leader-কে থামাতে না পেরে split-brain; আর বারবার failover-এর দোলাচল। প্রচলিত নীতি: region-এর ভেতরে স্বয়ংক্রিয়, কড়া fencing-সহ; region পেরোনো failover-এ মানুষের অনুমোদন (পর্ব ৫-এর GitHub ২০১৮ ঘটনা)। পরিকল্পিত leader বদল — switchover — নিরাপদ: নতুন leader আগে পুরো log পর্যন্ত আসে, তাই কিছু হারায় না।

৬ · Multi-leader replication — একাধিক জায়গায় লেখা

তিনটি পরিস্থিতিতে single-leader কষ্টের। বহু ডেটা সেন্টার: leader এক অঞ্চলে হলে দূরের প্রতিটি লেখায় round trip, আর সেই ডেটা সেন্টার বিচ্ছিন্ন হলে সবখানে লেখা বন্ধ। প্রতিটি ডেটা সেন্টারে একটি leader রাখলে লেখা স্থানীয় আর দ্রুত; leader-রা async-এ বদল বিনিময় করে — multi-leader replication. Offline client: নেটওয়ার্ক ছাড়া চলা নোট বা জরিপের অ্যাপে প্রতিটি ফোনের database একটি leader, নেটওয়ার্ক পেলে অন্যদের সাথে মেলে — lag তখন ঘণ্টা বা দিন; Apache CouchDB-র মতো কিছু database এমন sync মাথায় রেখেই বানানো। একসাথে সম্পাদনা: প্রতিটি browser-এর কপি যেন একটি leader; অনেক collaborative editor operational transformation বা CRDT ব্যবহার করে (পর্ব ৪৬)।

দাম একটাই, কিন্তু বড়: write conflict. দুই অঞ্চলে একই শিরোনাম একই মুহূর্তে বদলানো হলো — দুই leader-ই স্থানীয়ভাবে “OK” বলেছে, পরে বিনিময়ে দুই মান। লেখার আগে দুই leader কথা বললে স্থানীয় লেখার সুবিধাই থাকে না, তাই conflict পরে মেটাতে হয়। সবচেয়ে ভালো কৌশল প্রায়ই conflict এড়ানো: একজন ব্যবহারকারীর সব লেখা তাঁর “বাড়ির” ডেটা সেন্টারে — প্রতিটি রেকর্ডের কার্যত একটিই leader. এটিও ভাঙে, যখন বাড়ির ডেটা সেন্টার বিকল বা ব্যবহারকারী অন্য দেশে।

Conflict মেটানোর উপায় — কোনটিতে কী হারায়

শর্ত একটাই: সব replica শেষে একই মানে পৌঁছাবে। পথ কয়েকটি (conflict resolution):

• Last-write-wins (LWW): সবচেয়ে বড় timestamp জেতে, বাকিগুলো নিঃশব্দে বাদ। সহজ, সব কপি একই ফলে পৌঁছায় — কিন্তু “OK” লেখাও হারায়, আর ঘড়ির পার্থক্যে (clock skew) আসলে পরের লেখাটিই হারতে পারে। “অঞ্চল ১ সবসময় জেতে” ধাঁচের অগ্রাধিকারও একইভাবে হারায়।
• মিলিয়ে দেওয়া (merge): দুটি তালিকার union, বা দুটি শিরোনাম জুড়ে “ক / খ”।
• দুটিই রেখে দেওয়া: database দুটি সংস্করণই (siblings) রাখে; পড়ার সময় অ্যাপ বা ব্যবহারকারী মেলান। কোনটি কোনটিকে “দেখে” লেখা, তা ধরে version vector (পর্ব ৩৯)।
• Conflict-মুক্ত data type: CRDT — যেকোনো ক্রমে মিলিয়ে একই ফল দেয় এমন counter, set বা টেক্সট (পর্ব ৪৬)।

দুই leader — A (ঢাকা) আর B (সিঙ্গাপুর) — একে অপরের খবর পাওয়ার আগেই একই key-তে লেখা নিল; B-র ঘড়ি ৩০০ ms পিছিয়ে। ঈদের বাজারের তালিকার শিরোনাম আর জিনিস — দুটি key-তে LWW আর version vector পাশাপাশি:

// Two leaders, A (Dhaka DC) and B (Singapore DC), accept writes to the same key before
// hearing about each other (replication delay 150 ms). B's clock runs 300 ms behind.
const skew = { A: 0, B: -300 };
const writes = [ // [real time ms, leader, key, value, version vector the writer had seen]
  [1000, "A", "title", "Eid list", { A: 1 }],
  [1100, "B", "title", "Eid list (final)", { B: 1 }],      // B has not seen A's write yet
  [2000, "A", "cart", ["sugar", "milk"], { A: 1 }],
  [2050, "B", "cart", ["sugar", "rice"], { B: 1 }],
  [3000, "A", "title", "Eid list (final)", { A: 2, B: 1 }], // user resolved, saw both
].map(([real, at, key, value, vv]) => ({ real, at, key, value, vv, ts: real + skew[at] }));

const lww = {}, sib = {};                     // final state on every replica
const covers = (a, b) => Object.keys(b).every(n => (a[n] || 0) >= b[n]); // a has seen b?
for (const w of writes) {
  // 1) last-write-wins: keep only the biggest timestamp, silently drop the rest
  if (!lww[w.key] || w.ts > lww[w.key].ts) lww[w.key] = w;
  // 2) version vectors: drop only versions the new write has seen; keep concurrent ones
  sib[w.key] = (sib[w.key] || []).filter(s => !covers(w.vv, s.vv)).concat([w]);
  const show = s => JSON.stringify(s.value) + "@" + s.at;
  console.log(`t=${w.real} ${w.at} ts=${w.ts} ${w.key}: LWW -> ${show(lww[w.key])}` +
    ` | kept: ${sib[w.key].map(show).join(" + ")}`);
}
const union = [...new Set(sib.cart.flatMap(s => s.value))];
console.log("cart after merge (union of versions): " + JSON.stringify(union));

t=1000 A ts=1000 title: LWW -> "Eid list"@A | kept: "Eid list"@A
t=1100 B ts=800 title: LWW -> "Eid list"@A | kept: "Eid list"@A + "Eid list (final)"@B
t=2000 A ts=2000 cart: LWW -> ["sugar","milk"]@A | kept: ["sugar","milk"]@A
t=2050 B ts=1750 cart: LWW -> ["sugar","milk"]@A | kept: ["sugar","milk"]@A + ["sugar","rice"]@B
t=3000 A ts=3000 title: LWW -> "Eid list (final)"@A | kept: "Eid list (final)"@A
cart after merge (union of versions): ["sugar","milk","rice"]

কে কার কাছে পাঠায় — replication topology

দুইয়ের বেশি leader হলে বদল কোন পথে ছড়াবে, তার নকশা — replication topology:

বৃত্ত আর তারকায় প্রতিটি বদলের সাথে “কোন node এটি দেখেছে” তালিকা থাকে, যাতে বদলটি অনন্তকাল না ঘোরে। All-to-all-এর ক্রম-সমস্যা timestamp-এ মেটে না (ঘড়ি অনির্ভরযোগ্য, পর্ব ৩৮); লাগে version vector-এর মতো কারণ-ফলের হিসাব। আর একটি গভীর সীমা: “একই সিট দুবার বিক্রি নয়” বা “username অনন্য” — দুই leader আলাদাভাবে যাচাই করলে দুই জায়গাতেই পাশ করে যায়। এমন ডেটার জন্য একটি leader (বা consensus) লাগে, বহু-leader নকশাতেও।

৭ · Leaderless replication — Dynamo-ধাঁচে সবাই লেখা নেয়

Leaderless replication-এ কোনো leader নেই, তাই failover-ও নেই। প্রতিটি key থাকে N টি replica-তে (consistent hashing-এর preference list, পর্ব ১৬)। Client, বা coordinator হিসেবে যেকোনো node, লেখাটি N টির সবাইকে পাঠায় আর W টির ack পেলেই সফল ধরে; পড়ায় R টিকে জিজ্ঞেস করে সংস্করণ-নম্বর দেখে সবচেয়ে নতুনটি নেয়। R + W > N হলে পড়ার দল আর লেখার দল অন্তত একটি replica-তে মেলে, তাই সাধারণত নতুন মান চোখে পড়ে — এর নাম quorum; প্রমাণ আর “সাধারণত” কেন “সবসময়” নয়, তা পর্ব ৪১-এর বিষয়।

ছবি ২২.১-এর তৃতীয় অংশে N = ৩, W = ২, R = ২। লেখার সময় R3 বন্ধ ছিল; R1 আর R2 ack দিল, লেখা সফল — R3-তে রয়ে গেল পুরোনো v1. পরে পড়া গেল R2 আর R3-তে: উত্তর v2 আর v1; client নতুনটি (v2) নিল। পুরোনো কপি দুইভাবে ঠিক হয়:

• Read repair: পড়ার সময়ই পুরোনো উত্তর দেখে coordinator R3-কে v2 লিখে দেয় — প্রায়ই পড়া ডেটা দ্রুত ঠিক হয়, কম পড়া ডেটা নয়।
• Anti-entropy: পেছনের একটি প্রক্রিয়া replica-দের নিয়মিত তুলনা করে যার যা নেই তা পাঠায়; Merkle tree-এর hash মিলিয়ে অল্প ডেটাতেই অমিল খোঁজা হয় (Dynamo paper-এর কৌশল)। ক্রম মানে না, দেরিও হতে পারে।

নির্ধারিত replica বন্ধ থাকলে অন্য node লেখাটি একটি নোটসহ সাময়িক রাখে, পরে আসল replica-কে পৌঁছে দেয় — hinted handoff (পর্ব ৪১)। সুবিধা: একটি node ধীর বা মৃত হলেও বাকিরা কাজ চালায়, failover-এর সিদ্ধান্ত লাগে না, ধীর replica এড়িয়ে latency-র লেজ ছোট থাকে। দাম: লেখার একক ক্রম নেই, তাই একই key-তে একসাথে দুটি লেখায় multi-leader-এর মতোই conflict — version vector আর sibling, অথবা LWW; Cassandra-র মতো কিছু ব্যবস্থায় column-ভিত্তিক LWW-ই default. আর quorum থাকলেও linearizability আপনাআপনি আসে না (পর্ব ৪০, ৪১)।

৮ · তিন নকশার তুলনা আর region পেরোনো replication

Region পেরোনো replication — দূরত্ব আর খরচের হিসাব

Latency: ধরা যাক দুই region ৩,০০০ km দূরে। কাচের তারে আলো সেকেন্ডে প্রায় ২,০০,০০০ km যায়, তাই যাওয়া-আসায় অন্তত ২ × ৩,০০০ ÷ ২,০০,০০০ সেকেন্ড = ৩০ ms; আসল পথ সরলরেখা নয়, তাই বাস্তবে সাধারণত বেশি (পর্ব ৭)। দূরের region sync হলে প্রতিটি commit-এ অন্তত এটুকু যোগ হয়। খরচ: ধরা যাক সেকেন্ডে ২,০০০ লেখা, প্রতিটির log গড়ে ১ KB (১,০০০ বাইট) — স্রোত সেকেন্ডে ২ MB, দিনে ১৭২.৮ GB, ৩০ দিনে প্রায় ৫.১৮ TB, প্রতিটি দূরের region-এর জন্য আলাদা। অনেক cloud প্রদানকারী region-এর মাঝে ডেটা পাঠাতে প্রতি GB হিসাবে দাম নেয়; হার প্রদানকারী ও সময়ভেদে আলাদা, তাই দামের পাতায় মিলিয়ে নিন। Compression আর শুধু দরকারি টেবিল পাঠানো বিল কমায়।

প্রচলিত নকশা চারটি: (১) এক region-এ leader, অন্যগুলোতে async follower — পড়া স্থানীয়, দূরের follower বিপর্যয়ের বিকল্প (পর্ব ৫১); (২) ডেটা ব্যবহারকারীর “বাড়ির” region অনুযায়ী ভাগ, প্রতিটি ভাগের leader নিজের region-এ; (৩) multi-leader, conflict মেনে নিয়ে; (৪) region পেরোনো consensus, যেখানে commit-এ লাগে সংখ্যাগরিষ্ঠের round trip (পর্ব ৪২)। কিছু দেশের আইনে নির্দিষ্ট ডেটা দেশের ভেতরে রাখার শর্ত থাকতে পারে — কোন কপি কোথায়, সেটিও তখন নকশার অংশ।

৯ · AI-এর যুগে replication-এর নকশা যাচাই

“Database-কে highly available আর scalable বানাও” লিখলে AI মুহূর্তে বলে: “read replica, multi-master, সাথে Kafka আর Redis.” শুনতে পেশাদার, কিন্তু replication-এ কিছু ভুল AI প্রায় নিয়ম করে করে:

AI-এর দেওয়া replication-নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• লেখার হার দিয়ে follower-সংখ্যা আর sync follower-এর দূরত্ব দিয়ে commit latency নিজে হিসাব করেছি
• Leader মরলে কতগুলো “OK” লেখা হারাতে পারে (লেখার হার × lag) বের করে RPO-র সাথে মিলিয়েছি
• কোন পাতায় read-your-writes বা monotonic reads লাগবে আর কীভাবে route হবে, লিখে নিয়েছি
• Failover-এর failure-mode পর্যালোচনা করেছি: পিছিয়ে থাকা follower, ID-র পুনর্ব্যবহার, fencing, ভুল timeout; multi-leader হলে conflict-এর নিয়ম
• প্রতিটি setting আর দাম documentation-এ মিলিয়েছি; সম্ভব হলে একটি ছোট পরীক্ষায় lag মেপেছি