База данных MySQL (20 гигабайт таблиц и индекса) испортилась. Я запустил опцию восстановления с помощью графического интерфейса MySQL-admin, теперь он работает 24 часа. Когда я проверил параметры MyISAM (буферы, потоки и т. Д.), Я понял, что они имеют чрезвычайно низкую производительность: 1 поток восстановления, 8 МБ буфера сортировки ...
Мой вопрос в том, что лучше: остановить процесс восстановления и запустить снова с лучшей конфигурацией или оставить его включенным и подождать. Есть ли способ узнать, что происходит в процессе ремонта или сколько он займет?
Вы можете следить за ходом ремонта, просматривая содержимое каталога данных; вы увидите таблицы с именами, начинающимися с #, которые используются во время ремонта.
Вы также можете проверить SHOW PROCESSLIST, чтобы убедиться, что он не выполняет «Восстановление с помощью кэша ключей», потому что это намного хуже, чем «Восстановить путем сортировки»
Ремонт очень медленный с большими таблицами; вам, вероятно, следует избегать очень больших таблиц, особенно с большим количеством индексов, с MyISAM. Лучше разделить их, чтобы сократить время ремонта. Для этого может потребоваться серьезное изменение кода вашего приложения.
В основном произошло отключение электроэнергии, и база данных была повреждена.
Я не останавливаю процесс ремонта, но, похоже, надолго. Надеюсь, его правильно восстановят. В любом случае я следил за некоторыми указаниями на будущее:
1.- Добавьте в файл my.conf следующее
[mysqld]
myisam-recover=backup,force
При этом mysql будет принудительно выполнять восстановление каждый раз, когда движок myisam становится поврежденным.
2.- Увеличьте количество потоков для восстановления и размер буфера сортировки.
3.- Не используйте графический интерфейс mysql-admin, используйте командную строку. В основном потому, что в командной строке mysqlcheck есть подробный параметр.
И, конечно же, бэкап :-)
Я настоятельно рекомендую НЕ останавливать процесс.
Первый поток, который вы видите в списке процессов, - это способ работы MySQL, и вы можете нанести ущерб существующей базе данных, если остановите его посередине.
Может быть, вы можете предоставить дополнительную информацию о том, что случилось с вашей базой данных, чтобы быть поврежденным?
Хм ... для начала, вы можете убедиться, что восстановление активно выполняется, выполнив команду "show processlist;" из командной строки MySQL.
(Вероятно, это не тот ответ, который вы искали, но, надеюсь, это шаг на правильном пути.)
[Ах - избит MarkR.]
Мой ремонт длился вечно, потому что диск был заполнен временными файлами. Я не заметил. Мой файл servername.err в каталоге mysql содержал такие строки ....
101104 5:43:24 [ОШИБКА] / usr / sbin / mysqld: Диск полностью записывает '/ tmp / STiktcbP' (код ошибки: 28). Жду, пока кто-нибудь освободит место ... Повторите попытку через 60 секунд
проверьте свой временной лимит php.ini, очень вероятно, что ваш скрипт в любом случае перестал работать через 300 секунд! (вы также можете выполнить phpinfo () и проверить вывод)
вам следует делать ремонт такой большой БД только через интерфейс командной строки mysql.