डाउनटाइम के बिना लाइव डेटाबेस में स्कीमा परिवर्तन और डेटा माइग्रेशन के लिए सर्वोत्तम अभ्यास?

Question

आप डाउनटाइम के बिना लाइव डेटाबेस में स्कीमा परिवर्तन कैसे करते हैं?

उदाहरण के लिए, मैं कहता हूं कि मेरे पास एक PostgreSQL डेटाबेस है जिसमें एक टेबल है जिसमें विभिन्न उपयोगकर्ता डेटा जैसे ईमेल पते आदि, सभी विशिष्ट उपयोगकर्ताओं के साथ जुड़े हैं। अगर मैं ईमेल पतों को एक नई समर्पित तालिका में स्थानांतरित करना चाहता था, तो मुझे स्कीमा को बदलना होगा और फिर ईमेल डेटा को नई तालिका में स्थानांतरित करना होगा। मूल तालिका में लिखे बिना इसे कैसे रोका जा सकता है? निश्चित रूप से जबकि डेटा को पुरानी तालिका से नए पर लिखा जाता है, नए डेटा को पुरानी तालिका में लिखना जारी रहेगा और याद किया जाएगा, है ना?

मुझे लगता है कि यह समस्या बहुत बार सामने आती है लेकिन मैं इससे निपटने के लिए कोई मानक समाधान नहीं खोज सकता।

यह लेख समस्या से संबंधित है, लेकिन मुझे वास्तव में चरण 3 समझ में नहीं आया। वह दोनों तालिकाओं को लिखने के लिए कहता है, फिर पहले तालिका से नए में पुराने डेटा को माइग्रेट करता है। आप यह कैसे सुनिश्चित करते हैं कि आप केवल पुराने डेटा को माइग्रेट कर रहे हैं?

(मैं Heroku पर PostgreSQL का उपयोग करता हूं ।)

Comments

फेसबुक ने MySQL के लिए ऐसा करने के लिए एक टूल विकसित किया ।

— निक चामास

के स्कॉट एलन ने स्कीमा संस्करणों के प्रबंधन के लिए एक प्रणाली के बारे में यहां लिखा है । मैंने DbUpdater बनाया, जो संस्करण-जागरूक स्कीमा तैनाती के लिए एक खुला स्रोत उपकरण है। यहाँ और अधिक - http://www.tewari.info/dbupdater

— ash

@NickChammas साझा करने के लिए धन्यवाद। मेरे पास इस पर बहुत सारे सवाल हैं। क्या आप कृपया अधिक विस्तृत ट्यूटोरियल, अधिमानतः एक वीडियो सुझा सकते हैं, जो बिट लॉग, नॉन क्लस्टर्ड इंडेक्स जैसी चीजों की व्याख्या करता है और जैसे सवालों के जवाब देता है - 1. डेस्टिनेशन की नकल करने की तुलना में सोर्स टेबल से डेटा को कैसे कम करें? सीधे टेबल। 2. कॉपी फेज कब खत्म होगा? ये केवल कुछ ही प्रश्न हैं और मैंने केवल इसे पढ़ना शुरू किया है।

— संदीपन नाथ

@SandeepanNath - क्षमा करें, मैं फेसबुक के टूल से परिचित नहीं हूं और इसलिए आपको अधिक संसाधनों की ओर संकेत नहीं कर सकता। मैंने इसके बारे में एक घोषणा पढ़ी और वर्षों पहले अपनी टिप्पणी पोस्ट की, लेकिन मैंने कभी इसका उपयोग नहीं किया।

— निक चामास

Answer 1

आपके पास लगभग अपना जवाब पहले से है:

1. समानांतर में नई संरचना बनाएँ
2. दोनों संरचनाओं को लिखना शुरू करें
3. पुराने डेटा को नए स्ट्रक्चर में माइग्रेट करें
4. केवल नई संरचना लिखें और पढ़ें
5. पुराने कॉलम हटाएं

के रूप में चरण 3 , कुछ इस तरह (एक लेन-देन) का उपयोग करें:

वह डालें जो अभी तक नहीं है:

INSERT INTO new_tbl (old_id, data)
SELECT old_id, data
FROM   old_tbl
WHERE  NOT EXISTS (SELECT * FROM new_tbl WHERE new_tbl.old_id = old_tbl.old_id);

इस बीच जो बदल गया है उसे अपडेट करें:

UPDATE new_tbl
SET    data  = old.data
USING  old_tbl
WHERE  new_tbl.old_id = old_tbl.old_id
AND    new_tbl.data IS DISTINCT FROM old_tbl.data;

नए डेटा को नहीं छुआ जाएगा, क्योंकि यह दोनों जगहों पर समान है।

Comments

मेरे पास उस परिदृश्य को समझने की कोशिश करते हुए कुछ प्रश्न हैं जिनके लिए आपने इस उत्तर का प्रस्ताव दिया था - 1. क्या डीबी परिवर्तनों की शुरुआत के साथ ही कोड परिवर्तन तैनात किए जाएंगे? 2. दोनों संरचनाओं को लिखने की आवश्यकता क्यों होगी? 3. नए ढांचे को पहले क्यों नहीं लाया जा सकता है और फिर मौजूदा डेटा को माइग्रेट किया जाए और फिर कोड परिवर्तन को तैनात किया जाए जो नई संरचना को आबाद करेगा? 4. यह पता लगाने की आवश्यकता क्यों है कि क्या नहीं है (आपकी पहली क्वेरी)? क्या आप कई प्रयासों में प्रविष्टि का प्रस्ताव कर रहे हैं?

— संदीपन नाथ

@SandeepanNath, आपकी टिप्पणी में प्रश्न 3 का उत्तर देने के लिए: क्योंकि यदि आप (a) नई संरचना लाते हैं, (b) इसमें डेटा स्थानांतरित करते हैं, (c) पुराने के बजाय नई संरचना में डेटा लिखने के लिए अपना कोड परिवर्तित करें, तो सभी चरण b और चरण c के बीच किए गए डेटा परिवर्तन केवल पुरानी संरचना में मौजूद होंगे । सवाल यह था कि बिना डाउनटाइम स्कीमा परिवर्तन कैसे किया जाए । इस उत्तर को फिर से, ध्यान से पढ़ें।

— वाइल्डकार्ड