| Bug #89185 | Please report configured slave delay when starting a slave. | ||
|---|---|---|---|
| Submitted: | 11 Jan 2018 10:59 | Modified: | 22 Jan 2018 9:28 |
| Reporter: | Simon Mudd (OCA) | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S4 (Feature request) |
| Version: | 5.7.20 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | logging, sql_delay | ||
[11 Jan 2018 11:37]
Simon Mudd
I'd guess that something like:
diff --git a/sql/rpl_slave.cc b/sql/rpl_slave.cc
index 7539b0e486f..9bcfaffbc62 100644
--- a/sql/rpl_slave.cc
+++ b/sql/rpl_slave.cc
@@ -7286,11 +7286,12 @@ extern "C" void *handle_slave_sql(void *arg)
rli->get_group_master_log_name(),
llstr(rli->get_group_master_log_pos(),llbuff)));
sql_print_information("Slave SQL thread%s initialized, starting replication in"
- " log '%s' at position %s, relay log '%s' position: %s",
+ " log '%s' at position %s, relay log '%s' position: %s, sql_delay: %d",
rli->get_for_channel_str(), rli->get_rpl_log_name(),
llstr(rli->get_group_master_log_pos(),llbuff),
rli->get_group_relay_log_name(),
- llstr(rli->get_group_relay_log_pos(),llbuff1));
+ llstr(rli->get_group_relay_log_pos(),llbuff1),
+ sql_delay);
if (check_temp_dir(rli->slave_patternload_file, rli->get_channel()))
{
should fix this but not tested.
[22 Jan 2018 9:28]
MySQL Verification Team
Hello Simon, Thank you for the report and feature request! Thanks, Umesh

Description: I have other FRs open about including GTID information which is not shown when replication is started or stopped but this is similar. Current logging in 5.7.X shows: 2018-01-11T10:48:38.894357Z 1 [Note] Error reading relay log event for channel '': slave SQL thread was killed 2018-01-11T10:48:38.898022Z 39704 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'binlog.000003' at position 69004508, relay log '../log/relaylog.000007' position: 69004715 But I also changed the explicit replication delay as can be seen here: root@myhost [(none)]> pager grep SQL_Delay PAGER set to 'grep SQL_Delay' root@myhost [(none)]> show slave status\G SQL_Delay: 5 1 row in set (0.00 sec) This information is not visible. How to repeat: See above. Suggested fix: Something like the following would be better. 2018-01-11T10:48:38.898022Z 39704 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'binlog.000003' at position 69004508, relay log '../log/relaylog.000007' position: 69004715, sql_delay: 5