Strange behavior of DDL with FTWRL
General
Escalation
General
Escalation
Description
Environment
None
Attachments
3
- 31 Mar 2020, 01:12 PM
- 31 Mar 2020, 01:12 PM
- 31 Mar 2020, 01:12 PM
Smart Checklist
Activity
Show:
Kathy Williamson April 7, 2020 at 4:19 PMEdited
This is expected behavior because strict mode processing does not include FTWRL.
Lalit Choudhary April 6, 2020 at 9:08 AM
Hi Sergey,
Thank you for the report.
Sergey Kuzmichev March 31, 2020 at 1:16 PM
After writing this, found https://jira.mariadb.org/browse/MDEV-7808 which is the same issue explained the same way
Not a Bug
Details
Details
Assignee
Unassigned
UnassignedReporter
Sergey Kuzmichev
Sergey Kuzmichev(Deactivated)Affects versions
Priority
Smart Checklist
Open Smart Checklist
Smart Checklist

Open Smart Checklist
Created March 31, 2020 at 1:15 PM
Updated March 6, 2024 at 9:39 PM
Resolved April 7, 2020 at 4:19 PM
In presence of FTWRL DDL and DML behave differently. DDL shows a strange behavior, seemingly breaking TOI promise.
Session #1:
FLUSH TABLES WITH READ LOCK;
Session #2:
CREATE TABLE IF NOT EXISTS t1 (id int auto_increment primary key);
Observer:
SHOW PROCESSLIST; +----+-------------+-----------+------+---------+------+----------------------+-------------------------------------------------------------------+-----------+---------------+ | Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined | +----+-------------+-----------+------+---------+------+----------------------+-------------------------------------------------------------------+-----------+---------------+ | 1 | system user | | NULL | Sleep | 194 | wsrep: aborter idle | NULL | 0 | 0 | | 2 | system user | | NULL | Sleep | 194 | wsrep: applier idle | NULL | 0 | 0 | | 4 | system user | | NULL | Sleep | 192 | wsrep: applier idle | NULL | 0 | 0 | | 5 | msandbox | localhost | NULL | Sleep | 12 | | NULL | 0 | 0 | | 6 | msandbox | localhost | test | Query | 5 | checking permissions | CREATE TABLE IF NOT EXISTS t1 (id int auto_increment primary key) | 0 | 0 | | 7 | msandbox | localhost | NULL | Query | 0 | starting | show processlist | 0 | 0 | +----+-------------+-----------+------+---------+------+----------------------+-------------------------------------------------------------------+-----------+---------------+
On another node at the same time, the table is present already, and writes can be done to it. On the "FTWRL node" table is not present.
FTWRL node:
SELECT * FROM test.t1; ERROR 1146 (42S02): Table 'test.t1' doesn't exist
Another node:
INSERT INTO t1 VALUES (DEFAULT); INSERT INTO t1 VALUES (DEFAULT); SELECT * FROM test.t1; +----+ | id | +----+ | 3 | | 6 | +----+
If wsrep_sync_wait is enabled, reads stall on the "FTWRL node" as well.
Once UNLOCK TABLES; is executed, or Session #1 is terminated, the DDL goes through.
This is probably expected since upon running FTWRL the node will desync, but:
1. DDL is replicated to other nodes and they can write to new table (and other tables)
2. "checking permissions" state is a bit confusing
Comparing with the behavior of FTWRL and DML:
1. DML is not replicated to other nodes
2. DML shows "Waiting for global read lock" state while waiting
Attached "FTWRL node" error log + pt-pmp outputs.