Database Replication - Master-Slave, Multi-Master

Database Replication - Master-Slave, Multi-Master

GitHub, 2012. MySQL Primary נופל. Secondary אמורה להתרומם. הבעיה: replication lag של 45 שניות - 45 שניות של writes שה-secondary לא קיבלה. Failover בוצע, אבל 45 שניות של transactions אבדו. הם שינו architure: synchronous replication על critical data, monitoring replication lag כ-first-class metric.

Airbnb מריצה PostgreSQL Replication עם 20+ read replicas. כל read query - search, listing pages, user profiles - הולכת ל-replica. רק writes הולכים ל-primary. ה-primary פנוי לwrites בלבד, הscale של reads הוא horizontal.

Replication היא הדבר הראשון שמוסיפים לdatabase כש-scale גדל. לא Sharding, לא NoSQL - Replication. היא פותרת שני בעיות: availability (primary נופל? יש secondary) ו-read scaling (primary עמוס? קראו מ-replicas).

בלי replication, database הוא single point of failure. בסביבת production, זה לא מקובל. אפילו "ה-database נמצא ב-managed service כמו AWS RDS" - צריך Multi-AZ deployment, שהוא בעצם synchronous replication למדינה שנייה.

ה-concept של RTO ו-RPO הוא לא רק ל-DBA. כל developer שעוצב feature כדאי לו לחשוב: "מה קורה לfeature הזה אם ה-database לא זמין ל-5 דקות? מה קורה אם יש data loss של 30 שניות?" אלה שאלות שקובעות design decisions: האם לbuffer events לפני write? האם להשתמש ב-optimistic locking? האם לתת user feedback ב-optimistic update? כשמבינים את ה-RPO ו-RTO requirements, ה-technical decisions נעשות ברורות יותר. אם מריצים PostgreSQL עצמאית על server בלי standby - חושבים על RPO ו-RTO: כמה data loss מקובל? כמה זמן downtime מקובל? עבור production applications, התשובה הנורמטיבית היא "פחות ממינוט downtime, פחות מ-5 שניות data loss" - ורק replication מאפשר את זה.

RTO (Recovery Time Objective) - כמה זמן עד שהמערכת חזרה לפעולה אחרי failure. RPO (Recovery Point Objective) - כמה data אפשר לאבד. אלה שאלות עסקיות, לא טכניות. מערכת billing של SaaS: RPO=0 (אסור לאבד transactions), RTO=30 שניות. dashboard analytics: RPO=5 דקות (בסדר לאבד 5 דקות), RTO=10 דקות. ה-technical design נובע מה-business requirements.