Повторяющаяся проблема с ключами на временных таблицах
Мы проводим большой форум с большим количеством операций чтения и записи, особенно для posts
а также topics
таблицы, которые оба innodb.
На прошлой неделе я начал делать 12-часовое резервное копирование с помощью innobackupex, потому что mysqldump просто берет навсегда (7+ миллионов строк в posts
Таблица.) Кажется, что- то не нравится эти резервные копии, потому что у меня повторяющиеся проблемы через день.
Симптомы;
На первой странице сайта начинает появляться ошибки
Журналы начинают показывать ошибки, такие как Error: 126 - Incorrect key file for table '/tmp/mysql/#sql_4e87_14.MYI'; try to repair it
/ Tmp / dir заполняется, и мы начинаем получать Error: 1030 - Got error 28 from storage engine
в логах.
Единственный способ исправить это optimize table
на каждом из столов сообщений и тем.
Я пытаюсь сделать все возможное, чтобы остановить MySQL, используя диски для временных таблиц, но у меня было бы больше проблем, чем это, если бы он использовал всю мою память.
Мой my.cnf здесь; https://gist.github.com/cbiggins/0aa26f6defb7a14541d7
Коробка имеет 32 ГБ памяти, и я обычно не подхожу к этому. В настоящее время на 15GB использовать.
Заранее спасибо.
Обновление 1: несмотря на то, что conf выглядит так, как будто есть репликация, ее нет. Это отдельный экземпляр.
Обновление 2: Теперь, когда резервные копии не выполнялись более 24 часов, проблема возникла снова. Так что это не результат резервного копирования.
Обновление 3: я дал MySQL 20 ГБ временного пространства, используя tmpfs. Инструкции здесь. Собираюсь посмотреть еще немного и посмотреть как пойдет.
Обновление 4: я нашел убийственный запрос! 13 секунд и 2,3 миллиона строк. Сделайте это 20 раз одновременно, и я довольно быстро заполнил свой новый 20 ГБ временный каталог. Я отключил блок, который использовал этот запрос, и предоставил отзыв.
Я решил получить супер дешевый выделенный сервер для репликации, с которого можно запускать резервные копии. Надеюсь, мы снова увидим, как я работаю.:)
1 ответ
Проблема в том, что /tmp/ fill и MySQL помещают туда несколько файлов.
Один из вариантов, которые MySQL может сделать при работе с подзапросом:
Ссылка: MySQL 5.6 - Оптимизация подзапроса
Материализуйте подзапрос во временную таблицу с индексом и используйте временную таблицу для выполнения соединения. Индекс используется для удаления дубликатов. Индекс может также использоваться позже для поиска при соединении временной таблицы с внешними таблицами; если нет, таблица сканируется.
Вы можете отключить это (subquery_materialization_cost_based), и он будет использовать другую стратегию.
Ссылка: MySQL 5.6 - Управление переключаемыми оптимизациями
Другой вариант - предотвратить заполнение / tmp /, добавив больше места или заставив MySQL поместить его временные файлы в другое место.