MySQL Reference Manual for version 4.0.18.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.10 Reporting Replication Bugs

When you have determined that there is no user error involved, and replication still either does not work at all or is unstable, it is time to send us a bug report. We need to get as much information as possible from you to be able to track down the bug. Please do spend some time and effort preparing a good bug report.

If you have a repeatable way to demonstrate the bug, please enter it into our bugs database at http://bugs.mysql.com/. If you have a phantom problem (one that you cannot duplicate "at will"), use the following procedure:

  1. Verify that no user error is involved. For example, if you update the slave outside of the slave thread, the data will go out of sync, and you can have unique key violations on updates. In this case, the slave thread will stop and wait for you to clean up the tables manually to bring them in sync. This is not a replication problem; it is a problem of outside interference that causes replication to fail.
  2. Run the slave with the --log-slave-updates and --log-bin options. They will cause the slave to log the updates that it receives in its own binlogs.
  3. Save all evidence before resetting the replication state. If we have no information or only sketchy information, it will take us longer to track down the problem. The evidence you should collect is:
  4. Use mysqlbinlog to examine the binary logs. The following should be helpful to find the trouble query, for example:
     
    mysqlbinlog -j pos_from_slave_status /path/to/log_from_slave_status | head
    

Once you have collected the evidence for the phantom problem, try hard to isolate it into a separate test case first. Then enter the problem into our bugs database at http://bugs.mysql.com/ with as much information as possible.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by rdg (Feb 25 2004) using texi2html