Menu
We have different database IP addresses for our development and production environments. Our development environment is running locally on our developer machines and pointed to a single development database server on our local network. Our production environment uses a database hosted at RackSpace and is hosted on their local network. Somehow, it appears that our development IP address has been cached on production. Here's what I have done so far:
This has been working for weeks without a problem. It was when I disabled the config cache that problem started. I know what you're thinking, that it just now finally picked up a config change that someone made since the last time the cache was cleared. That makes sense. What doesn't make sense is that I've cleared every cache mentioned above, enabled the config cache using MageTool and everything works like a charm.
961
Magento 2 cache is in the var/cache directory off the store root with the settings located under System -> Cache Management. Configuration – generally, the system collects configuration info from all module/config.
Magento collects configuration from all modules, merges it, and saves the merged result to the cache. This cache also contains store-specific settings stored in the file system and database. Clean or flush this cache type after modifying configuration files.
What is Full Page Cache in Magento 2? Magento 2 full page cache is the free built-in Magento 2 caching solution that allows you to reduce the server load time and improves the response time due to the fast loading of CMS, product, and catalog pages.
Cache tags are a way to assign labels to different cache records so you can later clear multiple cache entries based on those labels (tags). For example, let's say you want to cache a category view page. This will have as tags category_{id of category here} . But the category page contains products.
As it turns out, fixing this whole thing was a two step process.
Because our production and development environments require different IPs app/etc/local.xml is untracked and instead we track app/etc/local-example.xml so that all of our developers can quickly and easily copy it over to app/etc/local.xml and be up and running. This has become a bit of a company standard and we use it across all of our other projects. Thankfully, one of my coworkers discovered that Magento loads all the xml files in app/etc/.
So, no, our development IP wasn't magically cached in some crazy obscure location, we were just inadvertently loading it. After renaming that file to app/etc/local.xml.example it stopped referencing our development IP. Yay!
Now, this isn't directly related to the question, but because the solution introduced a new bug I want to mention it. Once we renamed the xml file and cleared all of the caches we started seeing a new error.
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
In our example file we were defining our database resource inside a single <default_setup /> node. For our production environment we actually have a triple-m setup with separate IPs for read and write queries so for production instead of a single <default_setup /> node we had <default_read /> and <default_write /> nodes. I have never been able to find documentation on exactly what is allowed and required in resources, but the read / write split was setup per the instructions in another StackOverflow post on the topic and, up until today, worked great.
On a hunch, I renamed the <default_write /> node to <default_setup /> and everything magically began working again. I'm not yet sure if the reads and write are correctly splitting, but I'll update this answer once I confirm everything is working.
187
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
