Elena Stepanova added a comment - 2018-01-23 17:57 - edited It looks like a usual documentation deficiency. MySQL manual actually describes it quite explicitly: In MySQL 5.6.9 and later, this field is NULL (undefined or unknown) if the slave SQL thread is not running, or if the SQL thread has consumed all of the relay log and the slave I/O thread is not running. Previously, this field was NULL if the slave SQL thread or the slave I/O thread was not running or was not connected to the master. https://dev.mysql.com/doc/refman/5.6/en/show-slave-status.html So, both before and after 5.6.9, the field was/is NULL when IO thread was not running. I'll leave it to Elkin to decide if he wants to change it. In any case, it should be documented much better, since Seconds_Behind_Master is one of the most notoriously confusing status values in MySQL / MariaDB. --source include/master-slave.inc   create table t1 (i int ); drop table t1;   --sync_slave_with_master   --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc   STOP SLAVE IO_THREAD; --source include/wait_for_slave_io_to_stop.inc   --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc   START SLAVE IO_THREAD; --source include/wait_for_slave_io_to_start.inc   --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc   --connection master   create table t1 (i int ); drop table t1;   --sync_slave_with_master   --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc   # Cleanup   --connection master --source include/rpl_end.inc output include/master-slave.inc [connection master] create table t1 (i int); drop table t1; connection slave; Seconds_Behind_Master = '0' STOP SLAVE IO_THREAD; include/wait_for_slave_io_to_stop.inc Seconds_Behind_Master = 'NULL' START SLAVE IO_THREAD; include/wait_for_slave_io_to_start.inc Seconds_Behind_Master = '0' connection master; create table t1 (i int); drop table t1; connection slave; Seconds_Behind_Master = '0' connection master; include/rpl_end.inc bug.mdev15010 'mix' [ pass ] 992

Andrei Elkin added a comment - 2018-01-24 08:19 Thanks elenst for bring some background and showing it with a test! Indeed Mariadb behaviour in this regard is like mysql before 5.6.9: NULL is displayed when the IO thread is down, regardless of the SQL thread status. To display a numeric value when the IO thread is down is reasonable, as well to indicate about the reached synchronization with NULL rather than 0 of when the IO thread is up.

Sujatha Sivakumar (Inactive) added a comment - 2019-06-19 15:17 Hello Andrei, Can you please review the fixes for MDEV-15010 . http://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-5.5-sujatha https://github.com/MariaDB/server/commit/fb619954867232b3a733213a2703b2a425dff8e9 Thank you

Brandon Nesterenko added a comment - 2024-07-11 21:11 - edited Hi jeanfrancois.gagne , I think MDEV-33856 (New definition for Seconds_behind_master) should solve this issue, (albeit not in the Seconds_behind_master field, which we are considering deprecating). The IO thread will update Master_last_event_time to be the event timestamp of the last received event from the master, and the value will persist when the IO thread is later stopped (though RESET MASTER will reset it). Similarly, the SQL thread will update Slave_last_event_time to be the event timestamp of the last committed transaction. If you agree that this solves your needs, I'd like to close this issue (as we wouldn't be able to push a fix for it in a GA release anyway, as it may break existing user's scripts). Note that MDEV-33856 debuts in 11.6, which is not quite yet released, but does have a preview release available if you'd like to test it. And also note that MDEV-33856 includes a new way to view the slave status via the INFORMATION_SCHEMA.SLAVE_STATUS table

Jean-François Gagné added a comment - 2024-07-11 21:21 > The current definition of Seconds_Behind_Master is both complex and confusing It was explained to me that this is because InnoDB did not exist when it was 1st introduced. Without transaction, it made sense. > The IO thread will update Master_last_event_time to be the event timestamp of the last received event from the master LGTM... > though RESET MASTER will reset it RESET MASTER ? I would understand RESET SLAVE, but resetting with RESET MASTER does not make sense to me... > the SQL thread will update Slave_last_event_time to be the event timestamp of the last committed transaction LGTM... > I'd like to close this issue Ok for closing and continuing in MDEV-33856 ... > a new way to view the slave status via the INFORMATION_SCHEMA.SLAVE_STATUS Nice ! Thanks for closing the look on this Brandon.

Brandon Nesterenko added a comment - 2024-07-16 13:00 > RESET MASTER ? I would understand RESET SLAVE, but resetting with RESET MASTER does not make sense to me... Ah that was my blunder, I meant slave, thanks for an astute correction! Thanks for the quick response!

Brandon Nesterenko added a comment - 2024-07-16 13:02 Closing this as won't fix because MDEV-33856 (in 11.6) solves the problem better.