[wp-trac] Re: [WordPress Trac] #4677: Automatic REPAIR TABLE tablename after MySQL error 127

WordPress Trac wp-trac at lists.automattic.com
Thu Dec 11 04:23:19 GMT 2008


#4677: Automatic REPAIR TABLE tablename after MySQL error 127
------------------------------------------+---------------------------------
 Reporter:  markjaquith                   |        Owner:  anonymous
     Type:  enhancement                   |       Status:  new      
 Priority:  normal                        |    Milestone:  2.8      
Component:  General                       |      Version:  2.2.1    
 Severity:  major                         |   Resolution:           
 Keywords:  mysql error 127 repair table  |  
------------------------------------------+---------------------------------
Comment (by vladimir_kolesnikov):

 Replying to [comment:7 mrmist]:
 > The user-friendly part of me suggests that it might be a good idea to
 attempt a repair.

 And if REPAIR for some reason fails (one of that rare cases when after
 MySQL crash index file gets corrupted and you need to issue REPAIR TABLE
 xxx USE_FRM)? need a way to prevent infinite REPAIR loop.

 Another issue that worries me is that what happens if a table crashed
 under heavy load (e.g., misconfigured MySQL died on signal 11)? With this
 scenario we are going to try to REPAIR the table but if MySQL dies (again)
 while REPAIR is in progress, bad things may happen.

 Last, but not least, MySQL manual (http://dev.mysql.com/doc/refman/5.0/en
 /repair-table.html) says this:

   Caution: It is best to make a backup of a table before performing a
 table repair operation; under some circumstances the operation might cause
 data loss. Possible causes include but are not limited to filesystem
 errors.

 and

   If the server dies during a REPAIR TABLE operation, it is essential
 after restarting it that you immediately execute another REPAIR TABLE
 statement for the table before performing any other operations on it. In
 the worst case, you might have a new clean index file without information
 about the data file, and then the next operation you perform could
 overwrite the data file. This is an unlikely but possible scenario.


 > where a user isn't techy enough to do it themselves.

 If the user is not techy enough, IMO he should ask his hoster's support to
 fix the error. Quoting the MySQL manual again,

   If your tables become corrupted often, you should try to find the reason
 for it, to eliminate the need to use REPAIR TABLE

 Need to fix the problem, not cure symptoms.

 I would suggest not to try to do sysadmin's job. Data recovery is not a
 pleasant thing.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/4677#comment:9>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list