Riavvia automaticamente mysql quando muore

Ho un server Rackspace che ho noleggiato per eseguire i miei progetti personali. Dato che sono economico, ha 256 MB di RAM e onestamente non è in grado di gestirli molto. Ogni tanto, quando c'è un forte aumento del traffico, il server decide di iniziare i processi di uccisione e sembra che mysqld sia popolare per uccidere. Provo a visitare il mio sito e sono accolto con il messaggio che si è verificato un errore durante la connessione al database. L'ispezione dei registri rivela che mysqld è stato ucciso a causa della mancanza di memoria.

Dato che sono ancora povero come ieri e non voglio aggiornare la RAM della mia VM con spazio di archiviazione, c'è un modo in cui posso dirlo per riavviare automagicamente mysqld quando muore?

Ho pensato di usare qualcosa come crontab, ma purtroppo non so nemmeno cosa fare lì. Immagino di essere il prodotto della generazione "Linux sul tuo desktop" poiché posso fare la maggior parte delle cose sul mio desktop e laptop (che esegue Linux quasi esclusivamente), ma mancano ancora molte capacità di amministrazione del server per Linux.

Il server esegue CentOS 6.3

Questa non è una soluzione pulita, sarebbe ovviamente meglio evitare il problema in primo luogo. Ad ogni modo, non sono sicuro di come CentOS gestisce i servizi, ma penso che li usi service. In tal caso, è possibile verificare se il mysqlservizio è in esecuzione

/sbin/service mysql status

Questo comando verrà chiuso correttamente se mysqlè in esecuzione e restituirà uno stato di uscita diverso da 0 se non lo è. È quindi possibile avviare il servizio se non è in esecuzione con questo comando:

/sbin/service mysql status || service mysql start

Puoi aggiungere questa riga a /etc/crontabper lanciare questo comando ogni minuto:

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

Questo è un po 'inquietante.

mysqld viene sempre riavviato da mysqld_safe perché nella parte inferiore è presente un ciclo infinitomysqld_safeper verificare la presenza di arresti anomali. Se l'errore è troppo grave, neppuremysqld_safenon sarebbe in grado di riavviarsimysqldnei tentativi successivi.

Data quella situazione per cui mysqld_safeè stata progettata, potrebbe non essere una buona idea forzare mysqldl'avvio se mysqld_safela rifiuterà comunque.

È necessario individuare il log degli errori in my.cnf che si troverà sotto

[mysqld]
log-error=log-filename

o

[mysqld_safe]
log-error=log-filename

Leggi il file di testo (probabilmente eseguendolo tail -30 log-filename) e trova la fonte dell'elaborazione mysqld che si sta spegnendo.

In un bruto tentativo di mantenere le cose attive e funzionanti su un VPS a memoria insufficiente, ho usato una modifica della risposta di terdom per controllare e riavviare MySQL.

/sbin/service mysqld status || service mysqld restart

Avevo bisogno di cambiare mysqlper mysqldper farlo funzionare. Senza di essa otterrei l'errore " ERROR! MySQL is running but PID file could not be found".

Sul mio sistema CentOS 7.2, /sbin/servicereindirizza a /bin/systemctl status, quindi l'esecuzione del comando seguente è più veloce.

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

Ho finito per aggiungere la seguente riga al crontab di root del sistema. Controlla ogni minuto se MySQL è in esecuzione e reindirizza lo stdout su null. L'avvio del servizio non produrrà nulla a meno che qualcosa non vada storto, quindi non è necessario aggiungere il reindirizzamento null sull'ultimo comando.

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

La doppia pipe ||significa ORed eseguirà il secondo comando se il primo comando fallisce in qualche modo. (Restituisce un codice di uscita maggiore di zero.)

È come dire "Esegui il primo comando o , se il primo comando fallisce in qualche modo, esegui il secondo comando".

Questo è diverso dalla doppia e commerciale &&che è come dire "Esegui il primo comando e , solo se il primo comando ha avuto successo, esegui il secondo comando".

Quanto segue proviene da jonnyreeves.co.uk :

E il colpevole è php-fpm! Un rapido google ha trovato un altro cliente Wordpress affetto da sintomi simili; il consiglio era di modificare la configurazione del pool php-fpm (/etc/php-fpm.d/www.conf) e di modificare la configurazione pm. Il cambiamento principale è stato il passaggio da pm = dynamica pm = ondemandcon un pm.max_childrenvalore di 5(basato sull'osservazione dell'utilizzo di memoria ~ 5% per lavoratore). Dopo aver modificato la configurazione, ho riavviato tutti i servizi e verificato l'utilizzo della memoria.

service php-fpm restart
service nginx restart
service mariadb restart

Dopo aver riavviato l'utilizzo della memoria era notevolmente inferiore.