मुझे बताइए कि बिना downtime के डेटाबेस migration कैसे शिप करेंगे।

इसे पीछे की तरफ संगत कदमों में बांटें। पहले schema का बदलाव ऐसे रूप में डालें जिसे चल रहा कोड सह ले, जैसे nullable column जोड़ना, फिर ऐसा कोड डालें जो पुराने और नए दोनों में लिखे, बैचों में backfill करें, reads बदलें, और पुराना column किसी बाद वाली release में ही हटाएं। लंबे table locks से बचें और rollback का रास्ता हमेशा टेस्ट करें।

जिस नियम पर मैं टिका रहता हूं वह यह है कि rolling deploy के दौरान कोड के दो वर्जन एक ही डेटाबेस से बात कर रहे होते हैं, तो हर कदम दोनों के लिए सुरक्षित होना चाहिए। column का नाम बदलना क्लासिक जाल है। उसकी जगह मैं expand करता हूं: नया nullable column अपनी अलग migration में जोड़ता हूं, ऐसा कोड शिप करता हूं जो दोनों fields में लिखे और पढ़े अब भी पुराना, मौजूदा rows को कुछ हजार के बैचों में बीच में रुक रुककर backfill करता हूं ताकि replication पीछे न छूटे, फिर अगली release में reads पलटता हूं, और तीसरी release में ही पुराना column गिराता हूं। Postgres की बारीकियां भी मायने रखती हैं। बड़ी table पर NOT NULL constraint जोड़ना भारी लॉक लेता है, तो मैं column nullable जोड़ता हूं, backfill करता हूं, फिर constraint अलग से validate करता हूं। जरूरत पड़ने पर Django separate_database_and_state और non atomic migrations देता है, और मैं छोटा lock_timeout रखता हूं ताकि अटकी migration जल्दी फेल हो जाए, हर query को अपने पीछे कतार में न लगाए। हर migration को एक टेस्ट किया हुआ rollback भी मिलता है।