Testcase:

When we do FTWRL on node-1 we acquire global read lock (which blocks write to any table) and pause wsrep provider. The consequence is that any writeset replicated from node-2 is blocked at galera level on LocalMonitor. This behavior is OK.

When we do FLUSH TABLE t1 WITH READ LOCK on node-1 , we also block replication of t2 from node-2, which is not locked. This is because we also pause wsrep provider and applier threads are blocked on LocalMonitor. In this case, we should block only replication of t1. If node-2 inserts something to t2 only (no writes to t1), these writesets should be replicated and applied on node-1. Of course if we do several insertions on node-2 to t1, after replication, applier threads on node-1 should be blocked. This can cause blocking/waiting all applier threads on node-1 and consecutive inserts to t2 will be blocked as well. However, if there are no inserts to t1 on node-2, all inserts to t2 should be replicated and applied on node-1.

To do this, we should not pause wsrep provider FLUSH TABLE t1 WITH READ LOCK but we should rely on MDL locks. This way, t2 writesets will be applied on node-1 and t1 writesets will cause applier thread to block and wait on open_tables()

Solution:

In sql_parse.cc, case SQLCOM_FLUSH remove wsrep-specific code around wsrep_pause_once(&already_paused))