Database Migration Strategies - Zero-Downtime Migrations
2017, GitHub עשתה migration של column אחד ב-MySQL table עם 5 מיליארד שורות. RENAME COLUMN היה אמור לקחת שניות - אבל בMySQL, ALTER TABLE locks את הtable. 5 מיליארד שורות = שעות של downtime. הם השתמשו ב-pt-online-schema-change - tool שמבצע migration בלי לlock ה-table. זמן migration: 72 שעות. Downtime: 0.
Braintree (PayPal) עשה migration מPostgreSQL לPostgreSQL תוך כדי traffic ל-3 מיליארד transactions. Zero downtime. הם השתמשו בpattern של dual-write + gradual cutover. 6 חודשים של עבודה, 0 שניות downtime.
Database migrations הן הפעולה הכי מסוכנת שצוות פיתוח יכול לבצע. Schema change שגוי יכול לנעול table, לשחרר data corruption, או לקרוס את כל ה-production database. אבל migration שנכתבת נכון? אפשר לעשות אותה בלי שאף לקוח ירגיש.
מה שהופך migrations למסוכנות הוא ה-combination של: נתונים קיימים שחייבים להישמר, application code שרץ תוך כדי ה-migration, וdatabase engine שמבצע locking.
ה-incident הנפוץ ביותר שאני שומע מteams: "עשינו ALTER TABLE בproduction ונפלנו ל-15 דקות downtime". הדפוס כמעט תמיד אותו - developer הוסיף column על table גדול, לא בדק גודל, לא ידע שביPostgreSQL ישן יש table lock. ב-2025 עם PostgreSQL 11+ רוב הunsafe operations תוקנו, אבל עדיין יש edge cases. ה-discipline של "בדוק migration על production-size data לפני" שווה כל incident שהוא מונע.
אחד הדברים שארגונים גדולים עושים: separate migration deployment מcode deployment. migration רץ קודם, ורק אחרי validation code חדש deploy. זה מאפשר rollback של code בלי rollback של schema. Expand-Contract pattern מבוסס על זה: schema תמיד backward-compatible עם code קודם. כשמוסיפים column קטן לtable עם 100 שורות - לא מרגישים כלום. כשמוסיפים אותו column לtable עם 500 מיליון שורות ב-production בscale של Netflix - זה שאלה של חיים ומוות לsystem.
הgap בין developer שכותב migrations ל-developer שכותב migrations נכון הוא ניסיון שנצבר בדרך כלל אחרי incident אחד קשה. השיעור הזה נועד לחסוך לכם את ה-incident הזה.