Currently execution time for the replicated query is not limited in any clear way. On primary node we can use max_statement_time, but this value is neither passed to slave nor enforced for SQL thread when it's set locally. So, there is no way to "control" replication delay and just stop with error when it's too big already.
I think option to stop with error after specific timeout (that may be different than local max_statement_time or primary's max_statement_time) would be useful for replication setups.
Slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do). Whether that's designed on purpose (doubts) or is actually buggy remains to be seen.
Should there be no such effect the requested functionally could be provided without any new option.
To add more, init-slave is around to fine tune slave appliers so @@SESSION level setting
like this one could be technically done though that.
Andrei Elkin
added a comment - - edited Slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do). Whether that's designed on purpose (doubts) or is actually buggy remains to be seen.
Should there be no such effect the requested functionally could be provided without any new option.
To add more, init-slave is around to fine tune slave appliers so @@SESSION level setting
like this one could be technically done though that.
What do you mean "slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do)" ? Every THD gets max_statement_time, slave thread too. It's copied from global in plugin_thdvar_init() which is called from THD::init(). What slave threads don't do — they don't set the query timer to expire after max_statement_time seconds. In THD::set_query_timer() slave threads are explicitly excluded. This looks very much like on purpose, one can hardly write slave_thread || unintentionally.
Sergei Golubchik
added a comment - What do you mean "slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do)" ? Every THD gets max_statement_time , slave thread too. It's copied from global in plugin_thdvar_init() which is called from THD::init() . What slave threads don't do — they don't set the query timer to expire after max_statement_time seconds. In THD::set_query_timer() slave threads are explicitly excluded. This looks very much like on purpose, one can hardly write slave_thread || unintentionally.
I don't think it's a good idea. If the slave thread would always be using global.max_statement_time — that's one thing. But if you're adding an option anyway, better to have an option like --slave-max-statement-time and not --slave-uses-global-max-statement-time
Sergei Golubchik
added a comment - I don't think it's a good idea. If the slave thread would always be using global.max_statement_time — that's one thing. But if you're adding an option anyway, better to have an option like --slave-max-statement-time and not --slave-uses-global-max-statement-time
Currently execution time for the replicated query is not limited in any clear way. On primary node we can use max_statement_time, but this value is neither passed to slave nor enforced for SQL thread when it's set locally. So, there is no way to "control" replication delay and just stop with error when it's too big already.
I think option to stop with error after specific timeout (that may be different than local max_statement_time or primary's max_statement_time) would be useful for replication setups.
Currently execution time for the replicated query is not limited in any clear way. On primary node we can use max_statement_time, but this value is neither passed to slave nor enforced for SQL thread when it's set locally. So, there is no way to "control" replication delay and just stop with error when it's too big already.
I think option to stop with error after specific timeout (that may be different than local max_statement_time or primary's max_statement_time) would be useful for replication setups.
The adopted solution was to add a new variable, Slave_max_statement_time, which can be
used to limit the time that slave is going to wait for a query to be executed.
The slave will no honor max_statement_time.
Michael Widenius
added a comment - The adopted solution was to add a new variable, Slave_max_statement_time, which can be
used to limit the time that slave is going to wait for a query to be executed.
The slave will no honor max_statement_time.
Task
Critical
Slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do). Whether that's designed on purpose (doubts) or is actually buggy remains to be seen.
Should there be no such effect the requested functionally could be provided without any new option.
To add more, init-slave is around to fine tune slave appliers so @@SESSION level setting
like this one could be technically done though that.