If you get corrupted tables or if mysqld always fails after some update commands, you can test whether this bug is reproducible by doing the following:
Take down the MySQL daemon (with mysqladmin shutdown).
Make a backup of the tables (to guard against the very unlikely case that the repair does something bad).
Check all tables with myisamchk -s
database/*.MYI. Repair any wrong tables with
myisamchk -r
database/table
.MYI.
Make a second backup of the tables.
Remove (or move away) any old log files from the MySQL data directory if you need more space.
Start mysqld with the binary log enabled. If you want to find a query that crashes mysqld, you should start the server with both the general query log enabled as well. See Section 5.2.2, “The General Query Log”, and Section 5.2.3, “The Binary Log”.
When you have gotten a crashed table, stop the
mysqld server
.
Restore the backup.
Restart the mysqld server without the binary log enabled.
Re-execute the commands with mysqlbinlog
binary-log-file | mysql. The binary log is saved
in the MySQL database directory with the name
hostname-bin.
.
NNNNNN
If the tables are corrupted again or you can get
mysqld to die with the above command,
you have found reproducible bug that should be easy to
fix! FTP the tables and the binary log to
ftp://ftp.mysql.com/pub/mysql/upload/ and report it in our
bugs database using the instructions given in
Section 1.7, “How to Report Bugs or Problems”. (Please note that the
/pub/mysql/upload/
FTP directory is
not listable, so you'll not see what you've uploaded in
your FTP client.) If you are a support customer, you can
use the MySQL Customer Support Center
https://support.mysql.com/ to alert the
MySQL team about the problem and have it fixed as soon as
possible.
You can also use the script mysql_find_rows to just execute some of the update statements if you want to narrow down the problem.
The preceding discussion applies only to RHEL4. The patch is unnecessary for RHEL5.
User Comments
Add your own comment.