Is there any way to select / show all current locks that have been taken out using the GET_LOCK function?
Note that GET_LOCK locks are different from table locks, like those acquired with LOCK TABLES - readers who want to know how to see those locks should read Detecting locked tables (locked by LOCK TABLE)
From MySQL 5.7 onwards, this is possible, but requires first enabling the mdl instrument in the performance_schema.setup_instruments table. You can do this temporarily (until the server is next restarted) by running:
UPDATE performance_schema.setup_instruments
SET enabled = 'YES'
WHERE name = 'wait/lock/metadata/sql/mdl';
Or permanently, by adding the following incantation to the [mysqld] section of your my.cnf file (or whatever config files MySQL reads from on your installation):
[mysqld]
performance_schema_instrument = 'wait/lock/metadata/sql/mdl=ON'
(Naturally, MySQL will need to be restarted to make the config change take effect if you take the latter approach.)
Locks you take out after the mdl instrument has been enabled can be seen by running a SELECT against the performance_schema.metadata_locks table. As noted in the docs, GET_LOCK locks have an OBJECT_TYPE of 'USER LEVEL LOCK', so we can filter our query down to them with a WHERE clause:
mysql> SELECT GET_LOCK('foobarbaz', -1);
+---------------------------+
| GET_LOCK('foobarbaz', -1) |
+---------------------------+
| 1 |
+---------------------------+
1 row in set (0.00 sec)
mysql> SELECT * FROM performance_schema.metadata_locks
-> WHERE OBJECT_TYPE='USER LEVEL LOCK'
-> \G
*************************** 1. row ***************************
OBJECT_TYPE: USER LEVEL LOCK
OBJECT_SCHEMA: NULL
OBJECT_NAME: foobarbaz
OBJECT_INSTANCE_BEGIN: 139872119610944
LOCK_TYPE: EXCLUSIVE
LOCK_DURATION: EXPLICIT
LOCK_STATUS: GRANTED
SOURCE: item_func.cc:5482
OWNER_THREAD_ID: 35
OWNER_EVENT_ID: 3
1 row in set (0.00 sec)
mysql>
The meanings of the columns in this result are mostly adequately documented at https://dev.mysql.com/doc/refman/en/metadata-locks-table.html, but one point of confusion is worth noting: the OWNER_THREAD_ID column does not contain the connection ID (like would be shown in the PROCESSLIST or returned by CONNECTION_ID()) of the thread that holds the lock. Confusingly, the term "thread ID" is sometimes used as a synonym of "connection ID" in the MySQL documentation, but this is not one of those times. If you want to determine the connection ID of the connection that holds a lock (for instance, in order to kill that connection with KILL), you'll need to look up the PROCESSLIST_ID that corresponds to the THREAD_ID in the performance_schema.threads table. For instance, to kill the connection that was holding my lock above...
mysql> SELECT OWNER_THREAD_ID FROM performance_schema.metadata_locks
-> WHERE OBJECT_TYPE='USER LEVEL LOCK'
-> AND OBJECT_NAME='foobarbaz';
+-----------------+
| OWNER_THREAD_ID |
+-----------------+
| 35 |
+-----------------+
1 row in set (0.00 sec)
mysql> SELECT PROCESSLIST_ID FROM performance_schema.threads
-> WHERE THREAD_ID=35;
+----------------+
| PROCESSLIST_ID |
+----------------+
| 10 |
+----------------+
1 row in set (0.00 sec)
mysql> KILL 10;
Query OK, 0 rows affected (0.00 sec)
Starting with MySQL 5.7, the performance schema exposes all metadata locks, including locks related to the GET_LOCK() function.
See http://dev.mysql.com/doc/refman/5.7/en/metadata-locks-table.html
SHOW FULL PROCESSLIST;
You will see the locks in there
If you just want to determine whether a particular named lock is currently held, you can use IS_USED_LOCK:
SELECT IS_USED_LOCK('foobar');
If some connection holds the lock, that connection's ID will be returned; otherwise, the result is NULL.
Reference taken from this post:
You can also use this script to find lock in MySQL.
SELECT
pl.id
,pl.user
,pl.state
,it.trx_id
,it.trx_mysql_thread_id
,it.trx_query AS query
,it.trx_id AS blocking_trx_id
,it.trx_mysql_thread_id AS blocking_thread
,it.trx_query AS blocking_query
FROM information_schema.processlist AS pl
INNER JOIN information_schema.innodb_trx AS it
ON pl.id = it.trx_mysql_thread_id
INNER JOIN information_schema.innodb_lock_waits AS ilw
ON it.trx_id = ilw.requesting_trx_id
AND it.trx_id = ilw.blocking_trx_id
I found following way which can be used if you KNOW name of lock
select IS_USED_LOCK('lockname');
however i not found any info about how to list all names.
Another easy way is to use:
mysqladmin debug
This dumps a lot of information (including locks) to the error log.
Related
Starting MySQL 5.7.6, mysql.gtid_executed is supposed to keep track of all gtids executed.
However in MySQL 5.7.14, I am seeing a scenario as below
mysql> select ##global.gtid_executed;
+-----------------------------------------------------------------------+
| ##global.gtid_executed |
+-----------------------------------------------------------------------+
| cd5cd102-6586-0742-6f26-5b4c4c17d44d:4294967296:8589934592-8589939092 |
+-----------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select * from mysql.gtid_executed;
Empty set (0.00 sec)
Can this discrepancy be explained?
As per the mysql documentation
If binary logging is enabled (log_bin is ON), whenever the binary log is rotated or the server is shut down, the server writes GTIDs for all transactions that were written into the previous binary log into the mysql.gtid_executed table. This situation applies on a replication source server, or a replica where binary logging is enabled.
I was seeing the same behavior when mysql starts up but after flushing the logs FLUSH LOGS; could see the GTID range in the mysql.gtid_executed table.
I'm working on a financial system and I've got a problem with the MySQL transactions.
The system is a simple stock exchange, where users can buy and sell virtual shares. To keep integrity in buy and sell process I use transactions.
The problem is that in some cases (I don't know what it depends on) some of transactions are rolled back (or not commited), but next queries are processed.
The process is following:
User wants to buy shares for 1000 USD
In orderbook there are 4 offers for 250 USD
START TRANSACTION
For every offer:
Script does a UPDATE query (moving USD from one user to another and shares in the opposite way). Then script INSERTs entries to history tables.
Users pay a fee (UPDATE balances).
Repeat 5 and 6 for the next offer.
COMMIT
Now the key part - in some cases changes from point 5 are not saved, but from the 6 they are (I see that fee was paid, but there is no transaction in the history).
I'm not using ROLLBACK during this transactions and the script is not breaking (because in this case fee wouldn't be paid).
Is there any possibility that transaction is rolling back without ROLLBACK query? Or can MySQL COMMIT only few newest queries instead of all?
Transactions or not, it's the responsibility of your client code to verity that all your INSERT or UPDATE queries complete successfully and then either issue a explicit ROLLBACK or close the connection withour COMMIT to issue an implicity ROLLBACK. If any of them fails but your code goes on, those queries will not take effect (because they failed) but the rest will do.
Here's a simplified example:
mysql> create table test (
-> id int(10) unsigned not null,
-> primary key (id)
-> );
Query OK, 0 rows affected (0.02 sec)
mysql> insert into test(id) values (1);
Query OK, 1 row affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test(id) values (2);
Query OK, 1 row affected (0.00 sec)
mysql> insert into test(id) values (-3);
ERROR 1264 (22003): Out of range value for column 'id' at row 1
We should have rollbacked and aborted here, but we didn't.
mysql> insert into test(id) values (4);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test;
+----+
| id |
+----+
| 1 |
| 2 |
| 4 |
+----+
3 rows in set (0.00 sec)
4 rows expected, got 3.
Other than that, there're many circumstances where you can get an unwanted COMMIT but an unwanted ROLLBACK is something I'm not sure that can happen unless you terminate a session with pending changes.
It's long time since the question was asked, but the problem actually was that I didn't check for the SQL errors for every query.
Actually at some points, when I should rollback transaction, I didn't do it.
If your are looking for answer - check again if you testing ALL queries in your transaction for successful execution and don't trust that the framework you are using is doing it for you automatically (just check it again).
In MySQL, an overflow creates only a warning and MySQL destroys the data you feed it:
mysql> create table tmp(data tinyint primary key);
Query OK, 0 rows affected (7.83 sec)
mysql> insert into tmp set data = 200;
Query OK, 1 row affected, 1 warning (2.27 sec)
mysql> select * from tmp;
+------+
| data |
+------+
| 127 |
+------+
1 row in set (0.00 sec)
This is a huge problem, especially when using MySQL via a programming language, where one (usually) does not check any MySQL-warnings. This may cause not only data-corruption, but data-corruption that is hidden and may remain undetected - one of the worst things that may happen in a database.
Is there a way to configure MySQL so that an overflow causes an ERROR (similar to a syntax error) and not only a warning?
See Mysql documentation
you have to activate the strict SQL mode:
If strict SQL mode is enabled, MySQL rejects the out-of-range value with an error, and the insert fails, in accordance with the SQL standard.
If no restrictive modes are enabled, MySQL clips the value to the appropriate endpoint of the range and stores the resulting value instead.
I have a question about MySQL InnoDB. For example: I have thread A to start a transaction:
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> update user set name = "Jim" where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
And then, I just leave the thread A as it is. I started another thread B to do this:
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> update user set name = "Tom" where id = 1;
And I got the error:
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
It makes sense, because thread A put a 'X' lock on that row.
And then I used thread B to do this:
mysql> start transaction;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from user where id = 1;
+----+------+
| id | name |
+----+------+
| 1 | wlq3 |
+----+------+
1 row in set (0.00 sec)
Here I'm confused. Like I just said thread A put a 'X' lock on that row. why thread B can read this row. In my opinion, reading data need a share lock, but exclusive lock is already on that data. Is there anyone can help me ,thanks!
By the way, the isolation level of thread A is repeatable read, and thread B is read committed.
Well wlq3 is the committed value in the database so transaction B reads this value. The update with Jim has not committed yet.A lock will not block a read it will just block a update this is due to the MVCC locking model which is implemented in InnoDB.
See this link for more information: InnoDB's row locking the same as MVCC Non-Blocking Reads?
I am performing SELECT ... FOR UPDATE or row level locking with InnoDB tables.
My intention is to only one request can read the same row. So if two users make request for the same data as the same time. Only one of them get data, who fires the query first.
But How can i test that locking is placed or not. as I am testing it by retrieving the same data at same time and both users getting the data.
Note: My tables are InnoDB, My query executes in transaction, my query as below:
SELECT * FROM table_name WHERE cond FOR UPDATE;
Any other thing I have to check for this to make work?
open 2 mysql client session.
on session 1:
mysql> start transaction;
mysql> SELECT * FROM table_name WHERE cond FOR UPDATE;
... (result here) ...
1 row in set (0.00 sec)
on session 2:
mysql> start transaction;
mysql> SELECT * FROM table_name WHERE cond FOR UPDATE;
... (no result yet, will wait for the lock to be released) ...
back to session 1, to update selected record (and release the lock):
mysql> UPDATE table_name SET something WHERE cond;
mysql> commit;
back to session 2:
1) either showing lock timeout error
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
2) or showing result
... (result here) ...
1 row in set (0.00 sec)
3) or showing no result (because corresponding record has been modified, so specified condition was not met)
Empty set (0.00 sec)
You can use own lock mechanizm with lock_by column.
UPDATE table_name SET locked_by=#{proccess_id} WHERE cond and locked_by IS NULL
Now in your program you will get count of affected rows:
if(affected_rows==0)
return 'rows locked'
else
//do your staff with locked_by=#{process_id} rows
With this mechanism you can control locked rows and locking processes. You can also add in UPDATE statement locked_at=NOW() to get more info about locked row.
Don't forget to add some index on locked_by column.
Here is MySQL docs about working with locks.
Before update you can put lock, releasing it after. In another transaction you can check lock using it unique name. Strategy for naming you can choose yourself.