You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The vttablet variable --queryserver-config-query-timeout sets a timeout on all statements served in TabletServer/QueryExecutor. It makes sense for most queries to have some reasonable timeouts.
However, for DDL statements this is problematic, and even wrong. Consider the following arguments:
Some DDLs like ALTER TABLE or OPTIMIZE TABLE can runs for hours and days, well beyond any reasonable queryserver-config-query-timeout setting.
Say we do run such a long running DDL. The way the timeout is implemented is like so:
The problem is that KILL QUERY does not work reliably with long running DDLs. The good scenario is that MySQL does rollback the ALTER TABLE statement, but it can and will take a proportionate time to the timeframe the statement ran before beign killed. So from the moment of KILL QUERY it may yet take hours for the original query to return/complete, which leaves the killing code waiting still.
To summarize:
DDLs have very different timeout requirements compared with DML
Timing out a DDL may not work as expected.
In light of that, I'm suggesting DDL should run without timeout at all.
It should go without saying that we advocate the use of Online DDL in vitess.
Use Case(s)
Being able to protect against normal queries unreasonable runtime, while still allowing long running DDLs.
The text was updated successfully, but these errors were encountered:
Feature Description
The
vttablet
variable--queryserver-config-query-timeout
sets a timeout on all statements served inTabletServer
/QueryExecutor
. It makes sense for most queries to have some reasonable timeouts.However, for DDL statements this is problematic, and even wrong. Consider the following arguments:
ALTER TABLE
orOPTIMIZE TABLE
can runs for hours and days, well beyond any reasonablequeryserver-config-query-timeout
setting.Using a
context.WithTimeout
Check for timeout here:
vitess/go/vt/vttablet/tabletserver/connpool/dbconn.go
Lines 188 to 194 in 1ed18d0
Fast forward a few function calls, issue a
kill query
statement here:vitess/go/vt/vttablet/tabletserver/connpool/dbconn.go
Lines 520 to 525 in 1ed18d0
The problem is that
KILL QUERY
does not work reliably with long running DDLs. The good scenario is that MySQL does rollback theALTER TABLE
statement, but it can and will take a proportionate time to the timeframe the statement ran before beign killed. So from the moment ofKILL QUERY
it may yet take hours for the original query to return/complete, which leaves the killing code waiting still.To summarize:
In light of that, I'm suggesting DDL should run without timeout at all.
It should go without saying that we advocate the use of Online DDL in vitess.
Use Case(s)
Being able to protect against normal queries unreasonable runtime, while still allowing long running DDLs.
The text was updated successfully, but these errors were encountered: