एक नए सर्वर पर डेटाबेस स्थानांतरण और धीमी क्वेरी ट्यूनिंग

हम एक ऑनलाइन कैटलॉग चलाते हैं जो छह वर्षों से बढ़ रहा है, और यह अंततः उस मशीन से बाहर हो गया है जिस पर यह रहता है। श्रेणी पृष्ठों को खुलने में लगभग पांच सेकंड लगते हैं, कैटलॉग खोज और भी खराब है, और पीक घंटों में पूरा साइट अटकी हुई लगती है। डेटाबेस अभी भी पुराने सर्वर पर है, जबकि नया पहले से ही भुगतान किया गया है और तैयार है। मैं किसी ऐसे व्यक्ति की तलाश कर रहा हूँ जो डेटा को न्यूनतम डाउनटाइम के साथ स्थानांतरित करेगा - एक लिखित योजना के द्वारा, एक रिहर्सल के साथ और एक सहमत स्विच-ओवर विंडो के साथ, न कि शुक्रवार की शाम को प्लग खींचकर और उम्मीद करने के लिए।

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

पहले और बाद के माप कार्य का हिस्सा हैं, बोनस नहीं: मैं संख्याएँ चाहता हूँ, छापें नहीं।

शर्तें जिन पर मैं झुकूंगा नहीं:
— माइग्रेशन एक कॉपी पर रिहर्स किया गया है, और उत्पादन डेटाबेस को तब तक नहीं छुआ जाता जब तक कि उस कॉपी की पुष्टि नहीं हो जाती;
— प्रत्येक स्कीमा परिवर्तन से पहले एक बैकअप होता है जिसका पुनर्स्थापन परीक्षण किया गया है, केवल बनाया नहीं गया है;
— व्यस्त घंटों के दौरान कुछ भी लाइव नहीं बदला जाता है - सभी जोखिम भरे कदम सहमत शांत विंडो के भीतर होते हैं;
— प्रत्येक इंडेक्स और प्रत्येक फिर से लिखी गई क्वेरी के साथ अपने स्वयं के समय होते हैं पहले और बाद में;
— समापन रिपोर्ट बताती है कि क्या बदला गया, क्यों बदला गया, और इसे कैसे वापस रोल करना है।