बिना downtime के डेटाबेस schema का breaking बदलाव आप कैसे शिप करेंगे?

expand and contract पैटर्न इस्तेमाल करें। पहले expand: नया column या table इस तरह जोड़ें कि पीछे से मेल खाता रहे और अभी डिप्लॉय कोड चलता रहे। फिर ऐसा कोड डिप्लॉय करें जो पुराने और नए दोनों में लिखे, मौजूदा rows को छोटे batches में backfill करें, reads को नए ढांचे पर स्विच करें, और पुराना column किसी बाद वाले release में ही गिराएं। हर migration को उससे पहले और उसके बाद चल रहे एप्लिकेशन वर्जन दोनों के साथ चलने लायक रखें।

मेरा नियम यह है कि कोई भी डिप्लॉय किया गया schema कोड के पिछले और अगले दोनों वर्जन के साथ चलना चाहिए, क्योंकि rolling deploy के दौरान दोनों एक साथ चल रहे होते हैं। तो मैं कभी column का नाम नहीं बदलता, मैं expand और contract करता हूं। मान लीजिए हम name फील्ड को बांट रहे हैं। पहली migration नए nullable columns जोड़ती है, जो सस्ता है और किसी मौजूदा row को नहीं छूता। फिर एक release जिसमें एप्लिकेशन पुराने और नए दोनों ढांचे में लिखता है लेकिन पढ़ता अब भी पुराना है, तो यूज़र को दिखने वाली कोई चीज़ अभी नए डेटा पर निर्भर नहीं। फिर backfill, कुछ हज़ार के batches में और बीच में ठहराव के साथ, ताकि न मैं लंबा transaction पकड़ूं और न replicas पर replication lag बढ़ाऊं। फिर एक release जो नए columns पढ़ता है, और पुराने अब भी लिखे जा रहे हैं ताकि निकलने का रास्ता खुला रहे। जब यह एक दो release तक स्थिर रह जाए, तभी मैं dual writing रोकता हूं और पुराने columns गिराता हूं। मैं migrations को deploy के रास्ते से भी बाहर रखता हूं, और जो चीज़ भारी lock लेती है, जैसे index बनाना, वह concurrently और कम ट्रैफिक वाले वक्त चलती है।