Назад | Перейти на главную страницу

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

У нас большой форум, на котором много читают и пишут, особенно 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 ГБ памяти, я к этому обычно не подхожу. В настоящее время используется 15 ГБ.

Заранее спасибо.

Обновление 1: Несмотря на то, что конфиг, похоже, есть репликация, ее нет. Это отдельный экземпляр.

Обновление 2: Поскольку резервное копирование не выполнялось более 24 часов, проблема возникла снова. Так что это не результат резервного копирования.

Обновление 3: Я выделил MySQL 20 ГБ временного пространства, используя tmpfs. Инструкции здесь. Собираюсь понаблюдать в ближайшее время и посмотреть, как пойдет.

Обновление 4: Я нашел убийственный запрос! Проверено 13 секунд и 2,3 миллиона строк. Сделайте это 20 раз одновременно, и я довольно быстро заполнил свой новый временный каталог на 20 ГБ. Я отключил блок, который использовал этот запрос, и предоставил некоторую обратную связь обслуживающему персоналу.

Я решил купить супер дешевый выделенный сервер для репликации и резервного копирования. Надеюсь, мы снова увидим мой рост безотказной работы. :)

Проблема в том, что / tmp / заполняется и MySQL помещает туда какие-то файлы.

Один из вариантов, который MySQL может сделать при работе с подзапросом:

Ссылка: MySQL 5.6 - Оптимизация подзапроса

Материализуйте подзапрос во временную таблицу с индексом и используйте временную таблицу для выполнения соединения. Индекс используется для удаления дубликатов. Индекс может также использоваться позже для поиска при соединении временной таблицы с внешними таблицами; если нет, таблица сканируется.

Вы можете отключить это (subquery_materialization_cost_based), и он будет использовать другую стратегию.

Ссылка: MySQL 5.6 - Управление переключаемой оптимизацией

Другой вариант - предотвратить заполнение / tmp / путем добавления дополнительного места или размещения временных файлов MySQL в другом месте.