Support #1564
closedmysql 5.5 metadata lock
0%
Description
From Tom Dolafi:
In 5.5 we experience waits on metadata locks. It appears that running the microscope runs ddl statements "CREATE TABLE IF NOT EXISTS". Is there a way to turn ddl verification off? As described below, in 5.5 locks last the entire session and not per statement as is in 5.1.
Mysql session:
123456 | user | xxxxxx.xxx.org:56789 | dbemdata | Query | 55 | Waiting for table metadata lock | CREATE TABLE IF NOT EXISTS `dbemdata`.`SessionData` (`DEF_id` int(16) NOT NULL AUTO_INCREMENT, `DEF_timestamp` timestamp NOT NULL, `name` TEXT NULL, `REF|UserData|user` INT NULL DEFAULT NULL, `image path` TEXT NULL, `comment` TEXT NULL, `REF|GridHolderData|holder` INT NULL DEFAULT NULL, PRIMARY KEY (`DEF_id`), KEY `DEF_timestamp` (`DEF_timestamp`), KEY `REF|UserData|user` (`REF|UserData|user`), KEY `REF|GridHolderData|holder` (`REF|GridHolderData|holder`)) ENGINE=MyISAM |
Reference in mysql server:
http://dev.mysql.com/doc/refman/5.5/en/metadata-locking.html
As of MySQL 5.5.3, the server achieves this by acquiring metadata locks on tables used within a transaction and deferring release of those locks until the transaction ends.
…..
Before MySQL 5.5.3, when a transaction acquired a metadata lock for a table used within a statement, it released the lock at the end of the statement.
Thanks,
Tom
I asked what was the reason for the upgrade, and here is his answer:
My motivation to upgrade versions was based on Oracle's support structure. Oracle stopped 5.0 development July 2011, and announced End-Of-Life support Jan 2012. I suspect we will see the same with 5.1 this year. Oracle is pushing 5.5, and has started the releases of 5.6. At some point we will need the capability to migrate to a supported version of mysql. Resolving the metadata lock is a first step. On our next attempt to upgrade we will need more testing time to ensure everything behaves appropriately.
Updated by Anchi Cheng over 12 years ago
- Status changed from Assigned to New
- Assignee deleted (
Anchi Cheng)
Since I have no idea how to solve this now, I leave it unassigned. If you have any idea, please take it on.
Updated by Anchi Cheng over 12 years ago
Second inquiry about mysql 5.5 from Tom Houweling.
He made the following comment for our consideration:
I see, considering the need for some rewriting of the python code, it would make sense dropping mysql in favor of (the more advanced) postgresql.
Updated by Anchi Cheng about 12 years ago
Jim found out that mysql 5.5.5 uses INNODB as default storage engine instead of MyISAM that is used in the older versions.
Setting default-storage-engine to myisam therefore solve this issue.
See Database installation/setup Instruction for myami on Ubuntu
Updated by Anonymous almost 12 years ago
I see... There is another good argument for using InnoDB over MyISAM, in that InnoDB is safer and easier to create backups from. Ending a transaction in python MySQLdb should have a db.commit() following any sql statement, especially inserts, updates and removes... would that be an easy fix? Is there a good fast test case for this problem? Probably not worth it right now, but one day MyISAM itself might go away....
Updated by Sargis Dallakyan almost 7 years ago
- Status changed from New to Closed