| Bug #3015 | (binlog, position) stored by InnoDB for a replication slave can be wrong | ||
|---|---|---|---|
| Submitted: | 29 Feb 2004 15:16 | Modified: | 1 Mar 2004 6:19 |
| Reporter: | Guilhem Bichot | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 4.0, 4.1, 5.0 | OS: | Any (all) |
| Assigned to: | Guilhem Bichot | CPU Architecture: | Any |
[1 Mar 2004 6:19]
Guilhem Bichot
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
Fixed in ChangeSet@1.1719.1.5, 2004-03-01 15:15:58+01:00, guilhem@mysql.com
Description: 1) In 4.0 there is: trx->mysql_master_log_pos = ((ib_longlong) (active_mi->rli.master_log_pos + active_mi->rli.event_len + active_mi->rli.pending)); 'event_len' is the length of the COMMIT event. But 'pending' measures the distance between the BEGIN and the COMMIT _in_the_relay_log_, not in the master's binlog. So if there was a disconnection/reconnection why the I/O slave thread was reading the transaction, there is an additional Rotate event in the relay log, so: wrong (it can be too big). 2) In 4.1 there is: trx->mysql_master_log_pos = ((ib_longlong) (active_mi->rli.group_master_log_pos + active_mi->rli.event_len )); But 'group_master_log_pos' is the position of the BEGIN, so: wrong (it is too small). 3) In 5.0 it is good, except that it works only for Query events, not Load events (for LOAD DATA INFILE); so for a LOAD DATA INFILE running in autocommit mode (in which case there is no COMMIT in the binlog), it's wrong again. How to repeat: just read code in ha_innodb.cc Suggested fix: First extend the code in 5.0 to Load_log_event if possible (note that it will become less critical when the new logging of LOAD DATA INFILE is pushed; the problem will only remain for 4.x -> 5.0 replication of LOAD DATA INFILE). Then backport the updated 5.0 code into 4.0 and 4.1 (not a trivial backport as the variables were changed between each version).