MySql: Ежедневные сбои в течение последних 3 недель на мощном сервере
На моем сервере MySQL работает последняя версия MySql на Ubuntu 16. x продолжает давать сбой один или два раза в день. Иногда ремонтируется довольно быстро (за 10 минут). Иногда мне приходится перезагружаться и делать fsck, чтобы все снова заработало.
Что могло бы вызвать это?
То, что я пробовал до сих пор:
- увеличил ОЗУ с 1,5 ГБ до 5 ГБ.
- Аппаратные обновления: материнская плата, процессор, оперативная память (DDR4), но это не помогло (он работал на процессоре 7-летней давности, а теперь на 7-м. Gen Core I5).
- Настройте брандмауэр UFW, чтобы убедиться, что он не был вызван ботами, атакующими MySQL или другие службы.
- В my.cnf изменено значение innodb_buffer_pool_size со 128 МБ на 500 МБ. не помогло, но все еще на месте
- Я несколько раз запускал: mysqlcheck -u root -p --auto-repair --optimize --all-databases. не помогло
- В my.cnf уменьшил max_connections mysql с 151 до 80 и перезапустил mysql. не помогло
- Apache MaxRequestWorkers уменьшено со 150 до 100. Не помогло. По-прежнему вылетает.
- У меня уже был файл подкачки размером 1 ГБ. Оставил его.
- Просмотрел журналы Apache2, SysLog, любой другой журнал, который казался подходящим, но не нашел ничего, что привлекло мое внимание.
- Выключил сервер и попытался переместить ВМ на другой диск, но он не работает с ошибкой файла.
- Мое последнее подозрение в том, что это вызвано плохим блоком, но запуск плохих блоков, похоже, вызывал сбой при завершении 25%. Во время fsck я вижу следующее: критическая ошибка среды fsck, dev sda, сектор 147306432
Вот типичный журнал ошибок mysql:
2017-04-20T18: 43: 46.958430Z 0 [Примечание] InnoDB: page_cleaner: 1000 мс предполагаемый цикл занял 11791 мс. Настройки могут быть неоптимальными. (выброс гриппа = 92 и выселение = 0, за это время.)
2017-04-20T18: 44: 11.989905Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 6822 мс. Настройки могут быть неоптимальными. (за это время сброшено = 8 и выселено = 0.)
2017-04-20T18: 44: 49.145162Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 5021 мс. Настройки могут быть неоптимальными. (flus hed = 0 и выселенный = 0 в течение времени.)
2017-04-20T18: 45: 22.322429Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 26338 мс. Настройки могут быть неоптимальными. (выброс гриппа = 10 и выселение = 0 за время.)
2017-04-20T18: 45: 53.926808Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 4510 мс. Настройки могут быть неоптимальными. (flus hed = 0 и выселенный = 0 в течение времени.)
2017-04-20T18: 46: 03.097400Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 5384 мс. Настройки могут быть неоптимальными. (flus hed = 13 и выселено = 0 за это время.)
2017-04-20T18: 46: 39.247467Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 14848 мс. Настройки могут быть неоптимальными. (выброс гриппа = 8 и выселение = 0 в течение времени.)
2017-04-20T18: 47: 16.271672Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 29107 мс. Настройки могут быть неоптимальными. (выброс гриппа = 8 и выселение = 0 за это время.)
2017-04-20T18: 47: 53.669557Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 5969 мс. Настройки могут быть неоптимальными. (flus hed = 37 и выселено = 0 за это время.)
2017-04-20T18: 50: 23.879411Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 37671 мс. Настройки могут быть неоптимальными. (выброс гриппа = 6 и выселение = 0 в течение времени.)
2017-04-20T18: 55: 07.190725Z 0 [Предупреждение] Измененные лимиты: max_open_files: 1024 (запрошено 5000) 2017-04-20T18: 55: 07.235759Z 0 [Предупреждение] Измененные лимиты: table_open_cache: 431 (запрошено 2000)
2017-04-20T18: 55: 10.486670Z 0 [Предупреждение] TIMESTAMP с неявным значением DEFAULT устарел. Пожалуйста, используйте параметр --explicit_defaults_for_times tamp сервера (подробности см. В документации).
2017-04-20T18: 55: 11.563578Z 0 [Примечание] / usr / sbin / mysqld (mysqld 5.7.17-0ubuntu0.16.04.2), начиная с процесса 24701 ...
2017-04-20T18: 55: 21.979225Z 0 [Примечание] InnoDB: доступна поддержка PUNCH HOLE
2017-04-20T18: 55: 21.979250Z 0 [Примечание] InnoDB: мьютексы и rw_locks используют атомарные встроенные функции GCC
2017-04-20T18: 55: 21.979253Z 0 [Примечание] InnoDB: использует мьютексы событий 2017-04-20T18: 55: 21.979256Z 0 [Примечание] InnoDB: встроенная функция GCC __atomic_thread_fence () используется для барьера памяти
2017-04-20T18: 55: 21.979259Z 0 [Примечание] InnoDB: сжатые таблицы используют zlib 1.2.8
2017-04-20T18: 55: 21.979262Z 0 [Примечание] InnoDB: Использование встроенного AIO Linux 2017-04-20T18: 55: 22.004800Z 0 [Примечание] InnoDB: Количество пулов: 1
2017-04-20T18: 55: 22.060762Z 0 [Примечание] InnoDB: Использование инструкций crc32 процессора
2017-04-20T18: 55: 22.104584Z 0 [Примечание] InnoDB: инициализация буферного пула, общий размер = 128 МБ, экземпляры = 1, размер блока = 128 МБ
2017-04-20T18: 55: 24.184701Z 0 [Примечание] InnoDB: завершена инициализация пула буферов
2017-04-20T18: 55: 24.210160Z 0 [Примечание] InnoDB: если пользователь, выполняющий mysqld, авторизован, приоритет потока очистки страниц можно изменить. См. Справочную страницу setpriority ().
2017-04-20T18: 55: 26.405242Z 0 [Примечание] InnoDB: Самый высокий поддерживаемый формат файла - Barracuda.
2017-04-20T18: 55: 27.508456Z 0 [Примечание] InnoDB: сканирование журнала прошло мимо контрольной точки lsn 35288448161
2017-04-20T18: 55: 27.508478Z 0 [Примечание] InnoDB: Выполнение восстановления: сканировано до порядкового номера журнала 35288448170
2017-04-20T18: 55: 27.508630Z 0 [Примечание] InnoDB: Выполнение восстановления: сканировано до порядкового номера журнала 35288448170
2017-04-20T18: 55: 27.508634Z 0 [Примечание] InnoDB: База данных не завершалась нормально!
2017-04-20T18: 55: 27.508637Z 0 [Примечание] InnoDB: запуск восстановления после сбоя.
2017-04-20T18: 56: 16.516761Z 0 [Примечание] InnoDB: удален файл данных временного табличного пространства: «ibtmp1»
2017-04-20T18: 56: 16.516785Z 0 [Примечание] InnoDB: создание общего табличного пространства для временных таблиц
2017-04-20T18: 56: 16.516817Z 0 [Примечание] InnoDB: установка размера файла './ibtmp1' на 12 МБ. Физическая запись файла в полный; Подождите ...
2017-04-20T18: 56: 16.621736Z 0 [Примечание] InnoDB: размер файла './ibtmp1' теперь составляет 12 МБ.
2017-04-20T18: 56: 16.622203Z 0 [Примечание] InnoDB: обнаружено 96 сегментов отката повторного выполнения. 96 активных сегментов отката повторного выполнения.
2017-04-20T18: 56: 16.622211Z 0 [Примечание] InnoDB: активны 32 сегмента отката без повторения.
2017-04-20T18: 56: 16.622565Z 0 [Примечание] InnoDB: ожидание начала очистки
2017-04-20T18: 56: 16.672708Z 0 [Примечание] InnoDB: 5.7.17 запущен; порядковый номер журнала 35288448170
2017-04-20T18: 56: 16.672708Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 52462 мс. Настройки могут быть неоптимальными. (за это время очищено = 0 и выселено = 0.)
2017-04-20T18: 56: 16.673192Z 0 [Примечание] InnoDB: загрузка пулов буферов из / var / lib / mysql / ib_buffer_pool
2017-04-20T18: 56: 16.702959Z 0 [Примечание] Плагин «FEDERATED» отключен.
2017-04-20T18: 56: 16.851553Z 0 [ОШИБКА] Функция «архив» уже существует
2017-04-20T18: 56: 16.851568Z 0 [Предупреждение] Не удалось загрузить плагин с именем 'archive' с soname 'ha_archive.so'.
2017-04-20T18: 56: 16.851574Z 0 [ОШИБКА] Функция «черная дыра» уже существует
2017-04-20T18: 56: 16.851575Z 0 [Предупреждение] Не удалось загрузить плагин с именем 'blackhole' с soname 'ha_blackhole.so'.
2017-04-20T18: 56: 16.851578Z 0 [ОШИБКА] Функция 'federated' уже завершается 2017-04-20T18: 56: 16.851579Z 0 [Предупреждение] Не удалось загрузить подключаемый модуль с именем 'federated' с soname 'ha_federated.so' .
2017-04-20T18: 56: 16.851582Z 0 [ОШИБКА] Функция 'innodb' уже существует 2017-04-20T18: 56: 16.851583Z 0 [Предупреждение] Не удалось загрузить плагин с именем 'innodb' с soname 'ha_innodb.so' .
2017-04-20T18: 56: 17.044733Z 0 [Предупреждение] Не удалось настроить SSL из-за следующей ошибки библиотеки SSL: контекст SSL нельзя использовать без сертификата и закрытого ключа
2017-04-20T18: 56: 17.044754Z 0 [Примечание] Имя хоста сервера (адрес привязки): '0.0.0.0'; порт: 3306
2017-04-20T18: 56: 17.044761Z 0 [Примечание] - «0.0.0.0» заменяется на «0.0.0.0»;
2017-04-20T18: 56: 17.044779Z 0 [Примечание] Серверный сокет создан на IP: '0.0.0.0'. 2017-04-20T18: 56: 18.483575Z 0 [Примечание] Планировщик событий: загружено 0 событий
2017-04-20T18: 56: 18.483706Z 0 [Примечание] Выполнение 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' чтобы получить список таблиц с использованием устаревшего механизма разделов. Вы можете использовать параметр запуска --disable-partition-engine-check, чтобы пропустить эту проверку.
2017-04-20T18: 56: 18.483716Z 0 [Примечание] Начало списка таблиц, не секционированных в собственном коде
2017-04-20T18: 56: 25.478293Z 0 [Примечание] InnoDB: загрузка пулов буферов завершена в 170420 13:56:25
2017-04-20T18: 56: 26.091240Z 0 [Примечание] Конец списка нативно секционированных таблиц
2017-04-20T18: 56: 26.091423Z 0 [Примечание] / usr / sbin / mysqld: готов к подключению. Версия: '5.7.17-0ubuntu0.16.04.2' сокет: '/var/run/mysqld/mysqld.sock' порт: 3306 (Ubuntu)
2017-04-20T18: 56: 26.155810Z 4 [ОШИБКА] / usr / sbin / mysqld: Таблица './example/wp_options' помечена как поврежденная, и ее необходимо исправить
2017-04-20T18: 56: 26.155889Z 5 [ОШИБКА] / usr / sbin / mysqld: Таблица './example/wp_options' помечена как поврежденная и должна быть исправлена
2017-04-20T18: 56: 26.156037Z 4 [Предупреждение] Проверка таблицы: './ example / wp_options'
2017-04-20T18: 56: 35.816730Z 4 [ОШИБКА] / usr / sbin / mysqld: Таблица './example/wp_usermeta' помечена как поврежденная и требует исправления
2017-04-20T18: 56: 35.816875Z 4 [Предупреждение] Проверка таблицы: './example/wp_usermeta'
Последние два пункта указывают на проблему. Подозрение на наличие плохих блоков кажется вполне обоснованным.
- Ошибка файла при попытке переместить виртуальную машину
- Плохие блоки каждый раз вылетали примерно в одном и том же месте.
Пока сервер работает, выгрузите базы данных в файл на хосте. ОПЕРАЦИОННЫЕ СИСТЕМЫ. Поскольку сервер выходит из строя, и вы точно не знаете, к какой таблице, базе данных или записи он обращается, когда он все-таки выходит из строя, найдите время, чтобы выгрузить каждую базу данных, возможно, даже каждую таблицу, отдельно. Надеюсь, плохие блоки встречаются не в ваших данных, а в каком-то файле, который система пытается использовать. В любом случае, если один из дампов вызывает сбой, дважды, если вы хотите дважды проверить его, тогда рассматривайте эту таблицу или базу данных как подозрительные и просмотрите их вручную, насколько сможете.
Затем создайте новый ВМ на другом физическом диске со всеми необходимыми установками. Импортируйте сброшенные данные, включая проверенную версию любых подозрительных данных. Для всех таблиц сделайте несколько случайных проверок работоспособности данных, особенно для таблиц, построенных из любых подозрительных дампов. Затем выполните любой уровень тестирования, который вы сочтете подходящим, чтобы убедиться, что новая виртуальная машина и база данных работают должным образом и содержат достоверные данные.
Сделайте новую виртуальную машину «живым» сервером, удалите старую виртуальную машину и начните резервное копирование / восстановление для остальная часть физического диска, на котором находилась виртуальная машина отказавшего сервера. После того, как вы извлекли все или все доступные данные с этого диска, вы можете определить его работоспособность (подозрительно) и готовы ли вы доверять ему для дальнейшего использования для важных данных. Может быть, его можно использовать как место для размещения каталога / tmp или других временных структур, или как пространство подкачки, освобождая место на другом, предположительно исправном, диске для важных данных.