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