Percona Toolkit moved to https://jira.percona.com/projects/PT

Bug #1113301
Comment #4

Comment 4 for bug 1113301

Revision history for this message

Daniel Nichter (daniel-nichter) wrote on 2013-02-28:

We decided to remove --lock-wait-timeout and change how --set-vars works because we didn't want to introduce another one-off option (i.e. --innodb-lock-wait-timeout and swap the meaning of the two options to match their corresponding sys var).

--set-vars no longer has a "default: ...", which OptionParser automatically applies to the option if not specified on the command line. We could have done "default: wait_timeout=1000,innodb_lock_wait_timeout=1,lock_wait_timeout=1", but if the user wanted to set another var and did "--set-vars foo=bar", then that would clobber the entire default.

So the tool's defaults for --set-vars are now listed under MAGIC_set_vars, and the tool combines these plus whatever, if anything, the user gives on the command line, the user's vars override any tool defaults. Then it sets these vars one-by-one which is better than previous because "SET foo=1,bar=2" will not set bar if setting foo fails. Now failures are isolated.

Another change: --lock-wait-timeout (which used to set innodb_lock_wait_timeout) was magical to avoid warnings: if it failed to set and the current value was <= the requested value, then there was no warning because, the thinking was, "a lower innodb_lock_wait_timeout is always better". This is no longer the case: the tool always warns if it can't set a var with either the default or user-specified value because the user might want a high value for, say, lock_wait_timeout, so the tool waits awhile for metalocks to be released.

Not favoring smaller lock wait timeout values make more sense in combination with --retires because the user may want to wait awhile but only retry a few times. I.e. to wait for a total of 30s if --retries=3 and <some lock timeout value>=10. But if that lock timeout value was 5 and the tool quietly accepts that as better, then the user only get 15s total of waiting before the tool fails--not what they wanted.

Finally, I chose to warn instead of die on failure to set because usually the vars set just affect the tool's resiliency. So it's important to know that the user didn't get what they wanted, but the tool can still continue and still probably succeed. All the same, if it doesn't, the user may now know why: some vars weren't set like they wanted. Warning rather than dying is also necessary, else pt-osc and pt-table-checksum on MySQL 5.1 would always die failing to set innodb_lock_wait_timeout, and would require a manual set and restart of MySQL--no good.

--set-vars no longer has a "default: ...", which OptionParser automatically applies to the option if not specified on the command line.  We could have done "default: wait_timeout=1000,innodb_lock_wait_timeout=1,lock_wait_timeout=1", but if the user wanted to set another var and did "--set-vars foo=bar", then that would clobber the entire default.

So the tool's defaults for --set-vars are now listed under MAGIC_set_vars, and the tool combines these plus whatever, if anything, the user gives on the command line, the user's vars override any tool defaults.  Then it sets these vars one-by-one which is better than previous because "SET foo=1,bar=2" will not set bar if setting foo fails.  Now failures are isolated.

Another change: --lock-wait-timeout (which used to set innodb_lock_wait_timeout) was magical to avoid warnings: if it failed to set and the current value was <= the requested value, then there was no warning because, the thinking was, "a lower innodb_lock_wait_timeout is always better".  This is no longer the case: the tool always warns if it can't set a var with either the default or user-specified value because the user might want a high value for, say, lock_wait_timeout, so the tool waits awhile for metalocks to be released.

Not favoring smaller lock wait timeout values make more sense in combination with --retires because the user may want to wait awhile but only retry a few times.  I.e. to wait for a total of 30s if --retries=3 and <some lock timeout value>=10.  But if that lock timeout value was 5 and the tool quietly accepts that as better, then the user only get 15s total of waiting before the tool fails--not what they wanted.

Finally, I chose to warn instead of die on failure to set because usually the vars set just affect the tool's resiliency.  So it's important to know that the user didn't get what they wanted, but the tool can still continue and still probably succeed.  All the same, if it doesn't, the user may now know why: some vars weren't set like they wanted.  Warning rather than dying is also necessary, else pt-osc and pt-table-checksum on MySQL 5.1 would always die failing to set innodb_lock_wait_timeout, and would require a manual set and restart of MySQL--no good.