Magento instance pointing to wrong database

Anyone ever have this problem? local.xml has been modified. core_config_data table has been modified for unsecure and secure url as well as cookie domain. Cache dirs have been wiped clean, session values have been cleared, log tables have been开发者_开发知识库 truncated.

it is under version control with subversion. have also run find to locate where it could possibly be getting the production DB IP.

find ~/path/to/application -type f -print0 | xargs -0 grep -l "IP Of incorrect DB"

yet still throwing an error on DB

SQLSTATE[HY000] [2003] Can't connect to MySQL server on 'IP of incorrect DB' (4)

Extremely baffled and can not for the life of me locate where it would possibly be getting the production DB's IP

local.xml points to development address.

---

You might want to check that the magento/var/ directory, as well as all subdirectories, are writable by the web server. If those directories are not writable Magento uses /tmp/ which can cause strange effects and even conflict with other Magento sites.

---

Make sure you're editing the config file you think you're editing. Take a look at the following code

#File: app/code/core/Mage/Core/Model/Config.php

public function loadBase()
{
    $etcDir = $this->getOptions()->getEtcDir();
    $files = glob($etcDir.DS.'*.xml');
    $this->loadFile(current($files));
    while ($file = next($files)) {
        $merge = clone $this->_prototype;
        $merge->loadFile($file);
        $this->extend($merge);
    }
    if (in_array($etcDir.DS.'local.xml', $files)) {
        $this->_isLocalConfigLoaded = true;
    }
    return $this;
}

This is the code that merges in your local.xml file to the configuration tree. Add some debugging code

public function loadBase()
{
    var_dump('Called ' . __METHOD__);   //ensure we're being called    
    $etcDir = $this->getOptions()->getEtcDir();
    $files = glob($etcDir.DS.'*.xml');
    $this->loadFile(current($files));
    while ($file = next($files)) {
        var_dump($file);                    //dump the file path being loaded to the browser
        $merge = clone $this->_prototype;
        $merge->loadFile($file);
        $this->extend($merge);
    }
    if (in_array($etcDir.DS.'local.xml', $files)) {
        $this->_isLocalConfigLoaded = true;
    }
    exit;                                   //bail out early
    return $this;
}

Load your site in a browser, and observe the paths being output via var_dump. Make sure that the file(s) being loaded are the ones you think are being loaded. Keep in mind that it looks like every XML file from the etc folder is loaded and merged in.

If the paths are what you expect, next add some debugging code to output the contents of the XML file(s) being loaded.

public function loadBase()
{
    var_dump('Called ' . __METHOD__ . '');  //ensure we're being called    
    $etcDir = $this->getOptions()->getEtcDir();
    $files = glob($etcDir.DS.'*.xml');
    $this->loadFile(current($files));
    while ($file = next($files)) {
        header('Content-Type: text/plain'); //so the browser renders it as plain text
        echo file_get_contents($file);      //dump the contents of the file being loaded to the browser
        $merge = clone $this->_prototype;
        $merge->loadFile($file);
        $this->extend($merge);
    }
    if (in_array($etcDir.DS.'local.xml', $files)) {
        $this->_isLocalConfigLoaded = true;
    }
    exit;                                   //bail out early
    return $this;
}

If the database information is correct in these files, then your system has been customized and/or hacked in some way that there's code calling out to another database server.

If that's the case you'll need to install something like xDebug to get some decent error reporting. This will let you find the exact code that's throwing the error, at which point you can trace it back to where it's getting it's connection information.

Good luck.

---

Just came across this when I had a similar issue. Followed Alan Storm's suggestion of dumping the config file names and found the problem. I had done a fresh install before copying the db and config files in from another instance, and had renamed the existing local.xml to localorig.xml. This was being loaded after local.xml and setting the db configuration fields back to the wrong values.

Moral: if you're backing up any of the config files in the same folder, change the extension.

Thanks Alan.

---

Try installing Alan Storm's Configviewer and check the generated XML to confirm the connection details point to the local.xml specifications. It's possible that one of the modules is using a non-default resource or some other oddity.

Can you post some of the stack trace in your question (obfuscated if you need) to show which module is calling that erroneous DB?

---

I had a similar problem just now. I double checked the local.xml file and that was definitely correct, however. Magento was still using an old user to access the database.

The problem was instantly resolved with: rm -rf var/cache/* - immediately this was done, the site came up.

It appears that Magento is caching the contents of local.xml in the cache area. Not so helpful.

Obviously, also recommend double checking the local.xml file but in this case it was 100% correct.

---

Just to try to help. Can you check your apache configuration? Something like "apache2 -S" to see which virtualhosts are used (and note especially the first default one). You could test that all your virtualhosts (if you work with virtualhosts) are using the right documentRoot. Don't you have an other copy of the sources on your dev server?

I mean are you sure you get the right magento instance running on the url you're using on your browser? In the same way are you sure of the cache directories used on your installation - do you see any change in theses directories since the wipe out?