I'm new to MySQL database and got some issue with table lock/deadlock. We are running a system with a heavy transactions run everyday and sometime deadlock happened. I would like to know what happened to the transactions if they exceeded wait timeout. Are they canceled (roll-back) ? Do we need to manually run the transaction again or did application auto retry the transaction after deadlock is resolved?
I'm using MySQL 5.7 with Innodb engine.
Thanks
it dosen't matter what db you are using ,if you are using a transaction it will only be committed on success ie if u look closely there is a commit transaction command at the end of try which u write , unless that line is invoked No changes to the DB will be made hence you can be assured that it will be roll backed at the situation of timeout error
Related
We're using Rails v6.0.2.1 on Jruby with managed PostgreSQL (using JDBC adapter) hosted on DigitalOcean. Lately, we have been seeing issues where a certain transaction created some record, threw the Id to Sidekiq for further processing but the record isn't there in the database and Sidekiq fails since the record is not found in db.
There are some Concurrent::Future calls as well inside the transaction. DigitalOcean doesn't show any deadlocks in the said time period. And currently, DO doesn't provide a dump of PostgreSQL logs. How do we debug this?
While looking at Rails production logs, we found out that those transactions didn't log any BEGIN...COMMIT OR ROLLBACK message either.
you might have been using after_save callback on your models I assume? anyway, the issue is that Sidekiq is fast. Sometimes, too fast.
What is happening is that Sidekiq is picking up the job before the transaction is committed. That will trigger the error you are seeing (e.g. RecordNotFound).
You have two solutions: simply retry the job, on a second pass, the record would most likely be in the database again or you can go move to after_commit callback and these errors will disappear.
This issue was discussed here in the past
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';
I've moved to mysql from sqlite and funny issue - whenever I mass-delete objects via django admin (about 100 or so) I get this mysql error:
(1205, 'Lock wait timeout exceeded; try restarting transaction')
this has never happened with sqlite with the same models.
I am able to delete a max of two records, three are failing.
The setup is windows7, mysql 5.5.20, python 2.7, django 1.3
That error is directly from MySQL. It happens when there's a lock created on the table and it isn't released for whatever reason. You can try restarting your MySQL server. That might be enough to clear things up and allow you to proceed. You can also edit your my.conf file (not sure of its location in Windows, but should be with the rest of your MySQL stuff) and change the following line to a longer time period (number is seconds):
innodb_lock_wait_timeout = 50
Turns out there may be many causes to this issue. My case was caused by indexes mixing up somehow - I was only able to fix this by recreating the database and importing data.
in general
show status
show engine innodb status
explain <select causing issues>
may give some hints.
My question baliscally is: if the sytem crashes right when a mysql transaction is executed, will the transaction rollback after system restart?
How are the transactions executed by mysql?
Will MySQL check for unfinished transactions after restart?
I'm asking this because I made a transaction system in php, but I'm not storing the final results anywhere for a future rollback in case of a system crash...
There are different kind of crashes. The MySQL server can crash (like if you kill it) or the whole Operating system can crash (like if you unplug the machine).
Where you should start reading is about the Binary Log and how it works and about the Recovery process for InnoDB engine
Yes definitely you can roll back. Refer the DOC for more details
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!)