|
Задавайте вопросы, мы ответим
Вы не зашли.
1. В момент выполнения оптимизации таблицы, достучаться к ней селектом не удаётся (MyISAM). Так и есть?
2. На сервере 4Гб памяти. Из наблюдений за базой видно, что она не кушает больше 512Мб. Если она скушала 512Мб, то запросы не выполняются, а база ругается на нехватку памяти. Дело в конфиге базы или где-то в ОС могут быть какие-то ограничения? (FreeBSD)
3. Не удаётся выполнить запрос SHOW GLOBAL STATUS. Запрос вешается со статусом "выполняется". Удалить процесс не удаётся. Рестарт сервера не помогает с выполнением запроса, по прежнему вешается 
4. При добавлении именованного индекса в кеш на 16-32Мб, другие запросы не выполняются, ругаясь на нехватку памяти, тогда как по ресурсам имеется достаточный запас памяти.
5. Какие именно переменные потребляют указанные в них объёмы памяти постоянно, а не по надобности?
6. Есть ли какие-либо советы по значениям переменных по выделению памяти в процентном соотношении от имеющейся памяти для больших нагрузок и большего быстродействия?
Вот такое накопилось 
Неактивен
7. Bin Log. Что за зверь и с чем его едят? Разросся до 30Гб, что не очень интересно. Можно просто удалить все файлы?
Неактивен
1. так и есть
2. MySQL должен есть, сколько ему разрешает ОС. На 32-битных машинах это 3-4 Гб, на 64-битных - без видимого ограничения. Возможно FreeBSD, посмотрите sysctl -a нет ли там ограничений
3. это, вероятно, баг. Если можно повторить, то разместите на bugs.mysql.com
4. Если ругаются, значит запрос действительно запрашивает память - это может быть, например, sort_buffer или join_buffer
5. Большинство выделяется при необходимости. Важно делить на те, которые в одном экземпляре и те, которые выделяются для каждого запроса (если ему требуется). В последней категории read_buffer, sort_buffer, join_buffer. Важно, что если запрос содержит подзапросы, то эти буфферы могут выделяться на подзапрос отдельно.
6. Универсальных советов нет, очень сильно зависит от запросов.
7. binary log - смотреть командой mysqlbinlog, запись всех апдейтов. Идея такая: Пусть у Вас есть backup от 4:00 текущего дня. В 12:00 кто-то случайно или намеренно выполнил DROP DATABASE. Как восстановить? Восстанавливаете BACKUP, а затем mysqlbinlog имя_бинлога --end-datetime="2008.03.24 11:59" | mysql
Фактически повторяете все апдейты. Еще он используется при репликации - реплицируются именно записи бинлога.
При BACKUP, у mysqldump есть ключ --flush-logs, который начинает писать бинлог заново с момента BACKUP. Кроме того, посмотрите FLUSH LOGS http://dev.mysql.com/doc/refman/5.1/en/flush.html
Если Вам не нужен, отключите просто в my.cnf, убрав строчку log-bin=..
Неактивен
3. Даже если и баг, раньше он точно не проявлялся А что разместить-то? Просто описать проблему, или показать список процессов и результат команды KILL (0 rows affected)?
7. А его можно настроить так, чтобы логи хранились за, скажем, прошедшие сутки? Чтобы не скапливались сильно устаревшие логи.
Неактивен
3. описать проблему, включая все действия, которые помогают понять ее лучше, в том числе KILL
7. mysql -e "FLUSH LOGS" по cron
Неактивен
3. Если сборка из портов, то багрепорт не примут. Порты в FreeBSD битые, очень рекомендую
сначала собрать сервер из исходников, предоставляемых MySQL AB.
7. Есть параметр сервера --expire_logs_days, который заставляет сервер проверять, стирать ли
файл бинарного лога в зависимости от его давности. Также, возможно, Вам стоит обратить
внимание на параметр --max_binlog_size, который устанавливает максимальный размер файла.
Замечу, что если у Вас нету полного бэкапа, то бинлог со стертым началом абсолютно бесполезен.
Т.е. если у Вас полный бэкап раз в неделю, то бинлог за последние сутки - бесполезен.
Неактивен
Спасибо за ответы.
max_binlog_size в конфиге установил в 1Мб, но разницы не заметил. Вообще на сервере создаются ротированные бекапы раз в сутки, по этому, думаю, бин лог можно отключить
Неактивен
3. Я подозреваю, что причина может быть в фаерволе, т.к. подобные глюки (а также не всегда успешный перезапуск сервера БД) стали наблюдаться после включения и настройки фаервола. Не подскажите, может серверу нужны ещё какие-нибудь разрешения кроме порта 3306? ОС - FreeBSD 6.3
Неактивен
Можете отключить InnoDB, станет перезапускаться
Проблема в том, что порты битые. Флаги компилятора подобраны плохо и (не говоря уж
о том, что не оптимально) код собирается битым. Самый правильный способ - не собираться
из портов.
Фаервол никак не влияет, разумеется. Единственное, что может помешать серверу
запуститься с точки зрения сети, - это уже занятый другим приложением порт.
Неактивен
На сборку из исходников мы уже решились, надеюсь, это не будет проделано зря Обидно то, что раньше проблемы не наблюдалось, а InnoDB были всегда включены 
Неактивен
А дока по флагам компилятора на родном языке де-нить имеется?
Неактивен
Может быть это: http://www.vikvik.ru/gnudocrus/index.html
Лучше всего смотреть man gcc, про его перевод не знаю. На самом деле исходники должны собраться сами более-менее правильно, я бы не советовал использовать расширенные оптимизационные возможности gcc (ключи -O и.т.д), так как этом может привести к снижению стабильности.
Неактивен
