Мой сервер MySQL, на котором установлена последняя версия MySql на Ubuntu 16.x, дает сбой один или два раза в день. Иногда ремонтируется довольно быстро (за 10 минут). Иногда мне приходится перезагружаться и делать fsck, чтобы все снова заработало.
Что могло бы вызвать это?
То, что я пробовал до сих пор:
Вот типичный журнал ошибок 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: Использование встроенного в Linux AIO 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 каталог или другие временные структуры, или как пространство подкачки, освобождая место на другом, предположительно исправном, диске для важных данных.