📡 धडा 16 — Replication आणि failover: खोलीच्या प्रती

📍 तुम्ही इथे आहात: 18 पैकी धडा 16 · मागील: lesson-15-inside-the-engine · पुढील: lesson-17-app-code

भाग 3 — अधिक खोलात. धडे 01–12 नी रेकॉर्ड रूम बांधली आणि चालवली. धडे 13–18 हे interviews आणि incidents मध्ये विचारले जाणारे विषय आहेत — प्रत्येक त्याच school.db वर प्रत्यक्ष चालतो.

📦 या ब्रँचमध्ये काय आहे

धडे 01–16, आणि db/demo.py मधले replica(). हे एक simulation आहे: school.db primary ची भूमिका करते, memory मधली एक प्रत replica ची, आणि एक Python list पाठवलेल्या log ची. ते replication lag, मागे पडलेले भरून काढणे, आणि एक write गमावणारा async failover दाखवते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळा दुसऱ्या इमारतीत रेकॉर्ड रूमची एक प्रत ठेवते. मुख्य खोलीत प्रत्येक वेळी बदल झाला की एक निरोप्या डायरीतल्या ओळी (धडा 15) तिकडे घेऊन जातो. ही प्रत वाचणाऱ्यांसाठी उपयोगी आहे — आणि मुख्य खोली जळून गेली, तर ही प्रतच मुख्य खोली बनते.

पण निरोप्याला वेळ लागतो. एक पालक दियाचे नाव नोंदवतात, आणि निरोप्या पोहोचण्याआधीच प्रतीवरून page reload करतात — "दिया कुठे आहे?" हाच replication lag. आणि एखादी ओळ अजून निरोप्याच्या पिशवीत असताना मुख्य खोली जळाली, तर ती ओळ हरवते. जोपर्यंत office "झाले" म्हणण्याआधी प्रतीने "मिळाले" म्हणण्याची वाट पाहत नाही — synchronous replication — जे जास्त सुरक्षित पण हळू आहे.

🗺️ आकृती

flowchart LR
    p["🗄️ primary<br/>all writes"]
    r1["📖 replica 1<br/>lag 0.2 s"]
    r2["📖 replica 2<br/>lag 3 s"]
    p -->|WAL stream| r1
    p -->|WAL stream| r2
    p -. "💥 dies" .-> f["🚑 promote a replica<br/>async: last writes may be lost"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/database/lesson-diagrams.html#l16

❓ काय

Streaming replication — primary आपला log replicas कडे पाठवतो, आणि ते तो पुन्हा चालवतात (Postgres physical replication, MySQL binlog replication). Replicas reads देतात.
Replication lag — replica किती मागे आहे. तुमचे स्वतःचे writes primary वरून वाचा, किंवा replica बरोबरीला येईपर्यंत थांबा.
Asynchronous (default) — कोणत्याही replica कडे बदल पोहोचण्याआधीच COMMIT परत येतो. जलद; failover वेळी शेवटचे writes गमावले जाऊ शकतात (RPO > 0, धडा 09).
Synchronous — COMMIT किमान एका replica च्या acknowledgement ची वाट पाहतो. Failover वेळी commit झालेले काहीच गमावले जात नाही (RPO = 0); प्रत्येक commit ला एक network round trip लागतो, आणि आजारी replica writes अडवू शकतो.
Failover — एका replica ला primary बनवा आणि apps त्याच्याकडे वळवा (DNS name किंवा proxy). Managed services हे तुमच्यासाठी करतात (AWS school L17: Multi-AZ).
CAP, एका ओळीत — network फुटले असताना तुम्हाला निवड करावी लागते: काही writes नाकारा (consistent राहा) किंवा दोन्ही बाजूंना writes स्वीकारा आणि नंतर जुळवा (available राहा).

🤔 का

प्रत्येक production database ची एक प्रत असते; प्रश्न असा की ती किती ताजी आहे आणि failover ची किंमत काय. Sync विरुद्ध async माहीत असले की outage मध्ये काय गमावले जाते हे तुम्ही आकड्यासह सांगू शकता.

🔧 कसे (या repo मध्ये)

db/demo.py मधले replica() primary वर दियाची नोंद करते, दोन्ही बाजूंना विद्यार्थी मोजते, log पाठवते, मग इशानला लिहिते आणि log पाठवण्याआधीच primary ला "मारते".

🧪 करून पाहा

python3 db/demo.py replica
# then change replica() so ship() is called inside write() — that is synchronous replication.
# Run it again: Ishaan survives the failover.

✅ तपासा — तुम्हाला काय दिसायला हवे

primary: 6 students · replica, before the log arrives: 5 — replication lag, मग log पाठवल्यावर 6, मग failover नंतर Ishaan is LOST. तुमच्या synchronous बदलासह इशान तिथे असतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुम्ही lag, स्वतःचे writes वाचणे, आणि async failover नेमके कोणते writes गमावतो हे समजावू शकता — आणि ते टाळण्यासाठी synchronous replication ची किंमत काय हेही.

⚠️ नेहमीच्या चुका

स्वतःचा ताजा write replica वरून वाचणे आणि तो "हरवणे"
replica म्हणजे backup असे गृहीत धरणे — DELETE सुद्धा replicate होतो; backups (धडा 09) वेगळे आहेत
प्रत्येक commit वर दूरच्या region कडे synchronous replication
खऱ्या outage पर्यंत failover कधीच test न करणे
failover हलवू शकेल अशा name ऐवजी apps मध्ये primary चा IP hard-coded

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: RPO/RTO targets sync विरुद्ध async ठरवतात; failover drills आणि replica-lag alerts प्रत्येक database runbook वर असतात.

⏭️ पुढे

git checkout lesson-17-app-code — app मधून दिसणारा database.

📡 Lesson 16 — Replication & failover: copies of the room

📍 You are here: Lesson 16 of 18 · Previous: lesson-15-inside-the-engine · Next: lesson-17-app-code

Part 3 — going deeper. Lessons 01–12 built and ran the record room. Lessons 13–18 are the topics interviews and incidents ask about — each one runs for real on the same school.db.

📦 What's in this branch

Lessons 01–16, plus replica() in db/demo.py. It is a simulation: school.db plays the primary, an in-memory copy plays the replica, and a Python list plays the shipped log. It shows replication lag, catching up, and an async failover that loses a write.

🧒 Explain like I'm 5

The school keeps a copy of the record room in another building. Every time the main room changes, a messenger carries the diary lines (lesson 15) across. The copy is useful for readers — and if the main room burns down, the copy becomes the main room.

But the messenger takes time. A parent enrols Diya, then reloads the page from the copy before the messenger arrives — "where is Diya?" That is replication lag. And if the main room burns down while a line is still in the messenger's bag, that line is lost. Unless the office waits for the copy to say "got it" before saying "done" — synchronous replication — which is safer but slower.

🗺️ Diagram

flowchart LR
    p["🗄️ primary<br/>all writes"]
    r1["📖 replica 1<br/>lag 0.2 s"]
    r2["📖 replica 2<br/>lag 3 s"]
    p -->|WAL stream| r1
    p -->|WAL stream| r2
    p -. "💥 dies" .-> f["🚑 promote a replica<br/>async: last writes may be lost"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/database/lesson-diagrams.html#l16

❓ What

Streaming replication — the primary sends its log to replicas, which replay it (Postgres physical replication, MySQL binlog replication). Replicas serve reads.
Replication lag — how far behind a replica is. Read your own writes from the primary, or wait until the replica has caught up.
Asynchronous (the default) — COMMIT returns before any replica has the change. Fast; on failover the last writes can be lost (RPO > 0, lesson 09).
Synchronous — COMMIT waits for at least one replica's acknowledgement. Nothing committed is lost on failover (RPO = 0); every commit pays a network round trip, and a sick replica can stall writes.
Failover — promote a replica to primary and point the apps at it (a DNS name or a proxy). Managed services do this for you (AWS school L17: Multi-AZ).
CAP, in one line — during a network split you must choose: refuse some writes (stay consistent) or accept writes on both sides and reconcile later (stay available).

🤔 Why

Every production database has a copy; the questions are how fresh it is and what a failover costs. Knowing sync vs async lets you say, with a number, what an outage loses.

🔧 How (in this repo)

replica() in db/demo.py enrols Diya on the primary, counts pupils on both sides, ships the log, then writes Ishaan and "kills" the primary before shipping.

🧪 Try it

python3 db/demo.py replica
# then change replica() so ship() is called inside write() — that is synchronous replication.
# Run it again: Ishaan survives the failover.

✅ Verify — what you should see

primary: 6 students · replica, before the log arrives: 5 — replication lag, then 6 after shipping, then Ishaan is LOST after the failover. With your synchronous change, Ishaan is there.

🏁 What you just proved

You can explain lag, read-your-own-writes, and exactly which writes an async failover loses — and what synchronous replication costs to prevent it.

⚠️ Common mistakes

reading your own fresh write from a replica and "losing" it
assuming a replica is a backup — a DELETE replicates too; backups (lesson 09) are separate
synchronous replication to a far-away region on every commit
never testing failover until the real outage
apps with the primary's IP hard-coded instead of a name that failover can move

🏭 Why this matters in production: RPO/RTO targets decide sync vs async; failover drills and replica-lag alerts are on every database runbook.

⏭️ Next

git checkout lesson-17-app-code — the database, seen from the app.

← Previousinside the engine Next →app code

This page is the lesson's README from the lesson-16-replication-failover branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.