Erro ao estabelecer uma conexão de banco de dados várias vezes por semana

Question

Eu tenho um cliente que eu faço desenvolvimento web para quem tinha um site WordpRess baixo tráfego básico rodando no Ubuntu 12.0.4 com Digitalocean.

Pilha LAMP básica que eles fornecem pré-construída com o WordPress instalado.

Cerca de 3-4 vezes por semana, o banco de dados MySQL desce e mostra essa mensagem no site:

Erro ao estabelecer uma conexão com o banco de dados

Eu então tenho que usar o SSH na caixa e reiniciar o MySQL. Leva todos, mas 15 segundos no entanto pode ser baixo por horas, se eu não perceber isso. Não é justo para meu cliente, pois é aleatório e até 6 vezes por semana, às vezes!

Eu sou um desenvolvedor PHP e JavaScript, então minhas habilidades administrativas de servidor são limitadas.

Por favor alguém pode ajudar em como eu posso encontrar o problema, fonte de problema que eu deveria dizer e esperançosamente consertá-lo permanentemente?

UPDATE

Eu tenho um arquivo de log aqui /var/log/mysql.log que tem uma data / hora da última modificação na época em que o servidor MySQL falhou hoje. É um arquivo vazio.

Classificando arquivos nesse diretório /var/log/ por DateTime Eu posso ver que um dos arquivos modificados mais recentes é chamado syslog

Eu colei o conteúdo do syslog abaixo, já que na parte inferior ele menciona MySQL , então acho que pode ser relevante se alguém puder tentar me ajudar a entender por favor?

/ var / log / syslog

Jun 24 16:17:01 thomaslastname CRON[928]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jun 24 16:32:27 thomaslastname kernel: [2738822.445529] type=1400 audit(1435177947.529:25): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=1048 comm="apparmor_parser"
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1102]: Upgrading MySQL tables if necessary.
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1105]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1105]: Looking for 'mysql' as: /usr/bin/mysql
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1105]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1105]: This installation of MySQL is already upgraded to 5.5.38, use --force if you still need to run mysql_upgrade
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1116]: Checking for insecure root accounts.
Jun 24 16:32:29 thomaslastname /etc/mysql/debian-start[1122]: Triggering myisam-recover for all MyISAM tables
Jun 24 16:39:01 thomaslastname CRON[1208]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Jun 24 16:39:01 thomaslastname postfix/pickup[32544]: 5F48363D60: uid=0 from=<root>
Jun 24 16:39:01 thomaslastname postfix/cleanup[1221]: 5F48363D60: message-id=<20150624203901.5F48363D60@WP-NewBase-052814>
Jun 24 16:39:01 thomaslastname postfix/qmgr[1002]: 5F48363D60: from=<root@WP-NewBase-052814>, size=866, nrcpt=1 (queue active)
Jun 24 16:39:01 thomaslastname postfix/local[1223]: 5F48363D60: to=<root@WP-NewBase-052814>, orig_to=<root>, relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Jun 24 16:39:01 thomaslastname postfix/qmgr[1002]: 5F48363D60: removed

/var/log/mysql/error.log

150624 16:32:27 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
150624 16:32:27 [Note] Plugin 'FEDERATED' is disabled.
150624 16:32:27 InnoDB: The InnoDB memory heap is disabled
150624 16:32:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150624 16:32:27 InnoDB: Compressed tables use zlib 1.2.8
150624 16:32:27 InnoDB: Using Linux native AIO
150624 16:32:27 InnoDB: Initializing buffer pool, size = 128.0M
150624 16:32:27 InnoDB: Completed initialization of buffer pool
150624 16:32:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 18880361123
150624 16:32:27  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 18880542657
150624 16:32:27  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
150624 16:32:27  InnoDB: Waiting for the background threads to start
150624 16:32:28 InnoDB: 5.5.38 started; log sequence number 18880542657
150624 16:32:28 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
150624 16:32:28 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
150624 16:32:28 [Note] Server socket created on IP: '127.0.0.1'.
150624 16:32:28 [Note] Event Scheduler: Loaded 0 events
150624 16:32:28 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.38-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
150624 16:32:29 [ERROR] /usr/sbin/mysqld: Table './wordpress/wp_aiowps_login_activity' is marked as crashed and should be repaired
150624 16:32:29 [Warning] Checking table:   './wordpress/wp_aiowps_login_activity'

    

Answer 1

Infelizmente, não há informações suficientes aqui para diagnosticar totalmente os problemas de conexão. Seu log de erro do MySQL diz que o MySQL travou, mas nada sobre o porquê.

Você pode continuar investigando se quiser, mas há uma solução que você pode aplicar enquanto isso.

A cada cinco minutos, reinicie o MySQL automaticamente se não estiver aceitando conexões

Nota : isso eliminará o funcionamento do MySQL por cerca de seis minutos.

1. Abra um prompt do MySQL ou execute um comando no phpMyAdmin (escolha uma senha alfanumérica e sem espaços melhor que abcdefg ):

   CREATE USER 'hang-check'@'localhost' IDENTIFIED BY 'abcdefg';
   

2. Verifique se você pode fazer login no banco de dados como hang-check e se eles não podem ver nenhum dos bancos de dados do WordPress.

3. Abra um terminal no servidor e execute:

   sudo -i
   EDITOR=nano crontab -e
   

4. No arquivo crontab, insira a seguinte linha ( altere abcdefg para a senha que você escolheu anteriormente ), salve-a ( Ctrl + O then Enter ), e voltar para o terminal ( Ctrl + X ):

    */5 * * * * /usr/bin/mysql --host=127.0.0.1 --port=3306 --connect_timeout=30 --user=hang-check --password='abcdefg' -e '' || (/usr/bin/killall -9 mysqld_safe mysqld; /bin/sleep 15; /usr/sbin/service mysql start)
   

5. Execute isso no mesmo terminal:

    sudo -i
    service mysql stop
    killall -9 mysqld_safe mysqld
    sleep 360; ps -umysql
   

6. Aguarde seis minutos até terminar.

7. Verifique se o último comando responde com uma linha que termina com mysqld . Se isso não acontecer, execute service mysql start e comente aqui.
8. Feche o terminal.