Повторяющаяся проблема с ключами на временных таблицах

Мы проводим большой форум с большим количеством операций чтения и записи, особенно для 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 поместить его временные файлы в другое место.

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