MySQL 5.7 stuck forever “waiting for table level lock”
I have a webserver with a MySQL database. It holds several databases serving my various projects. Since Upgrading Ubuntu to 16.04 it has given me a lot of trouble in general. This question specifically is about a situation that a table is locked with a table level lock with no obvious reason why the lock is not removed quickly.
I have a lot of stuck queries like so:
581723 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21601'
581724 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21592'
581725 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21602'
581726 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21596'
581729 algebrainc_ro localhost algebrainc Query 10306 Waiting for table level lock SELECT inventory_id, ebay_title FROM inventory WHERE ebay_id = '32999992936'
581730 algebrainc localhost algebrainc Query 10282 Waiting for table level lock SELECT n complete_status status,n ebay_transactions.inventory_id,n ebay_transactions.ebay_id, n quantity, purchase_price, n ebay_title nFROM ebay_transactions, inventory nWHERE n ebay_transactions.inventory_id = inventory.inventory_id n AND created_date > date_add( now(), interval -7 day )nORDER BY n created_date
After a while of poking around and looking for nothing in performance_schema
such as table_handles
and metadata_locks
, I did not find much.
After a while I realized that it happens because of mysqldump
processes that I do periodically to dump one particular table. I had a dozen stuck mysqldump
processes (called by cron) like these:
ichudov 1178 0.0 0.0 29004 3248 pts/46 Ss+ 20:24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 1394 0.0 0.0 29004 900 pts/26 Ss+ Jun23 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 2537 0.0 0.0 29004 920 pts/22 Ss+ Jun24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
(table name masked for privacy)
After killing mysqldump
processes, table locks were removed and everything went back to normal.
But why do mysqldump
processes lock things up and do not work?
mysql
add a comment |
I have a webserver with a MySQL database. It holds several databases serving my various projects. Since Upgrading Ubuntu to 16.04 it has given me a lot of trouble in general. This question specifically is about a situation that a table is locked with a table level lock with no obvious reason why the lock is not removed quickly.
I have a lot of stuck queries like so:
581723 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21601'
581724 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21592'
581725 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21602'
581726 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21596'
581729 algebrainc_ro localhost algebrainc Query 10306 Waiting for table level lock SELECT inventory_id, ebay_title FROM inventory WHERE ebay_id = '32999992936'
581730 algebrainc localhost algebrainc Query 10282 Waiting for table level lock SELECT n complete_status status,n ebay_transactions.inventory_id,n ebay_transactions.ebay_id, n quantity, purchase_price, n ebay_title nFROM ebay_transactions, inventory nWHERE n ebay_transactions.inventory_id = inventory.inventory_id n AND created_date > date_add( now(), interval -7 day )nORDER BY n created_date
After a while of poking around and looking for nothing in performance_schema
such as table_handles
and metadata_locks
, I did not find much.
After a while I realized that it happens because of mysqldump
processes that I do periodically to dump one particular table. I had a dozen stuck mysqldump
processes (called by cron) like these:
ichudov 1178 0.0 0.0 29004 3248 pts/46 Ss+ 20:24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 1394 0.0 0.0 29004 900 pts/26 Ss+ Jun23 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 2537 0.0 0.0 29004 920 pts/22 Ss+ Jun24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
(table name masked for privacy)
After killing mysqldump
processes, table locks were removed and everything went back to normal.
But why do mysqldump
processes lock things up and do not work?
mysql
What are the sizes of these databases and the tables? Have you done something as simple as running a MySQL dump of all the databases, deleting them from your MySQL server and then importing them again to see of that clears things up?
– JakeGould
Jun 26 '16 at 4:41
Is the inventory table InnoDB or MyISAM?
– Michael - sqlbot
Jun 26 '16 at 14:15
Igor - how did u work this out?
– OhadR
May 31 '17 at 18:25
add a comment |
I have a webserver with a MySQL database. It holds several databases serving my various projects. Since Upgrading Ubuntu to 16.04 it has given me a lot of trouble in general. This question specifically is about a situation that a table is locked with a table level lock with no obvious reason why the lock is not removed quickly.
I have a lot of stuck queries like so:
581723 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21601'
581724 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21592'
581725 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21602'
581726 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21596'
581729 algebrainc_ro localhost algebrainc Query 10306 Waiting for table level lock SELECT inventory_id, ebay_title FROM inventory WHERE ebay_id = '32999992936'
581730 algebrainc localhost algebrainc Query 10282 Waiting for table level lock SELECT n complete_status status,n ebay_transactions.inventory_id,n ebay_transactions.ebay_id, n quantity, purchase_price, n ebay_title nFROM ebay_transactions, inventory nWHERE n ebay_transactions.inventory_id = inventory.inventory_id n AND created_date > date_add( now(), interval -7 day )nORDER BY n created_date
After a while of poking around and looking for nothing in performance_schema
such as table_handles
and metadata_locks
, I did not find much.
After a while I realized that it happens because of mysqldump
processes that I do periodically to dump one particular table. I had a dozen stuck mysqldump
processes (called by cron) like these:
ichudov 1178 0.0 0.0 29004 3248 pts/46 Ss+ 20:24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 1394 0.0 0.0 29004 900 pts/26 Ss+ Jun23 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 2537 0.0 0.0 29004 920 pts/22 Ss+ Jun24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
(table name masked for privacy)
After killing mysqldump
processes, table locks were removed and everything went back to normal.
But why do mysqldump
processes lock things up and do not work?
mysql
I have a webserver with a MySQL database. It holds several databases serving my various projects. Since Upgrading Ubuntu to 16.04 it has given me a lot of trouble in general. This question specifically is about a situation that a table is locked with a table level lock with no obvious reason why the lock is not removed quickly.
I have a lot of stuck queries like so:
581723 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21601'
581724 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21592'
581725 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21602'
581726 algebrainc_ro localhost algebrainc Query 10309 Waiting for table level lock SELECTn *nFROM inventorynWHERE inventory_id = '21596'
581729 algebrainc_ro localhost algebrainc Query 10306 Waiting for table level lock SELECT inventory_id, ebay_title FROM inventory WHERE ebay_id = '32999992936'
581730 algebrainc localhost algebrainc Query 10282 Waiting for table level lock SELECT n complete_status status,n ebay_transactions.inventory_id,n ebay_transactions.ebay_id, n quantity, purchase_price, n ebay_title nFROM ebay_transactions, inventory nWHERE n ebay_transactions.inventory_id = inventory.inventory_id n AND created_date > date_add( now(), interval -7 day )nORDER BY n created_date
After a while of poking around and looking for nothing in performance_schema
such as table_handles
and metadata_locks
, I did not find much.
After a while I realized that it happens because of mysqldump
processes that I do periodically to dump one particular table. I had a dozen stuck mysqldump
processes (called by cron) like these:
ichudov 1178 0.0 0.0 29004 3248 pts/46 Ss+ 20:24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 1394 0.0 0.0 29004 900 pts/26 Ss+ Jun23 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
ichudov 2537 0.0 0.0 29004 920 pts/22 Ss+ Jun24 0:00 mysqldump -ualgebrainc -px xxxxxxxx algebrainc XXXXXXXX_posts
(table name masked for privacy)
After killing mysqldump
processes, table locks were removed and everything went back to normal.
But why do mysqldump
processes lock things up and do not work?
mysql
mysql
edited Jun 26 '16 at 4:40
JakeGould
32.2k1098141
32.2k1098141
asked Jun 26 '16 at 4:25
Igor ChudovIgor Chudov
10137
10137
What are the sizes of these databases and the tables? Have you done something as simple as running a MySQL dump of all the databases, deleting them from your MySQL server and then importing them again to see of that clears things up?
– JakeGould
Jun 26 '16 at 4:41
Is the inventory table InnoDB or MyISAM?
– Michael - sqlbot
Jun 26 '16 at 14:15
Igor - how did u work this out?
– OhadR
May 31 '17 at 18:25
add a comment |
What are the sizes of these databases and the tables? Have you done something as simple as running a MySQL dump of all the databases, deleting them from your MySQL server and then importing them again to see of that clears things up?
– JakeGould
Jun 26 '16 at 4:41
Is the inventory table InnoDB or MyISAM?
– Michael - sqlbot
Jun 26 '16 at 14:15
Igor - how did u work this out?
– OhadR
May 31 '17 at 18:25
What are the sizes of these databases and the tables? Have you done something as simple as running a MySQL dump of all the databases, deleting them from your MySQL server and then importing them again to see of that clears things up?
– JakeGould
Jun 26 '16 at 4:41
What are the sizes of these databases and the tables? Have you done something as simple as running a MySQL dump of all the databases, deleting them from your MySQL server and then importing them again to see of that clears things up?
– JakeGould
Jun 26 '16 at 4:41
Is the inventory table InnoDB or MyISAM?
– Michael - sqlbot
Jun 26 '16 at 14:15
Is the inventory table InnoDB or MyISAM?
– Michael - sqlbot
Jun 26 '16 at 14:15
Igor - how did u work this out?
– OhadR
May 31 '17 at 18:25
Igor - how did u work this out?
– OhadR
May 31 '17 at 18:25
add a comment |
1 Answer
1
active
oldest
votes
Cause: table level lock during mysqldump which is the reason for slowness since the table is using MyISAM engine
Resolution: Convert MyISAM to Innodb, for row level locking,
ALTER TABLE 'table_name' ENGINE=INNODB;
Refer: myisam lock during mysqldump
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1093610%2fmysql-5-7-stuck-forever-waiting-for-table-level-lock%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Cause: table level lock during mysqldump which is the reason for slowness since the table is using MyISAM engine
Resolution: Convert MyISAM to Innodb, for row level locking,
ALTER TABLE 'table_name' ENGINE=INNODB;
Refer: myisam lock during mysqldump
add a comment |
Cause: table level lock during mysqldump which is the reason for slowness since the table is using MyISAM engine
Resolution: Convert MyISAM to Innodb, for row level locking,
ALTER TABLE 'table_name' ENGINE=INNODB;
Refer: myisam lock during mysqldump
add a comment |
Cause: table level lock during mysqldump which is the reason for slowness since the table is using MyISAM engine
Resolution: Convert MyISAM to Innodb, for row level locking,
ALTER TABLE 'table_name' ENGINE=INNODB;
Refer: myisam lock during mysqldump
Cause: table level lock during mysqldump which is the reason for slowness since the table is using MyISAM engine
Resolution: Convert MyISAM to Innodb, for row level locking,
ALTER TABLE 'table_name' ENGINE=INNODB;
Refer: myisam lock during mysqldump
edited Feb 13 at 12:21
answered Aug 2 '16 at 5:31
Infra DBAInfra DBA
1635
1635
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1093610%2fmysql-5-7-stuck-forever-waiting-for-table-level-lock%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What are the sizes of these databases and the tables? Have you done something as simple as running a MySQL dump of all the databases, deleting them from your MySQL server and then importing them again to see of that clears things up?
– JakeGould
Jun 26 '16 at 4:41
Is the inventory table InnoDB or MyISAM?
– Michael - sqlbot
Jun 26 '16 at 14:15
Igor - how did u work this out?
– OhadR
May 31 '17 at 18:25