Magento MySQL Uzaklaştı


14

Magento CE 1.7.0.2 ile ilgili birçok garip sorun yaşıyorum. Normal işlemler sırasında, site bazen hem ön uçta hem de arka uçta bir Magento Hata Sayfası ( İsteğiniz işlenirken bir hata oluştu ) oluşturur. İlişkili raporu görüntüleyerek aşağıdaki mesajı görüyorum:

"SQLSTATE[HY000] [2006] MySQL server has gone away"

Bazen, ancak daha nadiren, rapor mesajı şöyle olacaktır:

 Connection reset by peer

Ben var> log> system.log baktım ve MySQL has gone awayhata aşağıdaki eşlik ediyor:

Warning: PDO::__construct(): MySQL server has gone away  in /var/www/html/domain.com/live/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 129
Error while reading greeting packet. PID=1863  in /var/www/html/domain.com/live/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 129

Buna ek olarak, her istekte ve MySQL has gone awayhatalarda aşağıdaki hata gerçekleşiyor gibi görünüyor :

 Warning: include(File.php): failed to open stream: No such file or directory  in /var/www/html/domain.com/live/lib/Varien/Autoload.php on line 93
 Warning: include(): Failed opening 'File.php' for inclusion

Bu konuda bulabildiğim makalelerin çoğuna baktım ve inekler eve gelene kadar veritabanı parametreleriyle uğraştım ama hata devam ediyor.

Derleyici hakkında başka bir QnA'yı izledikten sonra , Sistem> Araçlar> Derleme yönetici sayfasının tamamen boş olduğunu fark ettim . Bunların tüm ilgili hatalar olduğunu düşünüyorum, ancak hata ayıklama veya nedenleri hakkında herhangi bir fikir çok yararlı olacaktır.

Bu tutarsızsa özür dilerim; Yaklaşık 42 saattir uyanıkım, bu yüzden lütfen açıklama isteyin. Teşekkür ederim.

-- Güncelleme --

Netlik için sunucu yığınım:

PHP 5.5.4 (PHP-FPM)
Nginx 1.4.2
MySQL 5.5.33

-- Güncelleme --

Bu bana (bazı uykudan sonra) asla belirtmedi - PHP kod tabanı ve MySQL db ayrı donanım sunucularında - ya bana yardım edeceğini bilmek çok önemlidir! Özür dilerim.


1
Kalıcı veritabanı bağlantıları kullanıyor musunuz? Öyleyse, bunları devre dışı bırakmayı deneyin. Ben de orada hatalar olup olmadığını veya aslında sadece bağlantı kesiliyor vs yeniden başlatılıyor olup olmadığını görmek için mysql günlükleri kontrol ediyorum.
davidalger

Thx David, MySQL günlüklerini kuyruk ve hata oluştuğunda DB vurmak asla. Kalıcı bağlantılar kullanıyordum, devre dışı bırakma yardımcı olmadı :(
Jongosi

1
Bağlantının kötü olduğunu düşündünüz mü? Bu hatanın nedeni, DB'nin msg'yi hiç almamasıdır. Mysqli işlevlerini çağırmak için local.xml bağlantı bilgilerini kullanarak hata ayıklamayı deneyin. Bakalım ne olacak.
SH-

teşekkür ederim, yerel dosyayı düzenleme sorunumu

Yanıtlar:


9

Bu çoğunlukla aşağıdaki iki nedenden kaynaklanmaktadır

  1. Sunucu zaman aşımına uğradı ve bağlantıyı kapattı.
    düzeltme: wait_timeoutmysqld'in my.cnf/my.ini yapılandırma dosyasındaki değişkeni artırmayı deneyin .
  2. Sunucu yanlış veya çok büyük bir paket bıraktı.
    düzeltmek: değerini artırarak maksimum paket boyutu sınırını arttırmak max_allowed_packetiçinde my.cnf/my.ini dosya.

Çok uzun veya uygulanamayan bir şey almaya çalışıyorsanız lütfen dosyaları kontrol edin.


Thx Anshu, MySQL sorgu günlüğünü takip ediyorum ve veritabanı asla bir istek ile vuruldu. Ayrıca, sunucuyu yeniden başlatırsam, bazen sunucu çevrimiçi olduğunda 20 saniye içinde bir hata oluşabilir - varsayılan ayarların bile zaman aşımına uğraması için çok kısa. max_allowed_packet2G'ye ve wait_timout86400'e ayarladım , hala yardım yok.
Jongosi

Lütfen veritabanı bağlantısının doğru olup olmadığını kontrol edin, uygulamanızı / etc / local.xml dosyanızı kontrol edin
Anshu Mishra

Teşekkürler Anshu, evet, doğru - bağlantı isteklerin yaklaşık% 68'i olur
Jongosi

6

Sorun çözüldü! Yardımlarınız için hepinize teşekkürler. Bu, bizim tarafımızdan devre dışı bırakıldıktan sonra bile web barındırıcısıyla ilgili bir donanım güvenlik duvarı sorunuydu.

1 & 1'in sunucu ekibi tarafından onaylandığı gibi , donanım güvenlik duvarları doğru bir şekilde yapılandırıldı, ancak dosya sunucusu ile db sunucusu arasındaki geçerli trafiği yanlış bir şekilde % 25 oranında engelliyorlardı.

Bunun yerine iptables'ı yapılandırdık ve donanım güvenlik duvarlarını tamamen kapattık. Şimdi% 100 kullanılabilirlik.


2
Aman! Sporadik güvenlik duvarı… bu tür bir konuyu sevmek lazım. Sıralamanıza sevindim. :)
davidalger

Burada da aynı sorun var ve çözümünüz bizim için de işe yarayacak gibi görünüyor. 1 ve 1 de konuşacağım. Destek size herhangi bir şekilde yardımcı oldu mu? Sizinle iletişime geçebilir miyim? Twitter? Facebook? Ayrıntılar için lütfen profilime bakın. Teşekkürler
webDEVILopers

2

Magento 2.1 için aynı sorunu yaşadım ve benim mysql hata günlüğüm, "MySQL gitti" işlemi sırasında aşağıdaki hatayı birden çok kez gösterdi:

...[Warning] File Descriptor 1228 exceeded FD_SETSIZE=1024

Bu sorunu potansiyel olarak çözmek için, öncelikle benim durumumda olan open filesdeğeri kontrol edin .$ ulimit -n256

İkinci olarak, table_open_cache = {that ulimit -n value}içindeki [mysqld]bölümün altına ekleyin my.cnf.

Şimdi MySQL'i yeniden başlatın ve umarım eyleme geri dönersiniz.

Not: Magento 2.1'i yerel olarak OS 7.1 El Capitan'da PHP 7.1 ve MySQL 5.7.15 ile Homebrew ile çalıştırıyorum. Ancak bu çözümün eski veya farklı kurulumlarda da işe yarayacağına eminim.


1

Magento klasörünüzdeki app / etc / local.xml dosyasını düzenleyerek ana bilgisayarın girişini 'localhost' yerine '127.0.0.1' olarak değiştirin.


Veritabanı ayrı bir donanım sunucusundadır, bu nedenle MySQL sunucusunun IP adresi kullanılır.
Jongosi

1

Büyük bir veritabanını 2 sunucu arasında taşırken aynı hatayla karşılaştım.

Yerel (hedef) sunucumda mysql yapılandırma dosyasına (/etc/mysql/my.cnf) geçici olarak aşağıdakileri eklemek ve mysql (service mysql restart) hizmetini yeniden başlatmak sorunu çözdü:

max_allowed_packet      = 160M
wait_timeout            = 28800000
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.