Re: Site back up again

[Old_Gray_Bear]

(THANK YOU)^5

Thank ALL of you who were involved.

Can I trouble you for a couple more pieces of information? Can you list the Monks involved in the recovery, that I may say appropriate novenas for them? And can you give more detail on what went wrong with the database? There are not a few of us in the Monastery who use MySQL in the Real World, and I, at least, would like to know what happened in detail so I can look at setting up counter-measures.

[Corion]

The database server suffered some corruption of its MyISAM tables. This was discovered and acted on by Pair. The only active involvement by tye, yitzhack and me was to decide that one particularly large table should not be restored. That table was for request statistics, so we've lost the access statistics per page, but that's a small price to pay.

I'm not sure what caused the table corruption. It became very manifest after I restarted the MySQL server, but maybe that was also what caused the corruption in the first place. Maybe it can be discovered earlier by frequently running show table status $table and/or check table $table.

As the recovery process employed by MySQL/myisamchk respectively repair $table seemed to be mostly rebuilding the MyISAM index from the raw table file, future decisions will likely weigh the recency of the last backup, as filling the database from a backup is much faster than rechecking/repopulating the table by scanning a MyISAM file.

Update: Added a crucial "maybe" in the first sentence of the second paragraph.

[CountZero]

I suffered a similar problem with MySQL very recently. During a routine adding of new records to our database and updating old records, my computer (Windows XP) crashed and seemed to have left some of the index tables in disarray.

After that reading of some records failed for no obvious reason with a so<mewhat helpful error message ("[ERROR] C:\data\Program Files\MySQL\MySQL Server 5.1\bin\mysqld: Incorrect key file for table '.\pandirecords\claims.MYI'; try to repair it"). Running the full check and repair suite fixed it in less than an hour (in total about 600,000 records in that database).