двоичный журнал mysql заполняет диск
Внезапно я закрыл свой веб-сайт (drupal 6.19) и не смог запустить mysql (слишком много таблиц разбилось).
проверив df-h, я обнаружил, что раздел MySQL заполнен из-за очень больших двоичных файлов журналов (я храню двоичные журналы только в течение одного дня, expire_logs_days= 1); проверив mysqlbinlog для одного из журналов bin, я обнаружил, что большинство записей предназначены для таблиц кэша (cache_form, boost_cache, boost_cache_relationships, cache_content и т. Д.) И для таблица сеансов; некоторые данные повторяются много раз.
кстати, у меня есть часы ls-lh, и файлы bin-журнала увеличивались экспоненциально (каждые одну или две минуты я получал новый файл binlog размером 100 м!!)
У вас есть какие-либо идеи о том, что вызывает это? Как я могу решить эту проблему?
2 answers
Я полагаю, что одним из очевидных улучшений было бы использование другого бэкенда кэша.
Если у вас есть один сервер и достаточно памяти, вы можете использовать серверную часть APC (D6: http://drupal.org/project/cacherouter , D7: http://drupal.org/project/apc ) иметь различные часто используемые кэши непосредственно в общей памяти. Это, вероятно, самое быстрое решение для кэширования, которое вы можете получить.
Другой альтернативой является Memcached, что особенно интересно, если у вас есть несколько серверов, которые должны совместно использовать кэш.
Обратите внимание, что вы не можете переместить форму cache_form, потому что она содержит информацию о текущих отображаемых формах и на самом деле не является кэшем, поскольку содержит уникальную информацию, а не просто агрегированные данные, как другие, которые всегда можно очистить. Кроме того, некоторые другие кэши, особенно cache_update, вы, возможно, захотите сохранить в базе данных, потому что их не следует очищать, как остальные, поскольку они содержат информацию об обновленной информации вашего используемые модули, что-то, что не меняется , что часто и может быть очень медленным для повторного извлечения, если у вас их много.
Вы также можете переместить информацию о сеансах из базы данных, например, вы можете поместить ее в MongoDB, и, вероятно, есть и другие.
Проверяли ли вы дату регистрации ваших ящиков? значение expire_logs_days не является "автоматической магией". Это вступает в силу только при перезапуске mysql или при выполнении команды flush_logs или когда max_binlog_size максимальный_размер достигается.
Затем mysql должен повернуть текущий файл журнала (создав новый) и удалить файлы старше 1 дня (в вашем случае)
Попробуйте настроить этот последний параметр в своем my.cnf и посмотрите, работает ли он в сочетании с истекает_лог_дней.