🗃️ धडा 17 — RDS: भाड्याने घेतलेले दप्तर कार्यालय

📍 तुम्ही इथे आहात: 20 पैकी धडा 17 · मागील: lesson-16-route53 · पुढील: lesson-18-cloudwatch

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

धडे 01–17. प्रत्येक खऱ्या system चे stateful हृदय — आणि "managed" आपली किंमत वसूल करते अशी पहिली service.

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

शाळेच्या नोंदी — गुण, प्रवेश, फी — दप्तर कार्यालयात 🗃️ राहतात: म्हणजे database. तुमच्याकडे दोन पर्याय आहेत:

स्वतः चालवा एका बाकावर (EC2 वर Postgres): तुम्हीच कारकून बनता. रात्रीच्या photocopies, software patches, हे कार्यालय पाण्याखाली गेल्यावर एक जादा कार्यालय, पहाटे 3 वाजताची recovery — सगळे तुम्ही, कायमचे.
कारकुनासह कार्यालय भाड्याने घ्या — RDS. तुम्ही engine निवडता (Postgres, MySQL…) आणि कार्यालयाचा आकार; backups, patching आणि failover ची कवायत AWS करतो.

भाडेकरूचे तीन फायदे:

रात्रीच्या photocopies 📸 — automated backups + point-in-time restore: "मंगळवारी 14:03 ला जसे होते तसे कार्यालय."
आरसा कार्यालय 🪞 — Multi-AZ: शेजारच्या इमारतीत हुबेहूब standby, दर second ला sync. Primary पाण्याखाली → AWS साधारण एका मिनिटात phonebook मधली नोंद आरशाकडे वळवतो. तुमचे app फक्त… पुन्हा connect होते. आरसा टिकण्यासाठी आहे, वाचण्यासाठी नाही — failover होईपर्यंत तो कोणताही traffic देत नाही.
वाचकांसाठी photocopy बाक 📚 — read replicas: अहवालांचा जड हंगाम? फक्त-वाचण्याच्या प्रती जोडा; लिहिणारे खरे कार्यालय वापरत राहतात. या read scaling साठी बनवलेल्या वेगळ्या प्रती आहेत — Multi-AZ standby नव्हे.

आणि संपूर्ण course एकत्र बांधणारा एक तपशील: तुमच्या app ला कार्यालयाचा आकडा कधीच कळत नाही — ते endpoint ला फोन करते (एक DNS नाव, धडा 16 ची phonebook!) जे नेहमी सध्याच्या primary कडे निर्देश करते. Reception-desk ची युक्ती, state ला लावलेली.

🗺️ आकृती

flowchart LR
    app["🖥️ app (private wing)"]
    ep["☎️ endpoint DNS<br/>school-db.xyz.rds.amazonaws.com"]
    p["🗃️ primary office (AZ-a)<br/>private subnet, SG: app only"]
    m["🪞 standby mirror (AZ-b)<br/>synced · failover only, no reads"]
    bak["📸 nightly photocopies<br/>+ point-in-time restore"]
    rr["📚 read replica(s)<br/>reports go here"]
    app -->|"1 dial the name"| ep -->|"2"| p
    p ==>|"3 sync"| m
    p -->|"4"| bak
    p -.->|"async"| rr

❓ काय

Multi-AZ ≠ read replica: आरसा टिकण्यासाठी (sync, अदृश्य, auto-failover); replicas वाचण्यासाठी (async, दृश्य, failover चे वचन नाही). परीक्षेचा आवडता प्रश्न, outage चाही आवडता.
जागा: private subnets (धडा 13), SG फक्त app बाकांच्या SG ला allow करणारा (पुन्हा धडा 10 चा pattern).
k8s StatefulSets शी तुलना (k8s धडा 22): नावाच्या पाट्या असलेल्या बाकांसह तुम्ही cluster मध्ये Postgres चालवू शकता — फक्त तुम्ही पुन्हा कारकून बनता, जास्तीच्या पायऱ्यांसह. बहुतेक teams: stateless k8s मध्ये, state RDS मध्ये. कंटाळवाणे विकत घ्या, खास ते बांधा.
Aurora: AWS चे स्वतःचे engine — तेच दार, भारी इमारत (storage 3 इमारतींत 6× photocopy केलेले, जलद failover, महाग).

🤔 का

State मध्ये cloud च्या चुका हसण्यावारी नेता येत नाहीत. हरवलेला stateless बाक = खांदे उडवणे (धडा 12 तो बदलतो). हरवलेले दप्तर कार्यालय = शाळेकडे गुणच नाहीत. हा असमतोल हाच कारकुनाला पैसे देण्याचा संपूर्ण युक्तिवाद आहे: जे भाग कोणाचे तरी पूर्णवेळ कौशल्य आहेत — खरोखर restore होणारे backups, खरोखर failover होणारे failovers — ते भाड्याने, तपासलेले आणि कंटाळवाणे मिळतात.

🔧 कसे

aws rds describe-db-instances --query \
  'DBInstances[].{id:DBInstanceIdentifier,engine:Engine,size:DBInstanceClass,multiAZ:MultiAZ,endpoint:Endpoint.Address}'
# the failover drill (Multi-AZ instances):
aws rds reboot-db-instance --db-instance-identifier school-db --force-failover

🧪 करून पाहा (~20 मिनिटे, db.t4g.micro free tier वर ~मोफत — नंतर DESTROY करा)

तुमच्या lab VPC च्या private subnets मध्ये db.t4g.micro Postgres बनवा, एका बाकावरून endpoint नावाला psql करा, एक row insert करा, --force-failover ने reboot करा, आणि तेच नाव दुसऱ्या इमारतीतून उत्तर देताना पाहा. मग ते delete करा (lab मध्ये final snapshot वगळा, आणि ते खरोखर गेले का ते तपासा — का ते धडा 20 सांगतो).

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

psql -h ENDPOINT private बाकावरून connect होते; reboot-db-instance --force-failover नंतर तोच endpoint दुसऱ्या AZ मधून पुन्हा उत्तर देतो.

🧹 साफसफाई — चालू ठेवू नका

DB instance delete करा (lab मध्ये final snapshot वगळा) आणि describe-db-instances रिकामे आहे याची खात्री करा — RDS तासाप्रमाणे bill करते

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

'testing साठी' publicly accessible database
Multi-AZ standby reads देतो असे गृहीत धरणे — तो देत नाही
Final snapshot सह delete करणे आणि त्याचे पैसे कायम भरत राहणे

⏭️ पुढे

बाक, files, गर्दी, नावे, नोंदी — सगळे चालू. पण पहाटे 3 वाजता या सगळ्यावर लक्ष कोण ठेवते? धडा 18: CloudWatch — प्रगतिपुस्तके, डायऱ्या आणि धोक्याच्या घंटा.

🗃️ Lesson 17 — RDS: the record office you rent

📍 You are here: Lesson 17 of 20 · Previous: lesson-16-route53 · Next: lesson-18-cloudwatch

📦 What's in this branch

Lessons 01–17. The stateful heart of every real system — and the first service where "managed" earns its price tag.

🧒 Explain like I'm 5

The school's records — grades, enrollments, fees — live in the record office 🗃️: the database. You have two choices:

Run it yourself on a desk (Postgres on EC2): YOU become the clerk. Nightly photocopies, software patches, a spare office when this one floods, 3 AM recoveries — all you, forever.
Rent the office WITH a clerk included — RDS. You pick the engine (Postgres, MySQL…) and the office size; AWS does backups, patching, and the failover drill.

The three renter's perks:

Nightly photocopies 📸 — automated backups + point-in-time restore: "the office as it was Tuesday, 14:03."
The mirror office 🪞 — Multi-AZ: an exact standby in the next building, synced every second. Primary floods → AWS flips the phonebook entry to the mirror in ~a minute. Your app just… reconnects. The mirror is for surviving, not for reading — it serves no traffic until the failover.
Photocopy desks for readers 📚 — read replicas: heavy report season? Add read-only copies; writers keep the real office. These are separate copies built for read scaling — not the Multi-AZ standby.

And one detail that ties the whole course: your app never learns the office's number — it dials the endpoint (a DNS name, lesson 16's phonebook!) which always points at the current primary. The reception-desk trick, applied to state.

🗺️ Diagram

flowchart LR
    app["🖥️ app (private wing)"]
    ep["☎️ endpoint DNS<br/>school-db.xyz.rds.amazonaws.com"]
    p["🗃️ primary office (AZ-a)<br/>private subnet, SG: app only"]
    m["🪞 standby mirror (AZ-b)<br/>synced · failover only, no reads"]
    bak["📸 nightly photocopies<br/>+ point-in-time restore"]
    rr["📚 read replica(s)<br/>reports go here"]
    app -->|"1 dial the name"| ep -->|"2"| p
    p ==>|"3 sync"| m
    p -->|"4"| bak
    p -.->|"async"| rr

❓ What

Multi-AZ ≠ read replica: the mirror is for surviving (sync, invisible, auto-failover); replicas are for reading (async, visible, no failover promise). Exam favorite, outage favorite.
Placement: private subnets (lesson 13), SG allowing only the app desks' SG (lesson 10's pattern, again).
vs k8s StatefulSets (k8s lesson 22): you CAN run Postgres in the cluster with name-plate desks — you're just the clerk again, with extra steps. Most teams: stateless in k8s, state in RDS. Buy the boring, build the special.
Aurora: AWS's own engine — same doorway, fancier building (storage photocopied 6× across 3 buildings, faster failover, pricier).

🤔 Why

State is where cloud mistakes stop being funny. A lost stateless desk = a shrug (lesson 12 replaces it). A lost record office = the school has no grades. That asymmetry is the whole argument for paying the clerk: the parts that are someone's full-time craft — backups that restore, failovers that fail over — come rented, tested, and boring.

🔧 How

aws rds describe-db-instances --query \
  'DBInstances[].{id:DBInstanceIdentifier,engine:Engine,size:DBInstanceClass,multiAZ:MultiAZ,endpoint:Endpoint.Address}'
# the failover drill (Multi-AZ instances):
aws rds reboot-db-instance --db-instance-identifier school-db --force-failover

🧪 Try it (~20 min, ~free on db.t4g.micro free tier — DESTROY after)

Create a db.t4g.micro Postgres in your lab VPC's private subnets, psql to the endpoint name from a desk, insert a row, reboot with --force-failover, watch the same name answer from the other building. Then delete it (skip the final snapshot in a lab, and check it's gone — lesson 20 explains why).

✅ Verify — what you should see

psql -h ENDPOINT connects from a private desk; after reboot-db-instance --force-failover the same endpoint answers again from the other AZ.

🧹 Clean up — do not leave running

delete the DB instance (skip the final snapshot in a lab) and confirm describe-db-instances is empty — RDS bills hourly

⚠️ Common mistakes

a publicly accessible database 'for testing'
assuming the Multi-AZ standby serves reads — it doesn't
deleting with a final snapshot and paying for it forever

⏭️ Next

Desks, files, crowds, names, records — running. But who's watching it all at 3 AM? Lesson 18: CloudWatch — report cards, diaries, and alarm bells.

← Previousroute53 Next →cloudwatch

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