ב-2017, GitLab אבדה כ-300GB של production data. לא בגלל cyberattack - בגלל שאדמין אחד הריץ rm -rf על ה-DB הלא נכון. הם גיבו, אבל כשניסו לשחזר - גילו שחמישה מתוך חמישה backup strategies שלהם נכשלו. WAL-E backup לא עבד. S3 replication לא היה מאופשר. ה-LVM snapshots היו ב-volume הלא נכון. הם איבדו 6 שעות של data ו-Database Replication שלהם לא הייתה configured נכון.
Database Replication הוא תהליך העתקת data מ-database אחד (Primary) לאחד או יותר (Replicas). זה פותר שני בעיות: High Availability (אם Primary נופל, Replica ממשיך) ו-Read Scalability (Replicas מקבלים reads, Primary מוקדש לwrites).
ה-incident של GitLab הפך לאחד מ-post-mortems הידועים ביותר בindustry - לא כי הם עשו משהו מוזר, אלא כי הם דיברו על זה בpublic בzמן אמת. הם עשו live stream של ה-recovery. אם יש לקח אחד: Replication ו-backup שלא נבדקו מעולם לrestore הם לא Replication ו-backup - הם Security Theater.
מה שמייחד את incident הGitLab היא הredundancy של הכשלים. זה לא שreplication אחת נכשלה - חמש strategies נכשלו בו-זמנית. WAL-E לא היה configured כראוי מאז שינוי infrastructure חודשיים קודם ואיש לא בדק. S3 replication הייתה מאופשרת בdocumentation אבל לא בפועל. LVM snapshot הייתה על ה-staging DB, לא ה-production DB. ה-point בכל זה: לא מספיק שreplication קיימת - חייבים לבדוק אותה. GitLab קבעה אחרי ה-incident שכל backup יבדק לrestore בכל שבוע. אם restore test נכשל - זה incident.
Stripe, שמטפלת בעשרות מיליארדי דולרים בתשלומים בשנה, מריצה PostgreSQL עם synchronous replication לshards הפיננסיים הרגישים ביותר - המשמעות היא שwrite לא מאושרת לclient עד שלפחות replica אחת אישרה. write latency גבוה יותר בcritical path - אבל לא ניתן לאבד אפילו transaction אחת של כסף. Tradeoff ברור.