Welcome Guest, Not a member yet? Register   Sign In
ci_sessions is marked as crashed and should be repaired
#1

There errors were emailed to me today, but when I went to the site everything seemed fine. I had the same error come through a few minutes later, and haven't had a problem since. I was able to login, which requires a session.  I was expecting that the session table would be corrupt or something, and that I wasn't going to be able to log in. Weird, yes?


Code:
2016-06-15 06:56:15
Error Number: 145
Table './abc/ci_sessions' is marked as crashed and should be repaired
SELECT `data`
FROM `ci_sessions`
WHERE `id` = '253a4c0e419de9100b8e881eeee504b91f106c0d'
AND `ip_address` = '51.255.65.4'
Filename: libraries/Session/drivers/Session_database_driver.php
Line Number: 166
Request URI: /abc

2016-06-15 06:56:15
Error Number: 145
Table './abc/ci_sessions' is marked as crashed and should be repaired
INSERT INTO `ci_sessions` (`id`, `ip_address`, `timestamp`, `data`) VALUES ('253a4c0e419de9100b8e881eeee504b91f106c0d', '51.255.65.4', 1466042175, '')
Filename: libraries/Session/drivers/Session_database_driver.php
Line Number: 233
Request URI: /abc


Table is standard issue:


Code:
--
-- Table structure for table `ci_sessions`
--

CREATE TABLE IF NOT EXISTS `ci_sessions` (
 `id` varchar(40) COLLATE utf8_unicode_ci NOT NULL,
 `ip_address` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
 `timestamp` int(10) unsigned NOT NULL DEFAULT '0',
 `data` blob NOT NULL,
 PRIMARY KEY (`id`,`ip_address`),
 KEY `ci_sessions_timestamp` (`timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci


Even though I wasn't personally experiencing any problems, I went into phpMyAdmin and repaired the table.

I've never seen such an error, have you? Any reason why it would happen?
Reply
#2

I have seen it, but many years ago and I don't know what can cause it.
However, I do suspect it is something MyISAM-specific ... don't know why you're using that, you don't need it for sessions and it hasn't been the default for a long time now.
Reply
#3

Well, I suppose after searching for "MyISAM vs InnoDB" I thought that since I don't need transactions or full text searching for that table there may be some sort of performance gain to MyISAM, because there is an indication that storage speed is better with MyISAM. This type of error really blows though, so I may just switch just so I never deal with this again.
Reply
#4

MyISAM typically does faster INSERTs because it doesn't lock the table in that case, but that's also possibly the reason for these crashes. Also, fulltext search has been MyISAM's biggest selling point since forever, InnoDB only got it recently.

In general MyISAM is better for logging-type stuff where you just insert lots and lots of data that you rarely modify, while InnoDB is for everything else, especially operational data like sessions.
Reply
#5

(06-16-2016, 10:31 AM)Narf Wrote: MyISAM typically does faster INSERTs because it doesn't lock the table in that case, but that's also possibly the reason for these crashes. Also, fulltext search has been MyISAM's biggest selling point since forever, InnoDB only got it recently.

In general MyISAM is better for logging-type stuff where you just insert lots and lots of data that you rarely modify, while InnoDB is for everything else, especially operational data like sessions.

Thanks for the info. Do you think MyISAM is still the right choice if all you're doing is inserts and deletes? (no modifications)
Reply
#6

DELETEs are modifications, but either way I've got no opinion on that case ... I can't remember a case I've had that would do INSERTs and DELETEs, but no UPDATEs.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB