(mysql.info.gz) Replication Bugs

(mysql.info.gz) Replication Problems
 
 6.11 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 test case that demonstrates 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 from the master into its own binary logs.
 
   3. Save all evidence before resetting the replication state. If we
      have no information or only sketchy information, it becomes
      difficult or impossible for us to track down the problem. The
      evidence you should collect is:
 
         * All binary logs from the master
 
         * All binary logs from the slave
 
         * The output of `SHOW MASTER STATUS' from the master at the time
           you have discovered the problem
 
         * The output of `SHOW SLAVE STATUS' from the master at the time
           you have discovered the problem
 
         * Error logs from the master and the slave
 
   4. Use `mysqlbinlog' to examine the binary logs. The following should
      be helpful to find the trouble query, for example:
           shell> 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.
Info Catalog
(mysql.info.gz) Replication Problems
(mysql.info.gz) Replication
automatically generated byinfo2html