|
Задавайте вопросы, мы ответим
Вы не зашли.
В общем в кратце, был перепад света, после включения сервера мускул умер. (До этого работал 7 месяцев всё было ок)
При попытке соединиться с сервером:
mysql
error 2002 (hy000) can't connect to local mysql server through socket '/tmp/mysql.sock' (2) freebsd
Переустановил сам скуль до версии 5.2.23
Стартуем мускуд:
/usr/local/etc/rc.d/mysql-server start
/usr/local/etc/rc.d/mysql-server status
mysql is not running.
Вот лог файла из /var/db/mysql/ИмяМашины.err
120508 11:58:07 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql
120508 11:58:07 InnoDB: The InnoDB memory heap is disabled
120508 11:58:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120508 11:58:07 InnoDB: Compressed tables use zlib 1.2.5
120508 11:58:07 InnoDB: Initializing buffer pool, size = 128.0M
120508 11:58:07 InnoDB: Completed initialization of buffer pool
120508 11:58:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 144555117877
120508 11:58:07 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Error: tried to read 1048576 bytes at offset 0 1048576.
InnoDB: Was only able to read -1.
120508 11:58:16 InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/ … codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
120508 11:58:16 mysqld_safe mysqld from pid file /var/db/mysql/etc.pid ended
Права на папки /var/db/mysql и /tmp дал, толку 0, выручайте 
Неактивен
Отвечу для тех кто пришел сюда из гугла. Как печально это и не было, но слетела вся база 
Восстанавливать файлы из каталога /var/db/mysql я не стал а тупо восстановил всё бекапом базы (у меня бекапилось все на ФТП сервер и на самом сервере делался тоже бекапчик ).
Неактивен
Хым, как-то я пропустил это сообщение. Выглядит как битый диск / ФС, судя по
IO error. Я бы еще рекомендовал проверить ФС на ошибки.
Неактивен
всем привет!
ситуация аналогичная наверное, после выключения света не стартует мускул
подскажите пжл с чего начать?
стоит боевой сервер, который все в одном, биллинг-нат-нетфлоу-роутер и т.д., предоставляется доступ абонентов в интернет
Отредактированно WideAreaNetwork (15.12.2018 10:22:18)
Неактивен
В InnoDB в каждом файле есть уникальный идентификатор. Ошибка говорит о том, что у вас есть два файла с одним идентификатором. Это плохо, так быть не должно.
Могу предложить несколько вариантов решения (все с разной степенью костыльности). В любом случае, перед тем, как делать то, что написано ниже, сделайте бэкап, чтобы можно было вернуться к изначальному состоянию.
Вариант «поочередное чтение».
1. Переименовываем mysql/innodb_index_stats.ibd в mysql/innodb_index_stats.ibd.bak
2. Стартуем MySQL (он должен ругнуться в лог, что не нашел файла, но стартануть)
3. Копируем nodeny/auth_log.ibd в текст (mysqldump nodeny auth_log > auth_log.sql)
4. Смотрим, создал ли MySQL табличку innodb_index_stats самостоятельно. Если да — ничего больше делать не нужно, если нет:
5. Убиваем табличку auth_log (DROP TABLE nodeny.auth_log)
6. Останавливаем MySQL
7. Восстанавливаем index_stats.ibd (так останется только одна таблица со space id2)
8. Восстанавливаем auth_log (у него получится новый space id, и должно быть всё хорошо: mysql nodeny < auth_log.sql)
Вариант «force recovery»
1. Добавляем в конфиг innodb_force_recovery = 1
2. Стартуем MySQL (это будет readonly-режим, но можно будет прочитать данные)
3. Бэкапим данные в файлик (mysqldump -A > dump.sql)
4. Убираем force recovery, пытаемся запустить (есть небольшой шанс, что MySQL сам восстановит id таблиц)
5. Если не запустился, убиваем содержимое каталога с данными
6. Инициализируем каталог с данными по новой (mysql_install_db)
7. Запускаем MySQL
8. Восстанавливаем данные из текста (mysql < dump.sql)
Неактивен
спс большое за ответ, но мог я долго пытаться , как оказалось через мускул извне ломанули сервак, и подменили шел, сейчас все восстановлено , но хочется просто все переустановить с нуля
ибо не знаю что могли еще там оставить после себя
Неактивен
подскажите пжл при ОС FreeBSD где именно можно посмотреть когда взломали MySQL?
Неактивен
Надо понимать, как взломали. Если MySQL смотрел наружу и читали через LOAD DATA INFILE / SELECT INTO OUTFILE, то, скорее всего, только по дате измененных файлов: по умолчанию MySQL не пишет лог всех запросов.
Ну и просто по логам авторизации смотрите — почти наверняка после этого они логинились по ssh.
Неактивен
