Tag Info

I have good news, and bad news. The good news is, your filesystem and mysql are most likely fine... but check /var/log/syslog or equivalent to see what else was happening on your system before 10:21:05. When the first message you posted was logged, your mysql server had already died. 120927 10:21:05 mysqld_safe Number of processes running now: 0 So, ...

Please review my answer to this recent question. I believe the circumstances are identical. Do not change your MySQL configuration at this point, as MySQL is not the problem -- it's only a symptom of the problem... which is that you appear to have a system with a small amount of memory and zero swap space. Your server is not crashing "because" memory ...

Follow the steps outlines in How to use the DBCC MEMORYSTATUS command to monitor memory usage on SQL Server. The remedy action will depend on your findings. You can also read How to Identify Microsoft SQL Server Memory Bottlenecks which is more accessible. One word of caution though: is unlikely you will find individual queries to blame. Tracking downs ...

ASPECT #1 The first thing that caught my eye was this line InnoDB: Error: trying to load index PRIMARY for table / This indicates you have a table using the InnoDB Storage Engine What is interesting about InnoDB is the way a PRIMARY KEY is stored. It is stored in a structure called the gen_clust_index, or more commonly known as the Clustered Index. ...

It seems theoretically possible that table could still dump properly if the corruption were in the indexes, which aren't dumped. It should not be possible for anything in your configuration to cause MySQL to crash with a Signal 11, a segmentation fault. I've been staring at this for a while, now, and I haven't come up with answers... just questions (in no ...

This error: ERROR 145 (HY000) at line 2970: Table './mysql/proc' is marked as crashed and should be repaired 228MB mysqldump: Got errno 32 on write ... suggests that the problem is writing not reading, so do a repair on the destination database.

Following these steps probably offers a decent shot at making the MySQL instance happy again... recreate the database's directory that you deleted create an InnoDB table with the same exact column names and definitions and the same table name, but in a different schema (or on a different server) copy only the .frm file for that table into the database's ...