تکرار (Replication)
تکرار دیتابیس: Master-Slave، Multi-Master، مشکلات تأخیر تکرار و خواندن از Replica
چرا تکرار؟
سه دلیل:
- دسترس‌پذیری: سرور اصلی مرد؟ Replica جایگزین!
- کارایی: خواندن‌ها را بین چند سرور پخش کن
- داده نزدیک: Replica در منطقه جغرافیایی دیگر = تأخیر کمتر
الگوی Master-Slave (Primary-Replica)
نوشتن → فقط Master
خواندن → Master یا Replica ها
Master ──(کپی async)──→ Replica 1
──→ Replica 2- مزیت: ساده، خواندن مقیاس‌پذیر ✓
- عیب: نوشتن همچنان تک‌نقطه! Master مرد؟ انتخاب Replica جدید (Failover)
الگوی Multi-Master
همه نودها نوشتن می‌پذیرند:
- مزیت: بدون تک‌نقطه نوشتن؛ مقاوم به قطعی منطقه
- عیوب: تضاد نوشتن! (دو نود، یک رکورد، دو مقدار) — حل تضاد پیچیده؛ سازگاری سقوط می‌کند
مشکل شماره ۱: تأخیر تکرار (Replication Lag)
کپی معمولاً async است:
کاربر پست می‌گذارد → Master ذخیره ✓
کاربر فوراً تایم‌لاین را می‌خواند → Replica هنوز قدیمی!
→ «پستم کجاست؟!» 😤راه‌حل‌ها:
- Read-Your-Own-Writes: نوشتن‌های اخیر کاربر را از Master بخوان
- خواندن هم‌زمان (Sync): کند اما تازه — برای داده حساس
- Session Stickiness: درخواست‌های یک Session به یک نود
Failover — مردن Master
- تشخیص (Health Check)
- انتخاب Replica جدید (معمولاً به‌روزترین)
- ارتقا به Master + هدایت نوشتن‌ها
- بقیه Replica ها به جدید وصل شوند
خطر: داده‌های «در راه» از دست می‌روند — ترید‌آف RPO!
نکته مصاحبه: «خواندن از Replica» را با ذکر مشکل lag بگویید: «Replica برای خواندن، اما write-then-read از Master» — همین دقت تمایز میcreates.
جمع‌بندی
- تکرار: دسترس‌پذیری + خواندن موازی + نزدیکی
- Master-Slave: نوشتن تک، خواندن چند
- Multi-Master: بدون تک‌نقطه اما تضاد!
- Lag: read-your-writes از Master
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.