summaryrefslogtreecommitdiff
path: root/sql/rpl_rli.cc
diff options
context:
space:
mode:
authorunknown <knielsen@knielsen-hq.org>2014-01-08 11:00:44 +0100
committerunknown <knielsen@knielsen-hq.org>2014-01-08 11:00:44 +0100
commit8cc6e90d74f4377491bcb7a0f1acd41ccf9fbcae (patch)
tree9d9878767d72068230ba15fc934259524b81c34d /sql/rpl_rli.cc
parentbfdbb17990b198ff2a7e5eda5e2a365a1c6d8906 (diff)
downloadmariadb-git-8cc6e90d74f4377491bcb7a0f1acd41ccf9fbcae.tar.gz
MDEV-5509: Seconds_behind_master incorrect in parallel replication
The problem was a race between the SQL driver thread and the worker threads. The SQL driver thread would set rli->last_master_timestamp to zero to mark that it has caught up with the master, while the worker threads would set it to the timestamp of the executed event. This can happen out-of-order in parallel replication, causing the "caught up" status to be overwritten and Seconds_Behind_Master to wrongly grow when the slave is idle. To fix, introduce a separate flag rli->sql_thread_caught_up to mark that the SQL driver thread is caught up. This avoids issues with worker threads overwriting the SQL driver thread status. In parallel replication, we then make SHOW SLAVE STATUS check in addition that all worker threads are idle before showing Seconds_Behind_Master as 0 due to slave idle.
Diffstat (limited to 'sql/rpl_rli.cc')
-rw-r--r--sql/rpl_rli.cc9
1 files changed, 7 insertions, 2 deletions
diff --git a/sql/rpl_rli.cc b/sql/rpl_rli.cc
index cfa7c0f344f..7f0ec702b87 100644
--- a/sql/rpl_rli.cc
+++ b/sql/rpl_rli.cc
@@ -56,7 +56,7 @@ Relay_log_info::Relay_log_info(bool is_slave_recovery)
is_fake(FALSE),
#endif
group_master_log_pos(0), log_space_total(0), ignore_log_space_limit(0),
- last_master_timestamp(0), slave_skip_counter(0),
+ last_master_timestamp(0), sql_thread_caught_up(true), slave_skip_counter(0),
abort_pos_wait(0), slave_run_id(0), sql_driver_thd(),
inited(0), abort_slave(0), slave_running(0), until_condition(UNTIL_NONE),
until_log_pos(0), retried_trans(0), executed_entries(0),
@@ -1287,9 +1287,14 @@ void Relay_log_info::stmt_done(my_off_t event_master_log_pos,
(probably ok - except in some very rare cases, only consequence
is that value may take some time to display in
Seconds_Behind_Master - not critical).
+
+ In parallel replication, we take care to not set last_master_timestamp
+ backwards, in case of out-of-order calls here.
*/
if (!(event_creation_time == 0 &&
- IF_DBUG(debug_not_change_ts_if_art_event > 0, 1)))
+ IF_DBUG(debug_not_change_ts_if_art_event > 0, 1)) &&
+ !(rgi->is_parallel_exec && event_creation_time <= last_master_timestamp)
+ )
last_master_timestamp= event_creation_time;
}
DBUG_VOID_RETURN;