[Решено] Пользователи не могут авторизоваться

Здравствуйте. Недавно переехала на новый хостинг (vds) и в тоже время обновилась до последней версии. Все работало нормально, но пару дней назад полетел mysql. Т.е. даже другие сайты на сервере перестали соединяться с mysql, она просто не запускалась. Погуглив, я поняла, что это из-за поврежденных таблиц innoDB. Такие таблицы у меня только на одном сайте с движком AltoCMS. В итоге mysql все таки запустила, но теперь отвалилась авторизация на сайте. Лог ошибок пишет следующее:
SQL Error: Got error -1 from storage engine at /.../common/classes/modules/user/mapper/User.mapper.class.php line 207
---
Array
(
    [code] => 1030
    [message] => Got error -1 from storage engine
    [query] => INSERT INTO prefix_session
                    (
                        session_key,
                        user_id,
                        session_ip_create,
                        session_ip_last,
                        session_date_create,
                        session_date_last,
                        session_agent_hash
                    )
                    VALUES (
                        '0x:287f562f43b69324cbe4e9eae111b464' ,
                        2820 ,
                        '83.139.137.90' ,
                        '83.139.137.90' ,
                        '2015-01-14 08:12:32' ,
                        '2015-01-14 08:12:32' ,
                        '0x:2cb27f87bc2cc5280b4a3d9df0c5fed1'
                    )
            
    [context] => /.../common/classes/modules/user/mapper/User.mapper.class.php line 207
)

Пробовала очищать таблицу prefix_session, а также удаляла ее и снова создавала. Толку ноль.
Прошу помощи, хотя бы в какую сторону копать. Спасибо!

Похожие статьи


11 комментариев

0
Тут мог бы помочь /var/log/mysql/error.log
0
/var/log/mysql/error.log — там куча непонятной инфы)) постараюсь выложить кусок
0
150114 11:47:43 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
150114 11:47:43 [Note] Plugin 'FEDERATED' is disabled.
150114 11:47:43 InnoDB: The InnoDB memory heap is disabled
150114 11:47:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150114 11:47:43 InnoDB: Compressed tables use zlib 1.2.3.4
150114 11:47:43 InnoDB: Initializing buffer pool, size = 128.0M
150114 11:47:43 InnoDB: Completed initialization of buffer pool
150114 11:47:43 InnoDB: highest supported file format is Barracuda.
150114 11:47:44  InnoDB: Waiting for the background threads to start
150114 11:47:45 InnoDB: 5.5.40 started; log sequence number 4256070218
150114 11:47:45 InnoDB: !!! innodb_force_recovery is set to 1 !!!
150114 11:47:45 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
150114 11:47:45 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
150114 11:47:45 [Note] Server socket created on IP: '127.0.0.1'.
150114 11:47:45 [Note] Event Scheduler: Loaded 0 events
150114 11:47:45 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.40-0ubuntu0.12.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
0
Отлично, только желательно содержимое в момент когда эта ошибка вываливается =)
0
Так поврежденные таблицы в итоге были восстановлены? Из-за них и может возникать такая ошибка.
Еще результаты из гугла молвят про параметр «innodb_force_recovery» в my.cnf — он должен отсутствовать или быть равным 0.
0
параметр как раз этот я и поставила innodb_force_recovery = 1, но как я тоже нагуглила, что оно само по себе не чинит таблицу, а отключает какие-то там проверки. После установки этого параметра я смогла запустить mysql. Но видимо таблицы не восстановились, т.к. я больше ничего не делала кроме как очищала и удаляла/создавала таблицу session
0
Предлагаю попробовать проверить статус таблиц по этой инструкции wiki.jumpbox.com/doc/runtime/faq/mysql_maintenance
И, если найдутся битые, то попытаться починить через REPAIR TABLE.
Отредактирован:
+1
Оу, я балда) невнимательно прочитала вначале. Поставила равным 0 и все получилось! Спасибо огромное!
0
я так понимаю именно про это и были сообщения

InnoDB: innodb_force_recovery is on: we do not allow
0
ага)
0
Вобщем, подведу итог) Видимо, в какой-то момент сломалась таблица prefix_sesson. Из-за сломанной таблицы не запускался mysql. Чтобы его запустить (чтобы починить таблицу) надо было поставить в my.cnf параметр innodb_force_recovery = 1. После запуска mysql починила таблицу (видимо или очистила или удалила и снова создала — что-то из этого помогло). Но после этого, надо не забыть убрать innodb_force_recovery или поставить 0. И перезагрузить mysql.
Вдруг кому-то пригодится)
@inliquid, @Can0r, cпасибо за помощь! задача решена)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.