NETOS Опубликовано: 9 октября, 2015 Опубликовано: 9 октября, 2015 Судя по логу я напорол бока с правами для пользователей No DB connection, DBI:mysql:database=nodeny;host=localhost;port=3306;mysql_connect_timeout=5 : Access denied for user 'nodeny'@ 'localhost' (using password: YES) Та тут просто говорит что не может подключится к базе nodeny. Причин масса...В какой папке была база? /var ? вы ее чистили? может и базу почистили? посмотрите что в var/db/
Enferno Опубликовано: 9 октября, 2015 Опубликовано: 9 октября, 2015 1. Надо /usr/local/etc/rc.d/mysql-server REstart , а не старт. 2. Если ругается на вланы, то в /etc/rc.conf за комментировать или удалить не нужные вланы 3. Проверить наличие mysql.sock в /tmp/
NETOS Опубликовано: 9 октября, 2015 Опубликовано: 9 октября, 2015 1. Надо /usr/local/etc/rc.d/mysql-server REstart , а не старт. 2. Если ругается на вланы, то в /etc/rc.conf за комментировать или удалить не нужные вланы 3. Проверить наличие mysql.sock в /tmp/ Так он запущен, зачем его вообще трогать? Изначально не проверили факт работы. Ну валаны мне кажется тут не мешают. А за что отвечает mysql.sock ?
rliskov Опубликовано: 9 октября, 2015 Автор Опубликовано: 9 октября, 2015 Огромное спасибо товарищу NETOS! Реально помог - РЕСПЕКТ!
alex_d Опубликовано: 9 октября, 2015 Опубликовано: 9 октября, 2015 Огромное спасибо товарищу NETOS! Реально помог - РЕСПЕКТ! все подняли?
Den_LocalNet Опубликовано: 9 октября, 2015 Опубликовано: 9 октября, 2015 Так в чем хоть бок был?Бок был в ТС, думаю это всем понятно с первого поста) А вообще нехрен лазить с таким багажом знаний.
Kitikonti Опубликовано: 10 октября, 2015 Опубликовано: 10 октября, 2015 Так в чем хоть бок был?Бок был в ТС, думаю это всем понятно с первого поста)А вообще нехрен лазить с таким багажом знаний. Ну чего ты так сразу... он думал темпы как в винде почистит, место на диске ЦЭ появится и комп летать будет :-)
NETOS Опубликовано: 14 октября, 2015 Опубликовано: 14 октября, 2015 Та в чем бок, базу немного подчистил ТС. Благо важные таблицы остались. Бэкап!!! Не забываем за бэкап!
cobalt Опубликовано: 15 октября, 2015 Опубликовано: 15 октября, 2015 Я щитаю, чудо свершилось: при "чистке" /var чудом остался жить /var/db/mysql/, конечно, может быть путь для БД был отличен от значения по умолчанию, получается, что человек, который поднимал НД+ что-то знал про админа
WideAreaNetwork Опубликовано: 15 декабря, 2018 Опубликовано: 15 декабря, 2018 не получается стартануть мускул, уже устал от чтива, фря с нодени+, после моргания света не стартует mysql # /usr/local/etc/rc.d/mysql-server status mysql is not running. ls -la /var/db/mysql/ total 177212 drwxr-xr-x 6 mysql mysql 512 Dec 15 20:28 . drwxr-xr-x 16 root wheel 512 Dec 1 04:15 .. -rw-rw---- 1 mysql mysql 56 Aug 25 2017 auto.cnf -rw-rw---- 1 mysql mysql 938011 Dec 15 20:28 homeline.pp.ua.err -rw-rw---- 1 mysql mysql 50331648 Dec 14 13:41 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 Dec 12 08:26 ib_logfile1 -rw-rw---- 1 mysql mysql 79691776 Dec 14 13:41 ibdata1 drwx------ 2 mysql mysql 2560 Aug 25 2017 mysql drwx------ 2 mysql mysql 4096 Dec 15 20:24 nodeny drwx------ 2 mysql mysql 2560 Aug 25 2017 performance_schema drwx------ 2 mysql mysql 512 Aug 25 2017 test my.cnf [mysqld] innodb_force_recovery=0 skip-networking character-set-server=utf8 init-connect="SET NAMES utf8" query_cache_size=64M long_query_time=5 slow_query_log=1 slow_query_log_file=/var/db/mysql/slow.log collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8 skip-external-locking low-priority-updates myisam-recover=backup,force [client] default-character-set=utf8 [mysql] default-character-set=utf8 localhost.err 2018-12-15 19:16:16 7774 [Note] Plugin 'FEDERATED' is disabled. 2018-12-15 19:16:16 7774 [Note] InnoDB: Using atomics to ref count buffer pool pages 2018-12-15 19:16:16 7774 [Note] InnoDB: The InnoDB memory heap is disabled 2018-12-15 19:16:16 7774 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-12-15 19:16:16 7774 [Note] InnoDB: Memory barrier is not used 2018-12-15 19:16:16 7774 [Note] InnoDB: Compressed tables use zlib 1.2.11 2018-12-15 19:16:16 7774 [Note] InnoDB: Not using CPU crc32 instructions 2018-12-15 19:16:16 7774 [Note] InnoDB: Initializing buffer pool, size = 128.0M 2018-12-15 19:16:16 7774 [Note] InnoDB: Completed initialization of buffer pool 2018-12-15 19:16:16 7774 [Note] InnoDB: Highest supported file format is Barracuda. 2018-12-15 19:16:16 7774 [Note] InnoDB: The log sequence numbers 13475082 and 13475082 in ibdata files do not match the log sequence number 102785521 in the ib_logfiles! 2018-12-15 19:16:16 7774 [Note] InnoDB: Database was not shutdown normally! 2018-12-15 19:16:16 7774 [Note] InnoDB: Starting crash recovery. 2018-12-15 19:16:16 7774 [Note] InnoDB: Reading tablespace information from the .ibd files... 2018-12-15 19:16:16 7774 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_index_stats uses space ID: 2 at filepath: ./mysql/innodb_index_stats.ibd. Cannot open tablespace nodeny/auth_log which uses space ID: 2 at filepath: ./nodeny/auth_log.ibd 2018-12-15 19:16:16 803616000 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. InnoDB: Error: could not open single-table tablespace file ./nodeny/auth_log.ibd InnoDB: We do not continue the crash recovery, because the table may become InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it. InnoDB: To fix the problem and start mysqld: InnoDB: 1) If there is a permission problem in the file and mysqld cannot InnoDB: open the file, you should modify the permissions. InnoDB: 2) If the table is not needed, or you can restore it from a backup, InnoDB: then you can remove the .ibd file, and InnoDB will do a normal InnoDB: crash recovery and ignore that table. InnoDB: 3) If the file system or the disk is broken, and you cannot remove InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf InnoDB: and force InnoDB to continue crash recovery here. вроде как просит удалить файл ./nodeny/auth_log.ibd - удалил не помогло, innodb_force_recovery начинал с 1 и доходил до 6 и после каждого увеличения /usr/local/etc/rc.d/mysql-server start также не помогло подскажите пжл чего еще не сделал?
mixtery Опубликовано: 15 декабря, 2018 Опубликовано: 15 декабря, 2018 1 час назад, WideAreaNetwork сказал: не получается стартануть мускул, уже устал от чтива, фря с нодени+, после моргания света не стартует mysql # /usr/local/etc/rc.d/mysql-server status mysql is not running. ls -la /var/db/mysql/ total 177212 drwxr-xr-x 6 mysql mysql 512 Dec 15 20:28 . drwxr-xr-x 16 root wheel 512 Dec 1 04:15 .. -rw-rw---- 1 mysql mysql 56 Aug 25 2017 auto.cnf -rw-rw---- 1 mysql mysql 938011 Dec 15 20:28 homeline.pp.ua.err -rw-rw---- 1 mysql mysql 50331648 Dec 14 13:41 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 Dec 12 08:26 ib_logfile1 -rw-rw---- 1 mysql mysql 79691776 Dec 14 13:41 ibdata1 drwx------ 2 mysql mysql 2560 Aug 25 2017 mysql drwx------ 2 mysql mysql 4096 Dec 15 20:24 nodeny drwx------ 2 mysql mysql 2560 Aug 25 2017 performance_schema drwx------ 2 mysql mysql 512 Aug 25 2017 test my.cnf [mysqld] innodb_force_recovery=0 skip-networking character-set-server=utf8 init-connect="SET NAMES utf8" query_cache_size=64M long_query_time=5 slow_query_log=1 slow_query_log_file=/var/db/mysql/slow.log collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8 skip-external-locking low-priority-updates myisam-recover=backup,force [client] default-character-set=utf8 [mysql] default-character-set=utf8 localhost.err 2018-12-15 19:16:16 7774 [Note] Plugin 'FEDERATED' is disabled. 2018-12-15 19:16:16 7774 [Note] InnoDB: Using atomics to ref count buffer pool pages 2018-12-15 19:16:16 7774 [Note] InnoDB: The InnoDB memory heap is disabled 2018-12-15 19:16:16 7774 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-12-15 19:16:16 7774 [Note] InnoDB: Memory barrier is not used 2018-12-15 19:16:16 7774 [Note] InnoDB: Compressed tables use zlib 1.2.11 2018-12-15 19:16:16 7774 [Note] InnoDB: Not using CPU crc32 instructions 2018-12-15 19:16:16 7774 [Note] InnoDB: Initializing buffer pool, size = 128.0M 2018-12-15 19:16:16 7774 [Note] InnoDB: Completed initialization of buffer pool 2018-12-15 19:16:16 7774 [Note] InnoDB: Highest supported file format is Barracuda. 2018-12-15 19:16:16 7774 [Note] InnoDB: The log sequence numbers 13475082 and 13475082 in ibdata files do not match the log sequence number 102785521 in the ib_logfiles! 2018-12-15 19:16:16 7774 [Note] InnoDB: Database was not shutdown normally! 2018-12-15 19:16:16 7774 [Note] InnoDB: Starting crash recovery. 2018-12-15 19:16:16 7774 [Note] InnoDB: Reading tablespace information from the .ibd files... 2018-12-15 19:16:16 7774 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_index_stats uses space ID: 2 at filepath: ./mysql/innodb_index_stats.ibd. Cannot open tablespace nodeny/auth_log which uses space ID: 2 at filepath: ./nodeny/auth_log.ibd 2018-12-15 19:16:16 803616000 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. InnoDB: Error: could not open single-table tablespace file ./nodeny/auth_log.ibd InnoDB: We do not continue the crash recovery, because the table may become InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it. InnoDB: To fix the problem and start mysqld: InnoDB: 1) If there is a permission problem in the file and mysqld cannot InnoDB: open the file, you should modify the permissions. InnoDB: 2) If the table is not needed, or you can restore it from a backup, InnoDB: then you can remove the .ibd file, and InnoDB will do a normal InnoDB: crash recovery and ignore that table. InnoDB: 3) If the file system or the disk is broken, and you cannot remove InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf InnoDB: and force InnoDB to continue crash recovery here. вроде как просит удалить файл ./nodeny/auth_log.ibd - удалил не помогло, innodb_force_recovery начинал с 1 и доходил до 6 и после каждого увеличения /usr/local/etc/rc.d/mysql-server start также не помогло подскажите пжл чего еще не сделал? innodb_force_recovery и стартуй сразу бинарник - проще логи будет увидеть запустится = дампай/дропай/восстанавливай ну или логи давай что mysql срёт в моменты запуска при force_recovery
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 10 часов назад, mixtery сказал: стартуй сразу бинарник решил глянуть /usr/local/etc/rc.d/mysql-server status получил # /usr/local/etc/rc.d/mysql-server status /etc/rc.conf: ext_if: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: binat: not found /etc/rc.conf: binat: not found /etc/rc.conf: binat: not found /etc/rc.conf: binat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: nat: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found /etc/rc.conf: rdr: not found Cannot 'status' mysql. Set mysql_enable to YES in /etc/rc.conf or use 'onestatus' instead of 'status'. глянул rc.conf ... сказать что охуел - это ничего не сказать, там тупо вся инфа как у файлике pf.conf , при этом маршрутизация работает, вланы подняты
l1ght Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 2 минуты назад, WideAreaNetwork сказал: глянул rc.conf ... сказать что охуел - это ничего не сказать, там тупо вся инфа как у файлике pf.conf , при этом маршрутизация работает, вланы подняты Чини ФС и на всякий случай поглядывай на свои бекапы. Если их нет, чтош, твоим данным жопа, правда на сколько сильная жопа - сложно сказать.
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 может не все так плохо, после ребута вернулось на свои места бекапы БД клиентов есть, буду дальше пробовать восстановить, хотя чем дальше в лес тем больше желание просто переустановить все, но как по мне это самый глупый вариант
l1ght Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 Только что, WideAreaNetwork сказал: может не все так плохо, после ребута вернулось на свои места бекапы БД клиентов есть, буду дальше пробовать восстановить, хотя чем дальше в лес тем больше желание просто переустановить все, но как по мне это самый глупый вариант Мало переустанавливать. Ещё и HDD заменить не забудь. Он уже пошел данные бить, нужно менять. 1
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 5 минут назад, l1ght сказал: Ещё и HDD заменить не забудь. да вроде пока все норм # cciss_vol_status -V /dev/ciss0 Controller: Smart Array E200i Board ID: 0x3211103c Logical drives: 0 Running firmware: 1.72 ROM firmware: 1.72 /dev/ciss0: (Smart Array E200i) RAID 1(1+0) Volume 0 status: OK. Physical drives: 4 connector 1I box 1 bay 1 HP DH036ABAA5 3PE0A8CR000098204EAN HPDB OK connector 1I box 1 bay 2 HP DH036ABAA5 3PE09S2000009822RAML HPDB S.M.A.R.T. predictive failure. connector 1I box 1 bay 3 HP DH036ABAA5 3PE09WP400009818HRJ5 HPDB OK connector 1I box 1 bay 4 IBM ST973402SS 3NP1V7VB00009814D3GF BF08 OK /dev/ciss0(Smart Array E200i:0): Non-Volatile Cache status: Cache configured: Yes Total cache memory: 32 MiB Cache Ratio: 100Read / 0Write Read cache memory: 32 MiB Write cache memory: 0 MiB Write cache enabled: Yes второй диск уже с полгода в таком состоянии
l1ght Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 1 минуту назад, WideAreaNetwork сказал: да вроде пока все норм Как скажешь ???
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 1 минуту назад, l1ght сказал: Как скажешь ??? я о дисках, что там с ФС я не знаю)
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 1 час назад, l1ght сказал: Ещё и HDD заменить не забудь. Он уже пошел данные бить, нужно менять. есть возможность вычислить какой? если стоит рейд 1+0, или менять все 4?
NiTr0 Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 2 часа назад, l1ght сказал: Ещё и HDD заменить не забудь. Он уже пошел данные бить, нужно менять. а с чего такой вывод что диск данные бьет? а не сбоящая память к примеру, или аппаратный рэйд контроллер?
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 16 часов назад, WideAreaNetwork сказал: не получается стартануть мускул мог я его долго запускать, сервак ломанули через мускул и подменили оболочку шел
l1ght Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 5 часов назад, NiTr0 сказал: а с чего такой вывод что диск данные бьет? а не сбоящая память к примеру, или аппаратный рэйд контроллер? Я предположил что там нет рейда и был не прав. 4 часа назад, WideAreaNetwork сказал: мог я его долго запускать, сервак ломанули через мускул и подменили оболочку шел А можно деталей чуть больше?))
WideAreaNetwork Опубликовано: 16 декабря, 2018 Опубликовано: 16 декабря, 2018 1 час назад, l1ght сказал: А можно деталей чуть больше?)) это уже подсказали добрые люди которые помогли восстановить, я бы точно такое не определил, далеко еще мне) у меня практика очень маленькая, с фрей максимум полтора года работаю, однозначно лучше чем мтик) сказали в фаере закрыть доступ извне к мускулу, доступ руту дать только с локалхоста и все, а далее снова читать тонны макулатуры
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас