Mysql öldüğünde otomatik olarak yeniden başlat

Kişisel projelerimi yürütmek için kiraladığım bir raf alanı sunucum var. Ucuz olduğum için 256Mb RAM var ve dürüstçe çok fazla işleyemiyor. Her seferinde, trafikte keskin bir artış olduğunda, sunucu öldürme işlemlerine başlamaya karar verir ve mysqld'in öldürmesi için popüler bir şey olduğu görülmektedir. Sitemi ziyaret etmeye çalışıyorum ve veritabanı bağlantısı kurulurken bir hata oluştuğu mesajı ile karşılaşıyorum. Günlüklerin incelenmesi, mysqld'in bellek yetersizliği nedeniyle öldürüldüğünü ortaya koymaktadır.

Dün olduğum kadar fakir olduğum ve rackspace VM'nin RAM'ini yükseltmek istemediğimden, öldüğünde mysqld'i otomatik olarak yeniden başlatmasını söyleyebileceğim bir yol var mı?

Crontab gibi bir şey kullanmayı düşündüm, ama ne yazık ki, orada ne yapacağımı da tam olarak bilmiyorum. Sanırım masaüstümde ve dizüstü bilgisayarımda (Linux'u sadece özel olarak çalıştıran) çoğu şeyi yapabildiğim için "masaüstünüzde Linux" nesnesinin ürünüyüm, ancak yine de Linux için çok fazla sunucu yönetimi becerisinden yoksundur.

Sunucu CentOS 6.3'ü çalıştırıyor

Bu temiz bir çözüm değil, ilk etapta problemden kaçınmak daha iyi olurdu. Her neyse, CentOS'un hizmetleri nasıl yönettiğinden emin değilim ama kullandığını düşünüyorum service. Öyleyse, mysqlhizmetin çalışıp çalışmadığını kontrol edebilirsiniz

/sbin/service mysql status

Bu komut mysqlçalışıyorsa başarıyla çıkacak ve i değilse 0 dışında bir çıkış durumu döndürecektir. Bu nedenle, bu komutla çalışmıyorsa hizmeti başlatabilirsiniz:

/sbin/service mysql status || service mysql start

Bu /etc/crontabkomutu her dakika bu komutu başlatmak için ekleyebilirsiniz :

* * * * * /sbin/service mysql status || service mysql start

Bu biraz rahatsız edici.

mysqld her zaman mysqld_safe tarafından yeniden başlatılırçünkümysqld_safeanormal kapanmaları kontrol etmek içinaltında sonsuz bir döngü vardır. Hata çok ağırsa,sonraki denemelerdemysqld_safeyenidenmysqldbaşlayamaz bile.

mysqld_safeTasarlanan durum göz önüne alındığında, yine de reddederse mysqld, başlamak için zorlamak iyi bir fikir olmayabilir mysqld_safe.

Altında olacak my.cnf hata günlüğünü bulmak gerekir

[mysqld]
log-error=log-filename

veya

[mysqld_safe]
log-error=log-filename

Metin dosyasını okuyun (muhtemelen çalışarak tail -30 log-filename) ve kapanarak mysqld işlemenin kaynağını bulun.

Düşük bellekli bir VPS'de işleri devam ettirmeye çalışan kaba bir güç girişiminde, MySQL'i kontrol etmek ve yeniden başlatmak için terdom cevabının bir modifikasyonunu kullandım .

/sbin/service mysqld status || service mysqld restart

Ben değiştirmek için gereken mysqlüzere mysqldişe almak için. O olmadan hatayı alırdım " ERROR! MySQL is running but PID file could not be found".

CentOS 7.2 sistemimde, /sbin/serviceyeniden yönlendiriliyor /bin/systemctl status, bu nedenle aşağıdaki komutun yürütülmesi daha hızlı.

/bin/systemctl status  mysqld.service || /bin/systemctl start  mysqld.service

Sistemin kök crontab'ına aşağıdaki satırı ekledim. MySQL'in çalışıp çalışmadığını her dakika kontrol eder ve stdout'u null değerine yönlendirir. Bir şey ters gitmedikçe hizmetin başlatılması hiçbir şey vermez, bu nedenle son komutta boş yönlendirme eklemenize gerek yoktur.

* * * * * /bin/systemctl status mysqld.service > /dev/null || /bin/systemctl start  mysqld.service

İlk komut bir şekilde başarısız olursa, çift ​​boru ||anlamına gelir ORve 2. komutu yürütür. (Sıfırdan büyük bir çıkış kodu döndürür.)

Bu, "1. komutu çalıştırın veya 1. komut bir şekilde başarısız olursa, 2. komutu çalıştırın" demek gibidir.

Bu &&, "1. komutu çalıştırın ve yalnızca 1. komut başarılı olursa 2. komutu çalıştırın " gibi çift ​​ampirden farklıdır .

Aşağıdaki jonnyreeves.co.uk adresinden :

Ve suçlu php-fpm! Hızlı bir google, benzer semptomlardan muzdarip başka bir Wordpress müşterisi buldu; php-fpm havuz yapılandırmasını (/etc/php-fpm.d/www.conf) değiştirmek ve pm yapılandırmasını değiştirmekti. Ana değişiklik taşımak olduğu pm = dynamiciçin pm = ondemand, bir ile pm.max_childrendeğerine 5(işçi başına ±% 5 bellek kullanımı gözlemlemeye dayanır). Yapılandırmayı değiştirdikten sonra tüm hizmetleri yeniden başlattım ve bellek kullanımını kontrol ettim.

service php-fpm restart
service nginx restart
service mariadb restart

Yeniden başlatıldıktan sonra bellek kullanımı önemli ölçüde düşüktü.