Ошибка, устанавливающая соединение с базой данных несколько раз в неделю

У меня есть клиент, я делаю веб-разработку для того, у кого был основной низкий трафик сайт Wordpress, работающий на Ubuntu 12.0.4 с Digitalocean.

Основной стек LAMP, который они предоставляют пред созданный установленный WordPress.

Приблизительно 3-4 раза в неделю, MySQL DB понижается и показывает это сообщение на сайте:

Ошибка, устанавливающая соединение с базой данных

Я затем имею к SSH в MySQL перезагрузки и поле. Берет все кроме 15 секунд однако могут снизиться в течение многих часов, если я не замечаю его. Это; s не справедливый моему клиенту, поскольку это случайно и до 6 раз в неделю иногда!

Я - PHP и разработчик JavaScript, таким образом, мои администраторские навыки Server ограничены.

Кто-то может помочь в том, как я могу найти проблему, источник проблемы, я должен сказать и надо надеяться зафиксировать его постоянно?


ОБНОВЛЕНИЕ

У меня есть файл журнала здесь /var/log/mysql.log это имеет последнюю измененную дату/время во время сервер MySQL, разрушенный сегодня. Это - пустой файл все же.

Сортировка файлов в том каталоге /var/log/ DateTime I видят, что один из новых измененных файлов называют системным журналом

Я вставил содержание системного журнала ниже как около нижней части, он упоминает MySQL, таким образом, я чувствую, что может быть необходимо, если кто-то мог бы попытаться помочь мне понять его?


/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'
1
задан 25 June 2015 в 00:22

1 ответ

К сожалению, нет достаточной информации здесь, чтобы полностью диагностировать проблемы соединения. В Вашем журнале ошибок MySQL говорится что разрушенный MySQL, но ничто о почему.

можно продолжить заниматься расследованиями, если Вы хотели бы, но существует решение, которое можно применить тем временем.

Каждые пять минут, автоматически перезапустите MySQL, если он не принимает соединения

Примечание : это выведет MySQL из обслуживания в течение приблизительно шести минут.

  1. Открывают подсказку MySQL или работают, команда в phpMyAdmin (выберите лучший алфавитно-цифровой, пароль без пробелов, чем abcdefg):

    CREATE USER 'hang-check'@'localhost' IDENTIFIED BY 'abcdefg';
    
  2. Гарантируют, что можно войти в систему базы данных как hang-check и что они не видят ни одной из баз данных WordPress.

  3. Откройте терминал на сервере и работайте:

    sudo -i
    EDITOR=nano crontab -e
    
  4. В crontab файле, вставьте следующую строку ( изменение abcdefg к паролю, который Вы выбрали ранее ), сохраните его (, Ctrl + O тогда Входят ), и выйдите назад к терминалу ( 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. Выполнение это в том же терминале:

     sudo -i
     service mysql stop
     killall -9 mysqld_safe mysqld
     sleep 360; ps -umysql
    
  6. Ожидают шесть минут, пока это не заканчивается.

  7. Гарантируют, что последняя команда отвечает строкой, которая заканчивается mysqld. Если это не делает, работает service mysql start и комментирует здесь.
  8. Близко терминал.
3
ответ дан 7 December 2019 в 12:44

Другие вопросы по тегам:

Похожие вопросы: