Database Magento L'IP è memorizzato nella cache

Question

Abbiamo diversi indirizzi IP di database per i nostri ambienti di sviluppo e produzione. Il nostro ambiente di sviluppo è in esecuzione localmente sulle macchine degli sviluppatori e indica un singolo server database di sviluppo sulla nostra rete locale. Il nostro ambiente di produzione utilizza un database ospitato su RackSpace ed è ospitato sulla rete locale. In qualche modo, sembra che il nostro indirizzo IP di sviluppo sia stato memorizzato nella cache durante la produzione. Ecco cosa ho fatto finora:

• Verificato che l'indirizzo IP in app/etc/local.xml in produzione sia corretto.
• eliminato il contenuto della var/cache/* e/full_page_cache/*
• rimesso in moto i nostri server memcached var per cancellare le cache strani ci
• grepped tutta la nostra base di codice per l'indirizzo dev IP
• Dumped database mysql e grepped la discarica per l'IP dev (eravamo disperati)
• eliminato il contenuto di/tmp
• moduli personalizzati per disabili

Questo ha ha lavorato per settimane senza problemi. È stato quando ho disattivato la cache di configurazione che il problema è iniziato. So cosa stai pensando, che finalmente ha finalmente ottenuto un cambiamento di configurazione che qualcuno ha fatto dall'ultima volta che la cache è stata cancellata. Ciò ha senso. Quello che non ha senso è che ho cancellato tutte le cache sopra menzionate, enabled the config cache using MageTool e tutto funziona come un incantesimo.

Answer 1

Come risulta, la correzione di questa intera faccenda è stata una procedura in due fasi.

Perché i nostri ambienti di produzione e di sviluppo richiedono IP diversi app/etc/local.xml è non tracciata e invece abbiamo traccia app/etc/local-example.xml in modo che tutti i nostri sviluppatori rapidamente e facilmente possibile copiarlo verso app/etc/local.xml ed essere attivo e funzionante. Questo è diventato un po 'uno standard aziendale e lo usiamo in tutti i nostri altri progetti. Per fortuna, uno dei miei colleghi ha scoperto che Magento loads all the xml files in app/etc/.

Quindi, no, il nostro IP di sviluppo non è stato memorizzato nella cache in qualche luogo oscuro pazzo, lo stavamo caricando inavvertitamente. Dopo aver rinominato il file su app/etc/local.xml.example, ha interrotto il riferimento al nostro IP di sviluppo. Sìì!

Ora, questo non è direttamente correlato alla domanda, ma poiché la soluzione ha introdotto un nuovo bug, voglio menzionarlo. Una volta rinominato il file xml e cancellato tutte le cache abbiamo iniziato a vedere un nuovo errore.

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

Nel nostro file di esempio si stavano definendo la nostra risorsa di database all'interno di un unico <default_setup /> nodo. Per il nostro ambiente di produzione abbiamo in realtà a triple-m setup con IP separati per le query di lettura e scrittura, quindi per la produzione anziché un singolo nodo <default_setup /> avevamo i nodi <default_read /> e <default_write />. Non sono mai stato in grado di trovare la documentazione su esattamente ciò che è permesso e richiesto nelle risorse, ma la divisione di lettura/scrittura è stata configurata per the instructions in another StackOverflow post on the topic e, fino ad oggi, ha funzionato alla grande.

Su un sospetto, ho rinominato il nodo <default_write /> in <default_setup /> e tutto ha cominciato a funzionare magicamente. Non sono ancora sicuro che le letture e le scritture siano correttamente suddivise, ma aggiornerò questa risposta dopo aver confermato che tutto funziona.