[MDEV-10407] Transactions not in Galera's receive queue when FLUSH TABLES WITH READ LOCK executed Created: 2016-07-20  Updated: 2018-07-16  Resolved: 2018-07-16

Status: Closed
Project: MariaDB Server
Component/s: Galera, wsrep
Affects Version/s: 10.0.24-galera
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Geoff Montee (Inactive) Assignee: Jan Lindström (Inactive)
Resolution: Not a Bug Votes: 0
Labels: galera, wsrep


 Description   

Let's say that we have a 2 node cluster.

On one of the nodes, let's set up a table like the following:

CREATE TABLE db1.lock_test (
 
	id int auto_increment primary key,
 
	str varchar(50)
 
);

Then on node 2, execute the following:

FLUSH TABLES WITH READ LOCK;

Then on node 1, execute the following:

INSERT INTO db1.lock_test VALUES (1, 'str1');

And then let's look at the state on node 2:

MariaDB [(none)]> SELECT * FROM db1.lock_test;
 
Empty set (0.00 sec)
 
 
 
MariaDB [(none)]> SHOW GLOBAL STATUS WHERE Variable_name IN ('wsrep_local_state_comment', 'wsrep_local_recv_queue', 'wsrep_local_recv_queue_max', 'wsrep_flow_control_paused', 'wsrep_flow_control_sent', 'wsrep_flow_control_recv');
 
+----------------------------+----------+
 
| Variable_name              | Value    |
 
+----------------------------+----------+
 
| wsrep_local_recv_queue     | 0        |
 
| wsrep_local_recv_queue_max | 1        |
 
| wsrep_flow_control_paused  | 0.000000 |
 
| wsrep_flow_control_sent    | 0        |
 
| wsrep_flow_control_recv    | 0        |
 
| wsrep_local_state_comment  | Synced   |
 
+----------------------------+----------+
 
6 rows in set (0.00 sec)

The new row is not in the table on node 2 and it is not in node 2's receive queue, since wsrep_local_recv_queue = 0.

However, let's do the following on node 2:

UNLOCK TABLES;

The row does correctly show up at that point:

MariaDB [(none)]> SELECT * FROM db1.lock_test;
 
+----+------+
 
| id | str  |
 
+----+------+
 
|  1 | str1 |
 
+----+------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [(none)]> SHOW GLOBAL STATUS WHERE Variable_name IN ('wsrep_local_state_comment', 'wsrep_local_recv_queue', 'wsrep_local_recv_queue_max', 'wsrep_flow_control_paused', 'wsrep_flow_control_sent', 'wsrep_flow_control_recv');
 
+----------------------------+----------+
 
| Variable_name              | Value    |
 
+----------------------------+----------+
 
| wsrep_local_recv_queue     | 0        |
 
| wsrep_local_recv_queue_max | 1        |
 
| wsrep_flow_control_paused  | 0.000000 |
 
| wsrep_flow_control_sent    | 0        |
 
| wsrep_flow_control_recv    | 0        |
 
| wsrep_local_state_comment  | Synced   |
 
+----------------------------+----------+
 
6 rows in set (0.00 sec)

Is it intentional that pending transactions aren't in the receive queue when a lock is held by FLUSH TABLES WITH READ LOCK?

 Comments   
Comment by Geoff Montee (Inactive) [ 2016-07-20 ]

Note that wsrep_sync_wait=1 still seems to wait properly in this situation.

Node 2:

MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
 
Query OK, 0 rows affected (0.00 sec)

Node 1:

MariaDB [db1]> INSERT INTO db1.lock_test VALUES (1, 'str1');
 
Query OK, 1 row affected (0.00 sec)

Node 2:

MariaDB [(none)]> SET SESSION wsrep_sync_wait=1;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SELECT * FROM db1.lock_test;
 
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Comment by Jan Lindström (Inactive) [ 2018-07-16 ]

The wsrep_local_recv_queue refers to a queue within galera's group communication system, once a message is delivered to the upper layer, it is removed from that queue. In your specific case, the insert is delivered, but is probably stuck applying because of the read lock.

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