Many solutions on this site describe how to debug and fix a lock-wait timeout. They discuss changing innodb_lock_wait_timeout and figuring out the root cause.
The official error code states "try restarting transaction". My question is if I don't restart the transaction, is there any benefit to just retrying the query?
Related
In my project, I'm using innodb storage engine with isolation level READ-COMMITTED.
And Iam having my innodb_lock_wait_timeout as 300s (5 min). For select and update queries, if they waited for lock held by other transactions, after 5 min, I'm getting
"Lock wait timeout..Try restarting Transaction."
But for insert queries (delete query sometimes), even after 5 min I'm not getting lock wait timeout.
Just after 5 min, if I kill those insert query, I get the exception based on connection termination which is expected but in
"show processlist"
the query is marked as killed but the query seems to be remain for more than an hour or two.
Is there any configuration parameters causing this or something else. Googled such problems but can't find the right answer.
FYI:
I'm just inserting 1 row(not bulk insert)which is waiting to acquire lock.
When further digged and debugged, it was found that it was an issue with the mysql version 5.7.18. When updated with 5.7.24 the query waiting for lock can actually throw "lock wait timeout exceeded. Try restarting transaction".
We have a MySQL 5.6 DB server providing service to 10 clients. The clients poll the database server for records to process. We were having intermittent issues where all of the clients would suddenly generate "Lock wait timeout exceeded; try restarting transaction" errors, all of them at the same time. During troubleshooting one of these events we noted that on the server (Windows Server 2008R2) that at the moment the clients generated the error the server time had changed. We took note for the next time.
Today the next time occurred. 9 out of the 10 clients generated the error and sure enough, when we checked the Event Viewer on the server the server time had changed 1 second forward at the exact time the errors were generated.
Can someone explain:
Why this is happening?
Recommend a way to prevent it?
We are already handling deadlock errors and it's actually not clear where in the program this error is coming from. The clients do not poll the server simultaneously but psuedo randomly in approximate 10 second intervals so it's baffling to us that so many would generate the error at the same moment.
Thanks,
Pablo
What may be happening is some thread is holding lock on some record/table (may be an scheduled task is there to take backup of DB which is generating locks) for too long, and your thread is being timed out. As I said in comments please go through innodb status log for more details.
One way to avoid this is if you are using InnoDB storage engine then fine tune your transaction isolation level.
Check transaction isolation level by executing SELECT ##GLOBAL.tx_isolation, ##tx_isolation;
If you see any of these as REPEATABLE READ which is defauld for InnoDB set it to READ COMMITTED using
SET tx_isolation = 'READ-COMMITTED'; and SET GLOBAL tx_isolation = 'READ-COMMITTED';
My application is installed on a client machine which is really really slow.
I'm getting errors like:
"Operation not allowed after ResultSet closed" (which I believe that occured due to timed out connections)
"Lock wait timeout exceeded;
try restarting transaction".
I would like to ensure that all of these errors caused to the slow machine by increasing MySQL timeouts.
My question is - which configurations should I change so that MySQL will be more tolerated to the slow environment.
Thanks
Well, you could try setting your innodb_lock_wait_timeout parameter in your my.ini file to resolve the second problem, but i dont really know how to fix the first one. More on innodb_lock_wait_timeout.
Firstly this isn't a duplicate of this question because I'm not behind a load balancer at the moment. Also randomly restarting the instance isn't a satisfactory solution either.
I moved our store from using a local mysql db on the EC2 to RDS recently and we're getting some errors on the backend when they're moving categories around / adding products. Mostly they look like SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction but I've seen other variations of PDO errors.
How would one go about eliminating these issues?
I've read suggestions to just 'keep retrying' but this seems stupid.
I've tried tinkering with innodb_lock_wait_timeout and others but doesn't seem to resolve it.
I have finally disabled magento logging to the DB - will see if this helps going forward. Unfortunately I have to wait a while to let the staff tinker on the backend and then see if any fix has an effect.
Thanks
UPDATE
Now also seeing a bunch of these
User Error: DDL statements are not allowed in transactions
I'm using SQLyog to sync a production database to a dev db. On 4 tables, I'm getting:
Error No. 1205 Lock wait timeout exceeded; try restarting transaction
Researching the web seems to indicate that a transaction has begun, locked tables, but has not committed. One post said to SHOW PROCESSLIST; but the only processes appear to be my own, via SQLyog.
I have also tried a Restart of MySQL, but that didn't help either.
As a relative novice in MySQL, I'm stuck: I can't determine what transaction or process is locking the tables, nor how to clear this situation.
Any suggestions would be gratefully accepted!
MTIA
Having the same problem on MySQL-cluster, I've solved (at least it looks being solved now - no fail have occured during last two days) it by performing commit/rollback after SELECTs too.
Export and re-import your database; this can often fix a lot of mysterious problems. You can do this through phpMyAdmin or from the command line.
This page at MediaTemple has a good set of instructions:
http://kb.mediatemple.net/questions/129/Export+and+import+MySQL+databases#gs
(Well, it worked for me!)