| Bug #29538 | clock skew gives impossible time behind master on slave | ||
|---|---|---|---|
| Submitted: | 4 Jul 2007 2:03 | Modified: | 4 Jul 2007 9:16 |
| Reporter: | River Tarnell | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.0.42-enterprise-gpl | OS: | Solaris (Solaris 10 11/06) |
| Assigned to: | CPU Architecture: | Any | |
[4 Jul 2007 9:16]
Sveta Smirnova
Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in MySQL. Duplicate of Bug #22047
Description: The MySQL replication SQL thread's running time is usually set to the lag behind the master server. If there is clock skew between the master and the slave, and the slave gets a binlog event which appears to be in the future, it will show an impossible value instead: *************************** 2. row *************************** Id: 2 User: system user Host: db: enwiki Command: Connect Time: 4294967295 State: Reading event from the relay log Info: COMMIT How to repeat: Set up a master/slave where the master's clock is ahead of the slave's. Start replication and run SHOW PROCESSLIST; on the slave. Suggested fix: Either show 0, or show the actual difference, e.g. "-2" if the master event is 2 seconds in the future.