یک رستوران زنجیرهای را تصور کن که فقط یک دفترچه دستور پخت در تهران دارد. شعبه شیراز هر بار زنگ میزند. اگر آن دفترچه سوخت، کل زنجیره میخوابد. راهحل: چند کپی زنده از همان دفترچه. در دیتابیس به این کار میگویند Replication.
سه شغل دارد: اگر یکی سوخت داده هست — Durability — خواندنها بین شعب پخش میشوند — مقیاس Read — و داده به مشتری دور نزدیک میشود. نوشتن هنوز از یک جا میگذرد؛ این را با Sharding قاطی نکن.
چه کسی مینویسد، چه کسی کپی میکند
رایجترین مدل مثل همان آشپزخانه مرکزی است: یک نفر میپزد، بقیه کپی میگیرند و مشتری را سرو میکنند. اسمها را حفظ نکن؛ بپرس نوشتن از چند نقطه وارد میشود و کپی چقدر معطل میماند.
دو دردسر کلاسیک
کپی زنده همیشه کمی عقب است، و رئیس همیشه زنده نمیماند. هر دو را از قبل طراحی کن، نه بعد از تماس مشتری.
- Replication Lag: کاربر پروفایلش را عوض میکند — نوشتن به Leader — و بلافاصله صفحه را میخواند از Follower عقبمانده. تغییرش را نمیبیند. راهحل: Read-Your-Writes — خواندن حساسِ همان کاربر تا چند ثانیه از Leader.
- Failover: با مرگ Leader یک Follower ارتقا مییابد. خطر Split-Brain: اگر Leader قدیمی برگردد و هنوز فکر کند رئیس است، دو نقطه نوشتن متعارض داری. برای همین Failover خودکار به Quorum و Fencing نیاز دارد.
به زبان ساده
Replication یعنی چند کپی زنده از دفترچه دستور، تا سوختن یکی زنجیره را نخواباند.
مثال واقعی
اگر کاربر نامش را عوض کرد و فوراً نام قدیمی دید، از شعبه عقبمانده خوانده — Read-Your-Writes یعنی خود او را از Leader بخوان.