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';
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".
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
Recently I noticed below error in slave server errorlogs in Master Slave replication. Even there is no issue in replication and slave is on time as per master. Actually I executed some heavy reporting queries on slave and inserted their results in temp/dummy (not temporary table) table. I need community help to clear my below 2 queries. I will be very thankful if anyone help me in this.
[ERROR] Slave SQL: Could not execute Update_rows event on table DBname.tablename; Lock wait timeout exceeded; try restarting transaction,
Error_code: 1205; handler error HA_ERR_LOCK_WAIT_TIMEOUT; the event's master log mysql-bin.******, end_log_pos *******, Error_code: 1205
As per my understanding this error occur when I was fetching report (fetching from production tables and inserting in dummy table) because mysql could not get lock and as lock will be available for mysql the update statement will be executed successfully means my data will be up to date on slave.
As we know that select statement does not lock the table, so it will be happen because I was simultanously inserting data into another table along with fetching data from production table.
Thanks in advance.
Running a query on the slave does set implicit locks on the underlying tables for as long as the query runs. Concurrent queries coming from the master had to be put on hold in the mean time. As your query presumably lasted for longer than (or close to) innodb_lock_wait_timeout, replication timed out.
When this happens, all you need to do is restarting replication with a simple START SLAVE;.
To avoid the issue altogether, you can explicitely pause replication (STOP SLAVE) before running your reporting queries, then resume replication after you are done.
As a workaround, you could also increase slave_transaction_retries.
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!)
I have two servers configured in a master-master pair using MMM. I recently had an issue where the passive master received a replication error (got a packet bigger than max_allowed_packet) but the slave IO and SQL threads continued running. And seconds_behind_master was still showing as 0 even though the slave was not executing new statements.
I thought this type of error would cause replication to stop (it's done this in the past). Instead replication kept running and our monitors didn't notice the problem. Also the replication errors continually showed up in the mysql error log, instead of "Last_Error" in "show slave status".
We are running version 5.0.33.
Any ideas what happened here? thanks!
For the max allowed packet size, it sounds like your two DBs are not configured identically. At least the network protocol stuff should be identical.
Did you try show slave status on both machines?
Quiet failure is a terrible situation. I wonder what records did not make it. Do you have a way of finding out?
Are you getting periodic errors in the error log or a flood of identical errors? Is the sequence number incrementing on the passive master?
Jacob