| Bug #56445 | The last_master_timestamp can not keep monotone order | ||
|---|---|---|---|
| Submitted: | 1 Sep 2010 9:57 | Modified: | 11 Jan 2011 5:38 |
| Reporter: | Daogang Qu | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.5+ | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[11 Jan 2011 5:38]
Daogang Qu
In mysql-trunk tree, the problem will be reproduced
by updating code as following:
--- sql/rpl_slave.cc 2010-12-10 16:55:50 +0000
+++ sql/rpl_slave.cc 2011-01-11 03:28:46 +0000
@@ -2899,7 +2899,10 @@
if (!(ev->is_artificial_event() || ev->is_relay_log_event() ||
(ev->when == 0) || ev->get_type_code() == FORMAT_DESCRIPTION_EVENT))
{
+ time_t rli_last_master_timestamp= rli->last_master_timestamp;
rli->last_master_timestamp= ev->when + (time_t) ev->exec_time;
+ DBUG_ASSERT(rli_last_master_timestamp <= rli->last_master_timestamp);
+
DBUG_ASSERT(rli->last_master_timestamp >= 0);
}
And rpl_semi_sync_event, rpl_udf and so on will cause the failure of the
DBUG_ASSERT(rli_last_master_timestamp <= rli->last_master_timestamp)
as following:
110111 7:31:31 [Note] next log './slave-relay-bin.000003' is currently active
mysqld: /home/daogang/bzrwork/bug58712/mysql-trunk/sql/rpl_slave.cc:2904: int exec_relay_log_event(THD*, Relay_log_info*): Assertion `rli_last_master_timestamp <= rli->last_master_timestamp' failed.
110111 7:31:39 - mysqld got signal 6 ;
Description: The last_master_timestamp is updated at the begin of execution of every event even if in a transaction as following: if (!(ev->is_artificial_event() || ev->is_relay_log_event() || (ev->when == 0) || ev->get_type_code() == FORMAT_DESCRIPTION_EVENT)) { rli->last_master_timestamp= ev->when + (time_t) ev->exec_time; DBUG_ASSERT(rli->last_master_timestamp >= 0); } The monotone order of last_master_timestamp will be ruined when more one transactions cross executed in parallel. So that the value of Seconds_Behind_Master (see Bug #52166) in SHOW SLAVE STATUS command is not trustable. How to repeat: See rpl_seconds_behind_master.test and read the above code block. Suggested fix: The last_master_timestamp should be updated at the end of a transaction or a statement(non-transaction). Then the value of Seconds_Behind_Master will be trustable.