Bug #29536 | timestamp inconsistent in replication around 1970 | ||
---|---|---|---|
Submitted: | 4 Jul 2007 1:30 | Modified: | 25 Aug 2007 15:43 |
Reporter: | Adam Dixon | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.0.44 | OS: | Any |
Assigned to: | Georgi Kodinov | CPU Architecture: | Any |
Tags: | bfsm_2007_07_19 |
[4 Jul 2007 1:30]
Adam Dixon
[4 Jul 2007 1:30]
Adam Dixon
Output from master binlog
Attachment: master.binlog.sql (text/x-sql), 2.83 KiB.
[4 Jul 2007 1:31]
Adam Dixon
Output from slave relay log.
Attachment: slave.binlog.sql (text/x-sql), 1.58 KiB.
[6 Aug 2007 11:57]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/32138 ChangeSet@1.2501, 2007-08-06 04:57:28-07:00, gkodinov@magare.gmz +4 -0 Bug #29536: timestamp inconsistent in replication around 1970 MySQL replicates the time zone only when operations that involve it are performed. This is controlled by a flag. But this flag is set only on successful operation. The flag must be set also when there is an error that involves a timezone (so the master would replicate the error to the slaves). Fixed by moving the setting of the flag before the operation (so it apples to errors as well).
[15 Aug 2007 9:48]
Bugs System
Pushed into 5.1.22-beta
[15 Aug 2007 9:51]
Bugs System
Pushed into 5.0.48
[25 Aug 2007 15:43]
Paul DuBois
Noted in 5.0.48, 5.1.22 changelogs. Operations that used the time zone replicated the time zone only for successful operations, but did not replicate the time zone for errors that need to know it.