Details
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?