Ошибки в базе данных Mysql. Некорректно завершили работу сервера

[denis.my.life]

много ошибок DBD::mysql::st execute failed: Got error 134 from storage engine at nodeny.pl line 1313.

До этого еще были ошибки
DBD::mysql::db do failed: Table './bill/y2011x2x9' is marked as crashed and should be repaired at nodeny.pl line 1157.
DBD::mysql::db do failed: Table './bill/z2011x2x13' is marked as crashed and should be repaired at nodeny.pl line 2051.
но их почти полностью удалось убрать
выставив max_allowed_packet = 16M в my.cnf
и REPAIR TABLE в мускул

[stix]

ну так пофикси

[Fredik]

это ошибка неправильно выключенного сервера и может вылезти на любой версии нодени

[Efendy]

Не думаю, что поломка таблиц зависит от max_allowed_packet. Скорее всего сервер ребутнули ресетом. К NoDeny не имеет никакого отношения

[denis.my.life]

 Неожиданно быстрые ответы) я приятно удивлен)
Есть предложения как профиксить?
DBD::mysql::st execute failed: Got error 134 from storage engine at nodeny.pl line 1313.

они появляются похоже каждую минуту. Весь лог админки забит.
Система на первый взгляд работает нормально.

[VitalVas]

use the mozg!

[smallcms]

У себя сочинил такой скрипт:

Код:

#!/bin/sh
passwd_root_mysql=`perl -e'require "/usr/local/nodeny/history.nod"; print $sql_root_pass;'`
datapath=`mysqladmin --host=localhost --user=root --password=${passwd_root_mysql} variables | grep 'datadir' | awk '{print $4}'`
for dir in $(find $datapath* -type d)
do
dir=`basename $dir`
mysqlcheck --user=root --password=${passwd_root_mysql} --auto-repair $dir | grep -v 'OK'
done

Так или иначе вопрос о крахе MySQL таблиц никак не связан с биллинговой системой, которая использует MySQL в качестве базы данных.

[denis.my.life]

use the mozg!

mysqlcheck -p(password root) --repair --analyze --all-databases --auto-repair
чтото поиспровляла но ошибки продолжили сыпатся

[ser970]

use the mozg!

mysqlcheck -p(password root) --repair --analyze --all-databases --auto-repair
чтото поиспровляла но ошибки продолжили сыпатся

ну воперых показал бы что было испраленно что нет.
во вторых по пробуй так
останови мускул
и
 myisamchk -r /путь к базе/*.MYI

если по умолчанию
 myisamchk -r /var/db/mysql/bill/*.MYI

а так для разнообразия почитай про ремонт базы - в гугле валом.

[stix]

еще может жесткий диск посыпался

[VitalVas]

myisamchk —safe-recover /var/db/mysql/bill/*.MYI

[denis.my.life]

еще может жесткий диск посыпался

диск периодически проверяю переназначенных секторов нет...

[denis.my.life]

Итак "проблема" решилась следующим образом
1 делаю бекап системы.
2 остановил mysql
mysqladmin  -p shutdown
3 воспользовался советом ser970
myisamchk -r /var/db/mysql/bill/*.MYI
4 стартанул mysql
mysqladmin -p start
далее неприятный сюрприз nodney не востановил соединение с mysql автоматически.
5 reboot
ошибок в логе больше нет всем спасибо!
такого мощного сапорта я даже не ожидал)

[gonhik]

Здравствуйте,  сделал все кок было описано выше и пропали ошибки с вязание с БД, удалил файл NEW_MONTH_ERROR и запустил скрипт заново но файл создался и там записало вот что " new_month.pl: \xef\xe5\xf0\xe5\xf5\xee\xe4 \xed\xe0 \xed\xee\xe2\xfb\xe9 \xec\xe
5\xf1\xff\xf6 \xed\xe5 \xee\xf1\xf3\xf9\xe5\xf1\xf2\xe2\xeb\xe5\xed! \xcf\xf0\xe
8\xf7\xe8\xed\xe0: \xf2\xe5\xea\xf3\xf9\xe5\xe5 \xf7\xe8\xf1\xeb\xee \xe1\xee\xe
b\xfc\xf8\xe5 1. \xcf\xe5\xf0\xe5\xf5\xee\xe4 \xf0\xe0\xe7\xf0\xe5\xf8\xe5\xed \
xf2\xee\xeb\xfc\xea\xee 1-\xe3\xee \xf7\xe8\xf1\xeb\xe0. \xc4\xeb\xff \xef\xf0\x
e8\xed\xf3\xe4\xe8\xf2\xe5\xeb\xfc\xed\xee\xe3\xee \xef\xe5\xf0\xe5\xf5\xee\xe4\
xe0 \xe7\xe0\xef\xf3\xf1\xf2\xe8\xf2\xe5 \xf1\xea\xf0\xe8\xef\xf2 \xf1 \xea\xeb\
xfe\xf7\xee\xec '-t'. \xd2.\xe5.
shell# ./new_month.pl -t "
это харашо или плохо ?

[versus]

Это хорошо, осталось научится настраивать ваш шел для доступа к удаленному серверу понимать кодировку cp1251. Тогда наступит счастье.