Magento डेटाबेस आईपी कैश किया गया है

Question

हमारे पास हमारे विकास और उत्पादन वातावरण के लिए अलग-अलग डेटाबेस आईपी पते हैं। हमारा विकास पर्यावरण हमारी डेवलपर मशीनों पर स्थानीय रूप से चल रहा है और हमारे स्थानीय नेटवर्क पर एक एकल विकास डेटाबेस सर्वर की ओर इशारा करता है। हमारा उत्पादन वातावरण रैकस्पेस में होस्ट किए गए डेटाबेस का उपयोग करता है और इसे अपने स्थानीय नेटवर्क पर होस्ट किया जाता है। किसी भी तरह, ऐसा लगता है कि हमारे विकास आईपी पते को उत्पादन पर कैश किया गया है। यहां मैंने जो किया है, वह है:

• सत्यापित किया गया कि उत्पादन पर ऐप/etc/local.xml में आईपी पता सही है।
• वहाँ किसी भी अजीब कैश स्पष्ट करने की var/कैश/* और var/full_page_cache/*
• पुनः आरंभ हमारे memcached सर्वर सामग्री नष्ट कर दिया गया
• देव आईपी पते
• mysql डेटाबेस फ़ेंका गया के लिए हमारे पूरे codebase grepped और देव आईपी के लिए डंप grepped (हम हताश थे)
• हटाए गए/tmp की सामग्री
• अक्षम कस्टम मॉड्यूल

यह है बिना किसी समस्या के हफ्तों तक काम कर रहा है। यह तब हुआ जब मैंने कॉन्फ़िगर कैश को अक्षम कर दिया था। मुझे पता है कि आप क्या सोच रहे हैं, कि अभी आखिर में एक कॉन्फ़िगरेशन बदलाव आया है जिसे पिछली बार कैश साफ़ कर दिया गया था। यह समझ आता है। इसका अर्थ यह नहीं है कि मैंने ऊपर वर्णित हर कैश को साफ़ कर दिया है, enabled the config cache using MageTool और सबकुछ एक आकर्षण की तरह काम करता है।

Answer 1

जैसा कि यह पता चला है, इस पूरी चीज को ठीक करना एक दो कदम प्रक्रिया थी।

क्योंकि हमारे उत्पादन और विकास के वातावरण अलग आईपी आवश्यकता app/etc/local.xml ट्रैक न किए गए है और इसके बजाय हम app/etc/local-example.xml तो ट्रैक हमारे डेवलपर्स के सभी जल्दी और आसानी से यह app/etc/local.xml को कॉपी कर सकते हैं पर और और चल रहा हो। यह एक कंपनी मानक का थोड़ा सा बन गया है और हम इसे अपनी सभी अन्य परियोजनाओं में उपयोग करते हैं। शुक्र है, मेरे सहकर्मियों में से एक ने पाया कि Magento loads all the xml files in app/etc/.

तो, नहीं, हमारे विकास आईपी को कुछ पागल अस्पष्ट स्थान में जादुई रूप से कैश नहीं किया गया था, हम केवल अनजाने में इसे लोड कर रहे थे। app/etc/local.xml.example पर उस फ़ाइल का नाम बदलने के बाद, यह हमारे विकास आईपी का संदर्भ देना बंद कर दिया। वाह!

अब, यह सीधे सवाल से संबंधित नहीं है, लेकिन क्योंकि समाधान ने एक नई बग पेश की है, मैं इसका उल्लेख करना चाहता हूं। एक बार जब हमने xml फ़ाइल का नाम बदल दिया और सभी कैश साफ़ कर दिए, तो हमने एक नई त्रुटि देखना शुरू कर दिया।

PHP Fatal error: Call to a member function setQueryHook() on a non-object in app/code/core/Mage/Core/Model/Resource/Setup.php on line 347

हमारे उदाहरण फ़ाइल में हम एक भी <default_setup /> नोड के अंदर हमारे डाटाबेस संसाधन को परिभाषित कर रहे थे। हमारे उत्पादन माहौल के लिए हमारे पास वास्तव में a triple-m setup है जो अलग-अलग आईपी पढ़ने और लिखने के लिए लिखने के लिए है, इसलिए एक <default_setup /> नोड के बजाय उत्पादन के लिए हमारे पास <default_read /> और <default_write /> नोड्स थे। मैं संसाधनों में बिल्कुल अनुमति और आवश्यकतानुसार दस्तावेज नहीं ढूंढ पाया है, लेकिन पढ़ने/लिखने का विभाजन the instructions in another StackOverflow post on the topic प्रति सेटअप था और आज तक, बहुत अच्छा काम किया।

एक झुकाव पर, मैंने <default_write /> नोड को <default_setup /> का नाम बदल दिया और सबकुछ जादुई रूप से फिर से काम करना शुरू कर दिया। मुझे अभी तक यकीन नहीं है कि क्या पढ़ना और लिखना सही ढंग से विभाजित हो रहा है, लेकिन एक बार जब मैं सबकुछ काम कर रहा हूं तो मैं यह जवाब अपडेट कर दूंगा।