[utils][proxysql] Set query_retries_on_failure to 1 explicitly #7238
Conversation
s10
requested review from
fwiesel,
notandy,
galkindmitrii,
Carthaca and
joker-at-work
as code owners
|
I am not sure, if we can enable that feature without risk. |
s10
force-pushed
the
C5384329/utils-query-retries
branch
from
765cf01
to
343e7b6
Compare
s10
changed the title
Default value is 1, but sometimes we might want more retries instead of 500
This could be done for SELECT queries by configuration:
proxysql:
query_rules:
retries_on_select: 10
s10
force-pushed
the
C5384329/utils-query-retries
branch
from
343e7b6
to
9505dc7
Compare
| @@ -42,6 +42,7 @@ mysql_variables = | |||
| connect_retries_on_failure = {{ default 1000 .global.Values.proxysql.connect_retries_on_failure }} | |||
| connect_retries_delay = {{ default 100 .global.Values.proxysql.connect_retries_delay }} {{- /* The default is 1ms, and that means we will run through the retries on failure in no time */}} | |||
| connect_timeout_server_max = {{ default 100000 .global.Values.proxysql.connect_timeout_server_max }} | |||
| query_retries_on_failure = {{ default 1 .global.Values.proxysql.query_retries_on_failure }} {{- /* The ProxySQL default is 1, and that means queries are being retried once */}} | |||
There was a problem hiding this comment.
Based on the documentation this is not limited to read only queries and bigger result sets can cause errors. There is also a related issue from 2017 still open. We should check if we can tweak the pxc-db HAProxy setup before we change this setting.
| active = 1, | ||
| apply = 1, | ||
| retries = {{ default 10 .global.Values.proxysql.query_rules.retries_on_select }}, | ||
| match_digest = "^SELECT", |
There was a problem hiding this comment.
With SELECT FOR UPDATE this can be a DML command and than the retries can be risky if something has been changed in between, or?
There was a problem hiding this comment.
My assumption was, that retries are only done, if it isn't within a transaction. SELECT FOR UPDATE only creates a lock within a transaction.
I've checked the code, and it looks to me, my assumption is correct.
A retry of a single statement from an aborted transaction wouldn't make sense.
Default value is 1, but sometimes we might want more retries instead of 500
This could be done for SELECT queries by configuration: