Showing entries 1 to 6
Displaying posts with tag: metadata lock (reset)
Quickly Troubleshoot Metadata Locks in MySQL 5.7

In a previous article, Ovais demonstrated how a DDL can render a table blocked from new queries. In another article, Valerii introduced performance_schema.metadata_locks, which is available in MySQL 5.7 and exposes metadata lock details. Given this information, here’s a quick way to troubleshoot metadata locks by creating a stored procedure that can:

  • Find out which thread(s) have the metadata lock
  • Determine which thread has been waiting for it the longest
  • Find other threads waiting for the metadata lock

Setting up …

[Read more]
More on (transactional) MySQL metadata locks

Two years ago Ovais Tariq had explained in detail what kinds of problems existed before MySQL introduced metadata locks in 5.5.3 and how these locks help to prevent them. Still, some implications of metadata locking in MySQL remain unclear for users – DBAs and even software developers that target recent MySQL versions. I’ve decided to include a slide or two into the presentation about InnoDB locks and deadlocks I plan to make (with my colleague Nilnandan Joshi) on April 16 at Percona Live 2015.

I decided to do this as …

[Read more]
Tracking Metadata Locks (MDL) in MariaDB 10.0

I recently blogged about tracking metadata locks in the latest MySQL, and now I want to discuss how to track these metadata locks in MariaDB.

In MySQL 5.7, there is a table named `metadata_locks` added to the performance_schema (performance_schema must be enabled *and* the metadata_locks instrument must be specifically enabled as well.

In the MariaDB 10.0 implementation (as of 10.0.7), there is a table named METADATA_LOCK_INFO added to the *information_schema*. This is a new plugin, so the plugin must be installed, but that is very simple with:

INSTALL SONAME 'metadata_lock_info';

Then, you will have the table.

To see it in action:

Connection #1:

mysql> create table t (id int) engine=myisam;
mysql> begin;
mysql> select * from t;

Connection #2:

mysql> alter table t add index …
[Read more]
Tracking Metadata Locks (MDL) in MySQL 5.7

I’ve blogged about metadata locks (MDL) in the past (1 2 3) and in particular discussed how best to track them down and troubleshoot threads stuck waiting on metadata locks.

If you’ve had any experience with these, you’ll know finding them isn’t always the most straight-forward task.

So I was glad to see metadata lock instrumentation added to MySQL 5.7.3 as part of performance_schema, which makes tracking these down a breeze! (Note this is only in 5.7.3 currently, and therefore is some time from being GA as of today)!

To use these, performance_schema must be enabled (i.e., performance_schema=1 in your config file).

But, also, the metadata_locks instrument is disabled by default, so even if you enable the …

[Read more]
Troubleshooting MySQL Crashes related to Metadata Locking

I just wrote an article about “Troubleshooting ‘Waiting for table metadata lock’ Errors for both MyISAM and InnoDB Tables” and then ran into a new, different metadata locking issue right after I posted it, and so I thought I’d share that too, just in case anyone ever encounters a similar situation.

In this case, mysqld kept crashing on restart, reporting “out of memory” errors:

/opt/app/mysql/product/mysql/bin//mysqld: Out of memory (Needed 840 bytes)
stack_bottom = 7fb4ebaeae58 thread_stack 0x40000
mysqld: /mysql/mysys/my_new.cc:52: int __cxa_pure_virtual():
  Assertion `! "Aborted: pure virtual method called."' failed.
mysqld: /mysql/mysys/my_new.cc:52: int __cxa_pure_virtual():
  Assertion `! "Aborted: pure virtual method called."' failed.
Fatal signal 6 while backtracing

There is a …

[Read more]
Troubleshooting “Waiting for table metadata lock” Errors for both MyISAM and InnoDB Tables

With the introduction of metadata locking in MySQL 5.5, it is much more common to see queries stuck in the “Waiting for table metadata lock” state.

If you see a query stuck in the “Waiting for table metadata lock” state, waiting for a MyISAM table, then it is because this table has been included as part of some uncommitted transaction (whether intentionally or not).

In fact, it could be as simple as issuing SET AUTOCOMMIT=0 followed by a SELECT against a MyISAM table (a transaction can be started 3 ways: START TRANSACTION, BEGIN, and SET AUTOCOMMIT=0). After that, the table will be locked to other DDL statements until the transaction is committed (or ended).

This metadata lock is meant for DDL statements, and so that is what it blocks. However, once a DDL statement is blocked and waiting, then all queries …

[Read more]
Showing entries 1 to 6