[MDEV-11402] Running connections hang forever when all tables are flushed and locked for a few seconds Created: 2016-11-29  Updated: 2016-11-29  Resolved: 2016-11-29

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.1.19
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michael Graf Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

Windows Server 2008 R2 Enterprise

Attachments: File my.ini     File mysqld.exe_161129_100345.001     File mysqld.exe_161129_100345.002     File mysqld.exe_161129_100345.crc     Microsoft Word show_full_processlist.csv    

 Description   

For the backup of MariaDB we use VSShadow and therefore the following commands are executed:

DROP TABLE IF EXISTS ibbackup_binlog_marker;
CREATE TABLE ibbackup_binlog_marker(a INT) ENGINE=INNODB;
SET AUTOCOMMIT=0;
INSERT INTO ibbackup_binlog_marker VALUES (1);
USE mysql;
FLUSH TABLES WITH READ LOCK;
COMMIT;

With MariaDB 5.5 we didn't have any problems. But with MariaDB 10.1 all running connections hang forever and didn't return anymore when the commands above are executed. I have attachted the response of "show full processlist" and the minidump of MariaDB and the my.ini.

 Comments   
Comment by Vladislav Vaintroub [ 2016-11-29 ]

I think you need "UNLOCK TABLES" after FLUSH TABLES WITH READ LOCK.

Comment by Elena Stepanova [ 2016-11-29 ]

As wlad said above, you need to unlock tables after FLUSH TABLES WITH READ LOCK. The whole point of running it is to block updates from other connections, which is what happens in your processlist.

5.5 is no different in this regard, I've just checked. Maybe your flow was somewhat different with 5.5.

Comment by Michael Graf [ 2016-11-29 ]

Sorry, it's our mistake.
There was a second mariadb directory with the same port on which the backup program tried to execute the same sql statements again.
But instead to connect to another MariaDB server it connected to the same MariaDB server again.
This lead to a deadlock.

Generated at Thu Feb 08 07:49:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.