-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: The Transaction Throttler can throttle writes outside of BEGIN/COMMIT #13037
Comments
Does this change impact the begin throttler to throttle on query than on begin? |
For Autocommit mode we have a separate execution plan, we can add a throttler check over there. |
Currently, throttling does not actually take place when the client submits |
I will follow your advice in #13040 and move the call to |
This change is moving the throttling from transaction creation to query execution. This could possibly lead to a connection to be open and not do anything meaningful to until get rolled back by transaction killer on a transaction timeout. The reason throttling was done at transaction creation is that the transaction does not open for a long time and if they do get open should be allowed to proceed further and eventually, a commit happens. With this change, the connections will get blocked to eventually get throttled and rolled back by transaction killer. I would suggest for this feature to allow read query to pass in the transaction, start the transaction with |
If I understand this correctly, you mean to have the throttler decide whether to throttle or not based on whether the current Tx is started as |
My whole idea is if the connection is taken from the pool, we are not preventing much but just blocking the connection. This transaction is held which means locks held and any read query on those rows are anyways not available - which lead to lock wait timeouts. I think better to throttle on begin+query time. There is no real benefit of throttling later, it can lead to more deadlocks/wait timeouts in MySQL. Another way of thinking. begin + select - no throttle does the application achieve what it wants after reading the record? I believe not. So, still is problematic and does not solve a real case. if the application executes with select for update the rows are anyways locked to be read by any other connection. The best way is for the application to tell that they do not want throttling to be effective. I believe this was the same reason |
While I understand your concern, I am afraid that expecting the application to be changed in every code path that issues a query is not feasible; I can't speak for other Vitess customers, but for us, there are simply too many - and on top of that, it also involves changing how every dev adds new queries to the codebase when adding or modifying features. I would propose then doing something different:
What do you think? |
Sounds good to me. |
OK, I will proceed as described above |
It looks like the call to
lands there instead of in |
Feature Description
Currently, the
TxThrottler
can trigger throttling only for queries that are inside aBEGIN/COMMIT
block if it considers that the query rate is too high to maintain replication lag within acceptable parameters.This feature request is about making the
TxThrottler
smarter so that it can throttle without the need for explicitBEGIN/COMMIT
commands from the client.Use Case(s)
Plenty of apps may not open explicit transactions with
BEGIN/COMMIT
, thus making the current transaction throttler unsuitable for them. With this request, such apps could benefit from theTxThrottler
without having to be modified.The text was updated successfully, but these errors were encountered: