Postgres में अक्सर होने वाली DB schema बदलाव की गलतियाँ

Here is a summary of the common database schema change mistakes, translated and structured in Korean:

concurrency से जुड़ी गलतियाँ

• lock हासिल करने में विफलता
• एक ही बार में बहुत ज़्यादा rows अपडेट करना
• exclusive lock हासिल करने के बाद transaction को लंबे समय तक खुला रखना

चरणों की शुद्धता से जुड़ी गलतियाँ - logical issues

• अप्रत्याशित schema drift
• schema/app code mismatch
• अप्रत्याशित data

अन्य गलतियाँ

• statement_timeout तक पहुँचना
• बढ़ सकने वाली table में 4-byte integer primary key का उपयोग
• VACUUM के व्यवहार और bloat के जोखिम को नज़रअंदाज़ करना

Case 1. schema mismatch

• development/test environment में काम किया, लेकिन QA/Staging/Production में विफल हो गया
• कारण की पहचान करने के बाद workflow सुधारकर इसे हल करना चाहिए

Case 2. IF [NOT] EXISTS का गलत उपयोग

• schema mismatch errors को IF NOT EXISTS से अनदेखा करने की कोशिश न करें
• समस्या के मूल कारण की पहचान कर उसे ठीक करना चाहिए

Case 3. statement_timeout तक पहुँचना

• सभी बदलावों को बड़े data volume के साथ टेस्ट करके पहले से पता करना चाहिए

Case 4. बिना सीमा के बड़े पैमाने पर बदलाव

• एक transaction में बहुत ज़्यादा rows बदलने से दूसरे transactions प्रभावित होते हैं
• अगर Checkpointer tuning नहीं हुई है तो WAL data बहुत अधिक बन सकता है
• disk write saturation से overall performance में गिरावट आ सकती है
• VACUUM/Bloat issues हो सकते हैं
• batches में बाँटकर प्रोसेस करें और VACUUM को मैनेज करें

Case 5. exclusive lock हासिल करने के बाद transaction के भीतर प्रतीक्षा

• BEGIN/ALTER TABLE/COMMIT के बीच दूसरा काम करने पर lock लंबे समय तक बना रहता है
• exclusive lock हासिल करने के बाद transaction को यथासंभव जल्दी खत्म करना चाहिए

Case 6. DDL + बड़े पैमाने का DML शामिल transaction

• DDL चरण में लिया गया lock, DML चरण तक लंबे समय तक बना रहता है
• DDL और DML को अलग transactions/migration steps में बाँटना चाहिए

Case 7. exclusive lock हासिल करने की प्रतीक्षा से दूसरे sessions block होना

• जब autovacuum wraparound रोकथाम मोड में हो, तो DDL को yield नहीं करता
• lock हासिल करने की प्रतीक्षा के दौरान SELECT भी block हो जाता है
• lock_timeout को कम रखें और retry logic बनाएँ

Case 8. FK बनाते समय सावधानियाँ

• बड़ी table पर FK बनाते समय referenced table scan के कारण समय लगता है
• not valid option के साथ FK define करें, फिर अलग transaction में validate करें

Case 9. FK हटाते समय सावधानियाँ

• दोनों tables पर lock चाहिए, इसलिए lock_timeout retry logic आवश्यक है

Case 10. CHECK constraint जोड़ते समय सावधानियाँ

• पूरे table scan होता है, इसलिए FK जैसी 2-step approach का उपयोग करें

Case 11. NOT NULL जोड़ते समय सावधानियाँ

• Postgres 11 से पहले नए column में NOT NULL जोड़ने पर table scan होता है
• Postgres 11 से NOT NULL DEFAULT column जोड़कर इसे हल किया जा सकता है
• Postgres 12 से CHECK constraint जोड़कर NOT NULL सेट किया जा सकता है

Case 12. column data type बदलते समय सावधानियाँ

• पूरे table का rewrite हो सकता है
• नया column जोड़कर trigger से data copy करने वाली approach की ज़रूरत हो सकती है

Case 13. CREATE INDEX करते समय सावधानियाँ

• OLTP में CREATE INDEX CONCURRENTLY का उपयोग करना चाहिए
• unique index बनाना विफल हो जाए तो invalid index को साफ़ करना होगा

Case 14. DROP INDEX करते समय सावधानियाँ

• lock हासिल करने की समस्या हो सकती है, इसलिए DROP INDEX CONCURRENTLY का उपयोग करें

Case 15. object name बदलते समय सावधानियाँ

• app code और DB schema के बीच mismatch से बचने के लिए deployment order समायोजित करना चाहिए

Case 16. DEFAULT value वाले column को जोड़ना

• PG 11 से पहले पूरे table का rewrite होता था
• PG 11 से DEFAULT value वाले column को जोड़ना तेज़ हो गया

Case 17. CREATE INDEX CONCURRENTLY विफल होने पर बचे हुए अवशेषों की सफ़ाई

• विफल होने पर invalid index बच जाता है, इसलिए retry से पहले उसे साफ़ करना ज़रूरी है

Case 18. बड़ी table में 4-byte integer primary key का उपयोग

• int8 का उपयोग करना चाहिए। ज़्यादातर frameworks पहले से ही int8 का उपयोग कर रहे हैं।

सिफारिशें

• वास्तविक data size के साथ टेस्ट करें
• exclusive lock के बने रहने का समय जाँचें
• deployment automation में सुधार करें
• दूसरों से सीखें और ज्ञान साझा करें

GN⁺ की राय

यह लेख वास्तविक DB schema बदलावों के दौरान होने वाली कई गलतियों और सावधानियों को अच्छी तरह व्यवस्थित करता है। खासकर exclusive lock से जुड़े मुद्दों का बार-बार उल्लेख किया गया है, और बड़े databases में ये और भी गंभीर समस्या बन सकते हैं.

यह FK, NOT NULL, indexes जैसी चीज़ों को संभालते समय ध्यान देने वाली बातों को भी ठोस तरीके से समझाता है, जिन्हें developers अक्सर नज़रअंदाज़ कर देते हैं। Postgres के version-specific improvements को समझना और उनका उपयोग करना भी मददगार हो सकता है.

सबसे अहम बात यह है कि वास्तविक data size के साथ अच्छी तरह टेस्ट करना और deployment automation को बेहतर बनाना, schema changes के जोखिम को कम करने की कुंजी है। testing और deployment automation के लिए Database Lab Engine जैसे tools का उपयोग करना भी अच्छा हो सकता है.

ऐसे उपयोगी tips साझा करने वाले technical blog posts और अधिक होने चाहिए। ऐसी जानकारी जितनी व्यापक रूप से फैलेगी, databases के साथ काम करने वाले developers की क्षमता बढ़ाने में उतनी ही मदद मिलेगी.